How to Build a WebMCP Tool for ITR Filing in India

AI agents can make income tax return (ITR) filing in India easier by collecting documents, explaining tax concepts, identifying missing information and preparing a reviewable draft. A WebMCP tool can expose these capabilities to agents through a structured, permission-aware interface—without giving an agent uncontrolled access to sensitive financial data or the final filing action.

This guide explains how to build a WebMCP tool for agents to assist with income tax return filing in India, with an implementation approach for founders, developers and tax-tech teams. The focus is assistance and preparation: the taxpayer or an authorised tax professional should retain control over declarations, verification and submission.

What is WebMCP and why use it for ITR assistance?

WebMCP refers to a web-based Model Context Protocol integration that allows AI agents to discover and call narrowly defined tools exposed by a website or web application. Instead of asking an agent to navigate arbitrary pages, you provide typed operations such as:

get_filing_context
extract_form16_fields
summarise_ais_transactions
calculate_tax_scenarios
validate_itr_draft
prepare_review_package

The agent can then combine these operations into a guided workflow. For Indian tax filing, this is valuable because the process involves multiple sources and concepts: Form 16, Annual Information Statement (AIS), Tax Information Summary (TIS), Form 26AS, capital gains statements, interest income, deductions, regime selection and e-verification.

A WebMCP layer should not be treated as a shortcut around the Income Tax Department’s official authentication or filing controls. Its role is to coordinate trusted data, calculations and explanations while making uncertainty visible.

Define the product boundary before writing code

Start with a precise scope. A safe first version should assist with preparation for common individual taxpayers rather than attempting to automate every ITR form and tax scenario.

Suitable first-release capabilities

Identify the likely ITR form based on taxpayer-provided facts.
Import or parse user-uploaded documents such as Form 16 and broker statements.
Normalise income, TDS and deduction data into a canonical schema.
Compare old-regime and new-regime tax outcomes where applicable.
Detect mismatches between Form 16, AIS, TIS and user declarations.
Produce an explanation and review checklist.
Generate a structured draft for a human to approve.

Capabilities to defer

Filing returns without explicit, current consent.
Storing reusable Income Tax e-filing credentials or OTPs.
Making legal or tax-advisory claims without qualified review.
Handling complex international income, trusts, cryptocurrency, litigation or intricate business accounts without specialist workflows.
Inferring sensitive facts—such as residential status, ownership or eligibility for deductions—from incomplete evidence.

The product should clearly state whether it is a calculator, document assistant, tax-preparation platform or professional-adviser support tool.

Design a WebMCP tool around narrow, typed actions

Avoid exposing one broad function such as file_income_tax_return(data). A monolithic tool encourages agents to send incomplete or unsafe payloads. Use small operations with explicit schemas, validation and predictable outputs.

A practical tool catalogue might look like this:

{
  "name": "calculate_tax_scenarios",
  "description": "Calculate indicative tax liability under selected regimes using validated taxpayer inputs.",
  "inputSchema": {
    "type": "object",
    "required": ["assessmentYear", "incomeSources", "deductions", "residentialStatus"],
    "properties": {
      "assessmentYear": { "type": "string" },
      "incomeSources": { "type": "array" },
      "deductions": { "type": "array" },
      "residentialStatus": { "type": "string" },
      "ageCategory": { "type": "string" }
    }
  }
}

Return machine-readable data as well as human-readable explanations. Every result should include:

Assessment year and tax-year assumptions.
Data sources used.
Calculation version.
Missing or conflicting fields.
Confidence or review status.
Whether the output is indicative or ready for professional review.

For example, a calculation response could contain gross_total_income, chapter_vi_a_deductions, taxable_income, tax_before_rebate, rebate, cess, interest, TDS, advance_tax, balance_payable and refund_estimate. Do not hide rounding rules or assumptions.

Build an India-specific canonical tax data model

Documents use different labels and formats. Create an internal canonical model before passing data to tax rules or an AI agent.

Useful entities include:

Taxpayer: PAN token, assessment year, age category, residential status and contact verification state.
Employment: employer identifier, salary components, exempt allowances, perquisites, professional tax and TDS.
Bank income: account reference, interest type, gross interest and TDS.
Capital gains: asset class, acquisition date, sale date, cost, consideration, expenses and holding-period evidence.
Deductions: section, amount claimed, eligibility evidence and verification status.
Taxes paid: TDS, TCS, advance tax and self-assessment tax.
Evidence: document hash, source, extraction confidence, page or table location and upload timestamp.

Use decimal arithmetic rather than binary floating-point values for money. Store amounts in paise or as decimal values with a fixed currency of INR. Preserve the original document and extracted value separately so that a user can trace every number.

Integrate documents without over-trusting OCR or LLM extraction

A typical workflow is:

1. The user uploads a document through an authenticated interface.
2. Malware scanning and file-type validation run before processing.
3. Text and tables are extracted using deterministic parsers or OCR.
4. Candidate fields are mapped to the canonical data model.
5. Validation checks ranges, dates, totals and identifiers.
6. The user confirms or corrects the extracted values.
7. Only confirmed or appropriately labelled fields become inputs to calculations.

For Form 16, validate that salary, exempt allowances, deductions and TDS reconcile with the certificate’s totals. For AIS and TIS, retain source labels and transaction categories because classification may require user confirmation. Form 26AS is particularly useful for tax-credit reconciliation, but it should not automatically override other evidence.

An agent should say, for example, “The dividend amount was extracted from page 3 with 82% confidence; please confirm,” rather than silently inserting it into a return.

Implement tax calculations as versioned deterministic services

Do not ask a language model to calculate final tax. Use a deterministic rules engine or reviewed calculation service, versioned by assessment year and applicable legal rules. The agent can gather facts, explain results and ask follow-up questions, but the arithmetic and eligibility logic should be reproducible.

The service should support:

Old-regime and new-regime comparisons where relevant.
Slabs, rebates, surcharge and health and education cess.
Salary exemptions and standard deductions applicable to the selected year.
Section 80C and other deductions only when eligibility and evidence are recorded.
Capital gains separated by asset type and applicable holding-period rules.
TDS, TCS, advance tax and self-assessment tax reconciliation.
Interest calculations under applicable provisions, with assumptions shown.

Tax rules change frequently. Maintain a rule manifest containing assessment year, effective dates, source references, test cases and approval history. Add regression tests for boundary amounts, age categories, regime selection, rebates, losses, rounding and missing data.

Because Indian tax compliance is fact-sensitive, the interface should use labels such as “indicative estimate” and “requires review” unless all required information has been validated.

Add consent, identity and data-security controls

ITR information includes PAN, salary, bank details, investments and identity documents. Treat it as highly sensitive personal and financial data.

Recommended controls include:

Explicit consent before document processing and before each sensitive tool call.
Short-lived access tokens scoped to a specific taxpayer, assessment year and action.
No PAN, Aadhaar, bank account number or OTP in model prompts or application logs.
Encryption in transit and at rest, with managed key rotation.
Role-based access for taxpayers, support staff, tax professionals and administrators.
Tenant isolation and strict object-level authorisation.
Redaction in analytics, debugging and observability systems.
Malware scanning, content-type validation and upload size limits.
Retention and deletion controls that users can understand and invoke.
Audit logs recording who accessed what, when, why and under which consent.

Do not let the agent request or store an e-filing password, OTP or Aadhaar authentication secret. If official filing is later supported, use a compliant redirect or government-approved integration pattern in which credentials remain with the taxpayer and the final declaration is clearly presented for approval.

India-specific legal review is essential. Design around applicable requirements under the Digital Personal Data Protection framework, contractual obligations, security standards and any rules governing tax professionals or intermediaries. Obtain professional advice before production launch.

Create an agent-safe interaction flow

A reliable conversation should follow a state machine rather than improvisation. One possible flow is:

1. Identify task: preparation, comparison, reconciliation or explanation.
2. Confirm assessment year: never assume the year from the current date.
3. Collect profile facts: taxpayer type, residential status, age category and income sources.
4. Request evidence: Form 16, AIS/TIS, 26AS and relevant statements.
5. Resolve conflicts: ask targeted questions when sources disagree.
6. Run calculations: produce scenario results with assumptions.
7. Show review screen: list every material field, source and unresolved issue.
8. Obtain confirmation: capture explicit consent for draft generation.
9. Create review package: draft data, computation summary and evidence index.
10. Stop before filing: require a separate, deliberate approval and compliant submission flow.

Tool responses should distinguish between complete, needs_user_input, conflict, not_supported and system_error. This prevents the agent from treating an unavailable value as zero or interpreting a parsing failure as a clean result.

Build validation and reconciliation checks

Validation is the main defence against plausible but incorrect returns. Useful checks include:

PAN format validation without exposing the full PAN unnecessarily.
Assessment-year and document-period consistency.
Employer salary totals versus Form 16 totals.
TDS in Form 16 versus Form 26AS and AIS, with explainable differences.
Duplicate interest, dividend or securities transactions.
Capital-gain proceeds and costs matching broker reports.
Deduction amounts supported by declarations or documents.
Losses carried forward only when historical evidence exists.
Tax payable and refund values reconciled to taxes already paid.
Required fields present for the selected ITR form.

Every warning should have a severity and remediation. “TDS mismatch” is less useful than “Form 16 shows ₹48,000 TDS, while the tax-credit statement shows ₹42,000; review employer reporting before proceeding.”

Test the WebMCP integration like a financial system

Testing should cover more than successful tool calls. Build automated and adversarial test suites for:

Invalid schemas and oversized payloads.
Prompt injection inside uploaded PDFs or spreadsheets.
Cross-user data access attempts.
Replay of expired consent tokens.
Tool calls with mismatched assessment years.
Partial OCR extraction and corrupted documents.
Duplicate transactions and contradictory evidence.
Tax-rule boundary conditions and rounding.
Agent attempts to bypass review or invoke filing without approval.
Rate limits, retries and idempotency.

Use synthetic taxpayer data in development. In staging, use masked or generated documents. Maintain immutable calculation fixtures so a change to a tax-rule package can be compared against previous outputs.

Observability, human review and operational controls

Record structured events rather than raw sensitive prompts. Monitor tool latency, parsing failure rates, unresolved conflicts, calculation discrepancies, consent failures and user correction frequency. A rise in corrections for one document format may indicate an extraction regression.

Introduce human review for high-risk cases, including:

Foreign income or non-resident status.
Multiple businesses or presumptive taxation questions.
Significant capital gains or losses.
Related-party or trust transactions.
Notices, revised returns or prior-year corrections.
Conflicting identity or tax-credit information.

The agent should be able to escalate with a concise evidence bundle: facts provided, documents used, calculations, unresolved questions and the precise reason for review.

Suggested technical architecture

A production architecture can separate responsibilities into these services:

Web client: consent, uploads, review screens and final confirmation.
WebMCP gateway: tool discovery, schema validation, authentication and rate limiting.
Agent orchestrator: conversation state and tool selection, without owning tax logic.
Document pipeline: malware scanning, OCR, extraction and evidence storage.
Canonical data service: versioned taxpayer facts and provenance.
Tax rules engine: deterministic assessment-year calculations.
Reconciliation service: AIS, TIS, 26AS and document comparisons.
Audit service: consent, access and action records.
Review and export service: human-readable computation and structured draft output.

Use idempotency keys for document processing and calculation requests. Keep WebMCP tools stateless where possible, while storing workflow state in a controlled backend associated with an authenticated session.

Launch a safer MVP

For an initial release, support one narrowly defined segment: salaried resident individuals with Form 16, interest income and straightforward deductions. Limit the product to document extraction, tax-regime comparison, mismatch detection and a reviewable preparation package.

Measure:

Percentage of fields confirmed without correction.
Reconciliation success rate.
Calculation agreement with an independently reviewed reference engine.
Time saved per completed preparation.
Escalation rate for unsupported cases.
Security and consent incidents.

Expand only after tax professionals review representative cases across assessment years and user testing shows that people understand the difference between an estimate, a draft and a filed return.

FAQ: WebMCP tools for Indian ITR agents

Can a WebMCP agent file an ITR automatically?

Technically, an application may automate parts of a workflow, but unattended filing creates serious consent, identity, accuracy and compliance risks. A safer design stops at a reviewable draft and requires explicit taxpayer approval through an appropriate, secure filing flow.

Which documents should the tool support first?

Start with Form 16, AIS, TIS, Form 26AS, bank interest certificates and broker capital-gains statements. Add documents incrementally with format-specific extraction tests and provenance tracking.

Should tax calculations be performed by an LLM?

No. Use a deterministic, versioned rules engine for arithmetic and eligibility logic. The LLM can collect facts, explain scenarios and identify missing information, but it should not be the source of final calculations.

How should PAN and OTP data be handled?

Minimise collection, encrypt sensitive data, redact logs and use scoped tokens. Never place OTPs or reusable filing credentials in prompts, model context, analytics tools or long-term application storage.

Is this product tax advice?

That depends on the functionality, claims, user context and applicable professional rules. Clearly disclose limitations and obtain Indian tax, privacy and compliance advice before offering recommendations or filing services.

Apply for AI Grants India

Building a secure WebMCP tool for Indian tax agents requires strong engineering, compliance design and responsible AI practices. Apply to AI Grants India for support in developing and scaling your India-focused AI startup.