The itr-agent server is a local-first Indian income tax (ITR) filing assistant that computes taxes, parses documents, and guides you through filing — entirely on your machine without uploading data anywhere.
Core Capabilities:
Tax Computation — Calculate full Indian income tax under the new or old regime, including slabs, standard deduction, 87A rebate with marginal relief, 111A/112A capital gains rates, surcharge (15% cap), and 4% cess.
Regime Comparison — Compare old vs. new tax regimes side by side for the same income, with a recommended regime and savings amount.
ITR Form Recommendation — Determine the correct ITR form (ITR-1/2/3/4) based on income heads, residency, losses, and disqualifiers (e.g., foreign assets, director status, brought-forward losses).
Filing Checklist — Step-by-step, form-specific walkthrough for filing on incometax.gov.in, covering documents, reconciliation, portal steps, and e-verification.
Advance Tax Planning — Schedule installments (Jun/Sep/Dec/Mar at 15/45/75/100%) based on estimated liability and TDS, with shortfall tracking.
Interest Computation (234A/B/C) — Calculate interest for advance tax shortfalls with Rule 119A rounding and statutory safe harbors.
HRA / 80GG Calculation — Compute HRA exemption under Rule 2A (period-wise, metro/non-metro) or the 80GG alternative.
Deduction Checklist — List old-regime deductions with statutory caps (80C, 80CCD(1B), 80D, HRA, etc.).
Parse Form 26AS — Extract structured TDS entries from the caret-delimited TRACES text export.
Parse AIS — Decrypt and parse the Annual Information Statement JSON export on-device using AES-256-CBC/PBKDF2 derived from PAN + DOB.
Reconcile Documents — Cross-check Form 16 vs. AIS vs. Form 26AS for mismatches (TDS over-claims, missing employers, undeclared interest/dividends) to pre-empt tax notices.
Supported Tax Years — Query supported fiscal years and their filing deadlines.
Provides tools for parsing Zerodha tax P&L statements to aggregate capital gains (planned for v0.3).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@itr-mcp Compare old and new regime for a salary of 12 lakhs."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Local-first ITR filing agent for Indian income tax. Claude interviews you one question at a time, picks your ITR form, computes your tax deterministically on your machine, reconciles your documents, and walks you to the portal's submit button -- no accounts, no uploads, no cloud.
Works with Claude Desktop, Claude Code, and any MCP client. Formerly published as itr-mcp.
You: Help me file my ITR.
Claude: [file_my_itr] One question at a time. First: were you a resident of India
for all of FY 2025-26?
You: Yes, salaried, and I have vested US RSUs from my employer.
Claude: [recommend_itr_form] Foreign assets (Schedule FA) rule out ITR-1: you file
ITR-2, due 2026-07-31. Next: how many employers this year?Every Indian tax tool wants your data on their servers. itr-agent flips it: your documents stay local, the LLM never does arithmetic, and every number comes from a versioned rule pack you can audit. The agent layer drives the interview; the deterministic engine does the math.
What it will never do: submit the return for you. India has no public filing API -- returns are filed by you on incometax.gov.in (or by an authorized ERI/CA). The agent takes you to that button with every number verified; you press it.
Related MCP server: mcp-india-stack
file_my_itr (MCP prompt) runs the guided interview:
Residency, age band -- one question at a time
Income heads: salary, house property, capital gains, business/F&O, other sources
Disqualifier sweep: foreign RSUs/ESPP, director role, unlisted shares, ESOP deferral
Losses, current and brought-forward (they change the form)
recommend_itr_form -> the form, with rule-by-rule reasoning
compare_regimes -> the regime, with real numbers
parse_ais / parse_form26as / reconcile_documents -> fix mismatches BEFORE filing
schedule_advance_tax / compute_interest_234 if applicable
filing_checklist -> schedule-by-schedule portal walkthrough, ending at e-verification
Tool | What it does |
| ITR-1/2/3/4 selection with rule-by-rule reasoning and loss-continuity awareness: brought-forward business losses force ITR-3 even with zero current-year business income (Schedule CFL) |
| Ordered, form-specific walkthrough: documents, reconciliation, computation, portal steps schedule by schedule, e-verification |
| Full FY 2025-26 (AY 2026-27) computation: new/old regime slabs (incl. the senior and super-senior slab sets), standard deduction, 87A rebate (new regime: Rs 60,000 up to Rs 12L with marginal relief, never offsetting 111A/112A tax; old regime: Rs 12,500 on total income up to Rs 5L, no marginal relief, offsets 111A), 111A (20%) / 112A (12.5% above 1.25L) capital gains with the unexhausted-basic-exemption set-off, surcharge with the 15% gains cap and its own marginal relief, 4% cess, s.288A/288B rounding |
| Old vs new side by side, recommended regime, savings amount |
| Jun/Sep/Dec/Mar installment plan (15/45/75/100%) with shortfall tracking |
| Sections 234A/234B/234C interest with the statutory 12%/36% safe harbors, the s.234B(2) self-assessment payment ladder, and Rule 119A rounding (principal floored to Rs 100, part month = full month). Reports which sections it skipped and why |
| HRA exemption per Rule 2A, period-wise (least of three limbs; FY 2025-26 metros: Delhi/Mumbai/Kolkata/Chennai) + the 80GG alternative, with its Rs 5,000-per-month cap and the bars under the new regime and alongside HRA |
| Old-regime deduction checklist with statutory caps (80C, 80CCD(1B), 80D tiers, HRA metros) |
| Parse the caret-delimited Form 26AS Text export from TRACES into structured TDS entries |
| Decrypt + parse the AIS JSON export on-device (AES-256-CBC/PBKDF2 with the password derived from PAN + DOB); normalized rows with label-matched amounts/dates/codes |
| Form 16 vs AIS vs 26AS mismatch report -- the checks that pre-empt 143(1)(a) intimations and 139(9) defect notices (TDS over-claim, missing employer, undeclared AIS interest/dividend) |
| Supported fiscal years + AY 2026-27 filing deadlines |
All tools are read-only (readOnlyHint: true), take zod-validated inputs, and return structuredContent alongside the human-readable text.
claude mcp add itr-agent -- npx -y itr-agentAdd to claude_desktop_config.json:
{
"mcpServers": {
"itr-agent": {
"command": "npx",
"args": ["-y", "itr-agent"]
}
}
}git clone https://github.com/Sagargupta16/itr-agent
cd itr-agent && pnpm install && pnpm build
node dist/index.js # stdio serverSame server, new name. Replace itr-mcp with itr-agent in your MCP config; the itr-mcp npm package is deprecated and frozen at v0.2.0.
"Help me file my ITR." (starts the guided interview)
"I'm salaried with US RSUs and 2L of equity LTCG -- which ITR form am I supposed to file?"
"My CTC is 18L with 50K NPS through my employer -- which regime should I pick for FY 2025-26?"
"My estimated tax is 2.4L and TDS covers 1.8L. Plan my advance tax installments."
"Parse C:/tax/26AS.txt and total the TDS my employer deposited."
The s.139(1) due date for FY 2025-26 is in deadlines (list_tax_years prints them). Once it has passed, the return is belated under s.139(4) and four things change. file_my_itr now asks about timing before anything else, because two of them are cheaper to know up front.
Check the date yourself before acting on it. The pack's deadlines.itr1_2 is 2026-07-31; deadlines.itr3_4_nonAudit is 2026-08-31 and is not cited to a section, circular or notification. Audit cases are later again (deadlines.audit), and no tool ever selects it because nothing here takes a 44AB input, so recommend_itr_form and filing_checklist both report the non-audit date and both say so in notes.
You can still file, up to deadlines.belated (2026-12-31 for AY 2026-27) or before the assessment is completed, whichever is earlier.
s.234F fee: Rs 5,000, or Rs 1,000 where total income does not exceed Rs 5 lakh. Both figures come from the rule pack (lateFee234F) and are returned by recommend_itr_form and filing_checklist.
s.234A interest: 1% per month, or part of a month, on the tax still outstanding after TDS/TCS, advance tax and reliefs, running from the day after the due date to the date of filing. Call compute_interest_234 with monthsLateFiling (part month = full month, Rule 119A).
s.80 forfeits this year's loss carry-forward. Business, speculative and capital losses of the current year cannot be carried forward in a belated return. Set-off of losses already determined in an earlier year survives, and so does the house-property loss carry-forward (s.71B). recommend_itr_form says this in notes whenever a business, speculative or capital loss flag is set, so its ITR-3 recommendation is not read as an unconditional carry-forward. A house-property-only loss does not trigger it, because s.71B carries that one forward either way.
Not modeled, deliberately: the s.139(5) revised-return time limit, and whether a belated business filer keeps the old-regime election (s.115BAC(6) / Form 10-IEA is due on or before the s.139(1) date). The rule pack carries a deadlines.revised field, but no tool reads it and this README does not quote it: 2027-03-31 sits three months later than the same pack's deadlines.belated, and the pack's cited source page gives no calendar date for either. Read those off the portal or ask a CA before relying on either answer.
Honest boundaries, so you know before you rely on it. docs/v0.2-spec.md carries the statutory citations behind each rule, the per-section implementation status, and the register of claims that were researched and refuted.
Resident individuals, FY 2025-26 (AY 2026-27). NRI/RNOR computation differs (the form recommendation accounts for residency, the tax engine assumes resident).
No filing. There is no public API to submit an ITR; only you or an authorized ERI can file. The agent prepares and verifies everything, then hands over.
You supply the income figures. compute_tax computes tax on the heads you give it: salary, other income, 111A STCG, 112A LTCG, and old-regime deductions as a single total. It does not itself compute house property (30% standard deduction, 24(b) interest), other capital-gains heads (112 debt/property, 115BBH crypto, slab-rate debt MF under 50AA), or business P&L -- work those out separately, or with list_deductions for the Chapter VI-A caps, and pass the totals in.
Not yet modeled: house property and business P&L computation (a presumptive flag exists, but only to pick the single-installment 234C schedule and to steer the form recommendation -- 44AD/44ADA income itself is not computed), crypto/VDA (115BBH), non-equity capital gains, loss set-off arithmetic (#4), Schedule FA valuation (#5), Form 16 PDF parsing (reconcile_documents takes Form 16 figures as input, it does not read the PDF), broker capital-gains statements (#7).
Dividend is ordinary income for surcharge purposes. There is no dividend input: it goes in otherIncome. The First Schedule keeps dividend out of the 25%/37% surcharge bands and caps its surcharge at 15%, and compute_tax does neither for dividend (it does both for 111A/112A gains). Only bites above Rs 2 crore of total income; below that every band rate is already at or under 15%.
Transaction-date rules not yet split. The engine applies FY 2025-26 rates uniformly; the 23-Jul-2024 capital-gains rate flip and the 1-Oct-2024 buyback change matter for FY 2024-25 returns, which this pack does not cover.
The encrypted AIS file is not a safe place to store your data. Its password is your PAN plus your date of birth, stretched with only 1,000 PBKDF2-SHA256 iterations. Once someone knows your PAN, every plausible DOB can be tried in about 4 seconds single-threaded (measured on a laptop: 0.11 ms per key derivation over a ~36,600-date space). That is the portal's scheme, not this tool's choice, and nothing here can strengthen it -- treat a downloaded AIS export as effectively unencrypted and delete it when you are done.
parse_ais decryption is unproven on a live export. The AIS password scheme is reverse-engineered from open-source utilities and verified against this repo's synthetic round-trip, never against a file the portal actually produced. If it fails, the error tells you to pass password explicitly or use the portal's CSV export, and an issue report with your download date helps fix it. Every other tool is unaffected.
Not tax advice. Complex cases belong with a CA. Every output says so.
Local-only. stdio transport, no network calls, no telemetry, no accounts. Your documents are read from disk by this process and never uploaded anywhere. AIS decryption happens entirely on-device with Node's crypto -- the reverse-engineered password scheme has un-peppered fallbacks and an explicit password override in case the format rotates.
What your MCP client still sees. Parsed output is returned to whatever client you connected, so if that client is a hosted LLM, the parsed contents reach that provider like any other message. PAN is masked in the human-readable text mirror, but the structuredContent payload carries the full parsed document (PAN, TANs, deductor names, amounts) because downstream tools need it. Local-only describes this server, not your whole stack -- for maximum privacy, run it against a local model.
The LLM never does math. Every rupee is computed by pure functions over data/fy2025-26.json. 121 tests pin the engine to published worked examples and to statute: the 12L zero-tax case, the 12,10,000 marginal-relief case, the 12,70,588 relief exhaustion point on both sides, the surcharge bands with the First Schedule exclusion of capital-gains income, all three old-regime age bands, and the 234A/234B/234C/HRA/80GG golden cases.
The agent drives, the engine decides. The interview sequencing is a prompt; every number and every form rule is deterministic code. Nothing is estimated.
Year-parameterized. Rules live in per-FY JSON packs. FY 2026-27 (Budget 2026: Form 16 renamed to Form 130, 8 HRA metros, buyback reversion) lands as a new pack, not code changes.
Not tax advice. Every tool that computes a rupee figure returns a disclaimers array and the fiscal year it applied; compute_tax, compute_hra and list_tax_years also return the exact rulePackVersion. Verify against the official utility before filing.
v0.1 -- tax engine (both regimes + CG + surcharge + cess), regime comparison, advance tax, deduction checklist, 26AS text parser
v0.2 -- parse_ais (encrypted AIS JSON, on-device decrypt), reconcile_documents (the #1-notice-trigger checks), 234B/234C interest with golden-case tests, HRA + 80GG calculators, old-regime 87A semantics fix
v0.3 -- renamed to itr-agent; recommend_itr_form with loss-continuity awareness (#3), filing_checklist, the file_my_itr guided interview prompt
v0.4 -- engine correctness pass (senior/super-senior slab sets, surcharge marginal relief on tax + surcharge, the s.111A/112A basic-exemption set-off, s.288A/288B rounding), positional 26AS amount extraction, s.234A + the s.234B(2) payment ladder, reconcile M4/M5, belated-filing guidance, security pins on the SDK's transitives, npm publishing via OIDC with provenance, and an MCP registry manifest (server.json)
v0.5 (priorities validated against a real AY 2026-27 filing) -- compute_loss_setoff (BFLA/CFL engine, #4), parse_form16 (TRACES PDF), broker capital-gains parsers -- Groww first, then Zerodha (#7)
v0.6 -- compute_schedule_fa (foreign assets/RSU, Rule 115 rates, #5), portal quirks playbook (#6), mutual fund CAS via casparser, draft ITR JSON export, .mcpb one-click Claude Desktop bundle
pnpm install
pnpm test # vitest: engine golden files + in-memory MCP client tests
pnpm build
pnpm inspect # MCP inspector against dist/index.jsTax software has a higher correctness bar than most OSS, so the ground rules are written down: CONTRIBUTING.md (tax constants live in data/*.json with a cited source, every calculator change ships a golden test, never commit a real tax document). Version history and every constant that moved: CHANGELOG.md. Found a vulnerability? SECURITY.md has the private reporting path -- please do not open a public issue for it.
itr-agent is an open-source calculator, document parser, and filing guide. It is not a substitute for professional tax advice, and it never files anything -- output is meant to be verified against the official income tax utility, and the return is always submitted by you on the portal.
Deterministic sections 234B and 234C interest on advance-tax shortfalls. 234B: 1%/month on assessed-minus-advance when advance < 90% (from 1 April of the AY). 234C: per-installment shortfalls with the statutory 12%/36% safe harbors for June/September. Rule 119A rounding applied (principal floored to Rs 100, part month = full month).
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | 2025-26 | |
| assessedTax | Yes | Tax on total income minus TDS/TCS and reliefs, in INR | |
| presumptive | No | 44AD/44ADA: single 100% installment by Mar 15 | |
| monthsFor234B | No | Months from 1 April of the AY to payment/assessment (part month = full month) | |
| advanceTaxPaid | No | Total advance tax paid during the FY | |
| cumulativePaid | No | Cumulative advance tax paid by Jun 15 / Sep 15 / Dec 15 / Mar 15, for 234C |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds deterministic behavior, rounding (Rule 119A), and part-month rules, providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently front-load the tool's purpose and detail. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description fully explains the computation logic. However, it could briefly mention that the output is interest amounts, but the tool name makes this clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%. The description adds meaning by explaining how each parameter is used in the interest calculation, e.g., 'per-installment shortfalls' and 'safe harbors', which goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes sections 234B and 234C interest on advance-tax shortfalls, with specific formulas and rules. This distinguishes it from sibling tools like compute_tax and schedule_advance_tax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when computing interest on advance tax shortfalls, but it does not explicitly state when to use or not use this tool versus alternatives. No exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic Indian income tax computation for a fiscal year. Handles new/old regime slabs, standard deduction, 87A rebate with marginal relief, 111A/112A capital gains rates, surcharge (with the 15% cap on gains), and 4% cess. All arithmetic is done in code from a versioned rule pack -- never estimated.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | Fiscal year, e.g. '2025-26' (AY 2026-27) | 2025-26 |
| regime | Yes | Tax regime. 'new' (115BAC) is the default regime since FY 2023-24. | |
| ageBand | No | Age band: below60, senior (60-79), superSenior (80+). Affects old-regime exemption only. | below60 |
| ltcg112A | No | Long-term capital gains under section 112A in INR, BEFORE the 1.25L exemption | |
| stcg111A | No | Short-term capital gains under section 111A (listed equity, STT paid) in INR | |
| deductions | No | Old regime only: total Chapter VI-A deductions (80C, 80D, ...) in INR. Ignored under the new regime. | |
| otherIncome | No | Other normal-rate income in INR (interest, net rent, etc.) | |
| salaryIncome | No | Gross salary income in INR, before standard deduction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation: it confirms determinism ('Deterministic', 'never estimated'), source of logic ('code from a versioned rule pack'), and coverage of all major Indian tax rules. This fully informs the agent of the tool's behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph with five sentences, each contributing distinct information. No redundant or filler content. The purpose and key features are front-loaded, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema) and the annotation richness, the description adequately covers computation logic and inputs. However, it omits any mention of the output format (e.g., whether it returns a single tax amount or a breakdown), which is a minor gap. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how parameters interact (e.g., 'all arithmetic is done in code', 'Handles new/old regime slabs...'), which complements the individual parameter descriptions. It clarifies the role of deductions (old regime only) and capital gains rates, providing semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Deterministic Indian income tax computation for a fiscal year', which is a specific verb+resource combination. It enumerates handled features (regime slabs, standard deduction, 87A rebate, capital gains, surcharge, cess), making the purpose unmistakable and distinct from sibling tools like compare_regimes and compute_hra.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly provide when-to-use or when-not-to-use guidance relative to siblings. While the purpose is clear, there is no exclusionary context (e.g., 'use compare_regimes for regime comparisons'). The implied usage is present, but formal guidelines are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ordered, form-specific walkthrough for filing ITR-1/2/3/4 on incometax.gov.in: documents to gather, reconciliation, tax computation, portal steps schedule by schedule, and e-verification. Guidance only -- the taxpayer performs the final submit on the portal themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | Fiscal year, e.g. '2025-26' | 2025-26 |
| form | Yes | The ITR form to file (use recommend_itr_form if unsure) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, and the description reinforces that this is 'guidance only' with no automated action. The description adds context about the portal steps and e-verification, going beyond the annotations to clarify the tool's non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Ordered, form-specific walkthrough') and efficiently lists the covered areas. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is read-only guidance with no output schema, the description provides all necessary information: what it covers (documents, reconciliation, computation, portal steps, e-verification), and that it is guidance only. The sibling tools are complementary, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (fy with default, form with enum and suggestion to use recommend_itr_form). Schema coverage is 100%, so the description does not need to add much. It mentions 'form-specific' which aligns with the form parameter, but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an 'ordered, form-specific walkthrough' for filing ITR-1/2/3/4 on incometax.gov.in, covering specific steps like documents, reconciliation, and e-verification. It distinguishes itself from sibling tools which focus on individual computations or deductions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for guidance by stating 'Guidance only -- the taxpayer performs the final submit on the portal themselves.' However, it does not explicitly list when not to use it or directly contrast with sibling tools, though the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the old-regime deduction checklist with statutory caps for a fiscal year (80C, 80CCD(1B), 80D tiers, 80TTA/TTB, 24(b), HRA metro list). Useful for estimating the deductions input to compute_tax/compare_regimes.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | Fiscal year, e.g. '2025-26' | 2025-26 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (no side effects) and openWorldHint=false. Description adds value by specifying the checklist includes statutory caps and the exact deduction sections, going beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. First sentence describes output; second sentence explains utility. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately covers what the tool returns (checklist with caps) and how to use it. Minor lack of return format details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter 'fy', so the schema already documents it. Description does not add further parameter meaning, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns an old-regime deduction checklist with statutory caps for specific sections (80C, 80CCD(1B), etc.), and distinguishes from siblings like compute_tax and compare_regimes by providing the deduction data rather than computing taxes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states it is useful for estimating the 'deductions' input to compute_tax/compare_regimes, providing clear usage context. Does not mention when not to use or alternative tools, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the fiscal years this server has rule packs for, with filing deadlines for the current assessment year.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds value by specifying that it lists years for which 'rule packs' exist and includes 'filing deadlines for the current assessment year', providing context beyond the annotations about the data scope and additional information returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 15 words, with no redundancy. It is front-loaded with the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters, the description covers the essential purpose and additional detail (deadlines). It could mention whether the list is chronological or includes both past and future years, but overall it is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and it adds a hint about what the output contains (filing deadlines), which compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'fiscal years', specifying that it lists years with rule packs and filing deadlines. This distinguishes it from sibling tools which focus on regimes, computations, or parsing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, given its simplicity and distinct function from siblings, the context implies it is for discovering available fiscal years. Still, a sentence about prerequisites or follow-up actions would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse the caret-delimited Form 26AS TEXT export from TRACES into structured TDS entries (deductor, TAN, section, amounts) with totals. Download the 'Text' format from TRACES -- it needs no password. PDF exports are not supported; the text export is more reliable.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the 26AS .txt file downloaded from TRACES |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description clarifies read-only operation (parse file), consistent with readOnlyHint annotation. Adds output structure details but no mention of error handling or size limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states purpose; second provides actionable usage instructions. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, output items, and constraints (supported format, password). Lacks explicit output schema but mentions key fields. Adequate for a simple tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'path' parameter. Description adds no additional parameter-level information beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'parse' and resource 'Form 26AS TEXT export', with clear output items (deductor, TAN, section, amounts, totals). Distinguishes from PDF exports and implicitly from sibling 'parse_ais' by file type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells user to download Text format, notes no password needed, and states PDF is not supported. Provides context on reliability. Missing direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the advance tax installment plan (Jun 15 / Sep 15 / Dec 15 / Mar 15 at 15/45/75/100%) for an estimated tax liability net of TDS. Reports per-installment amounts and shortfalls against what has been paid so far.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | Fiscal year, e.g. '2025-26' | 2025-26 |
| paidSoFar | No | Advance tax already paid per installment, in order | |
| tdsExpected | No | TDS/TCS expected to be deducted during the year in INR | |
| estimatedTax | Yes | Estimated total tax liability for the FY in INR (use compute_tax first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with description of planning/reporting. Description adds behavioral details: the installment schedule, percentages, and shortfall reporting. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and output details. Every sentence is meaningful with no fluff. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, description covers what the tool does and what it returns (per-installment amounts and shortfalls). Missing error conditions or assumptions, but sufficient for standard use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. Description adds minimal parameter info beyond schema (e.g., 'net of TDS' linking estimatedTax and tdsExpected), but doesn't elaborate on each parameter. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds an advance tax installment plan with specific due dates (Jun 15, Sep 15, Dec 15, Mar 15) and percentages (15/45/75/100%). It reports per-installment amounts and shortfalls, distinguishing it from siblings like compute_tax or list_deductions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when you have an estimated tax liability net of TDS and want to plan installments. However, it does not explicitly state when not to use it or mention alternatives like compute_tax, though the input schema hints at using compute_tax first. Still clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0compare_regimescompute_hrafiling_checklistparse_aisreconcile_documentsv0.2.0compare_regimescompute_hracompute_interest_234compute_taxlist_deductionslist_tax_yearsparse_aisparse_form26asreconcile_documentsschedule_advance_taxEach tool targets a distinct aspect of Indian tax compliance: interest computation, general tax computation, filing walkthrough, deduction checklists, tax year info, TDS parsing, and advance tax scheduling. No two tools overlap in purpose.
All tool names use a consistent snake_case pattern with descriptive verbs (compute, list, parse, schedule, filing) followed by nouns. The naming is predictable and uniform.
With 7 tools, the server covers the core workflows of Indian tax compliance without being bloated or sparse. Each tool serves a well-defined function.
The tool set covers computation, deductions, filing, TDS, advance tax, and tax years. Minor gaps like tax payment or appeal support exist, but the core lifecycle is well-represented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
TaxSort — Tollbooth-monetized MCP server for personal tax transaction classification
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
Deterministic cross-border tax engine: PE, GAAR, Indian TP, rule-level lookup. Compiled law, no LLM.
MCP server for Quaderno — tax-rate calculation, invoices, contacts, products, receipts & expenses.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sagargupta16/itr-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
