Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavior: it returns a side-by-side comparison, a recommended regime and the savings amount, and clarifies that the new regime ignores old-regime deductions. It does not spell out assumptions or output field details, but it adds meaningful 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?

Two sentences, front-loaded with the computation and return, followed by a compact input rule. No repeated or filler content.

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 10-parameter tax comparison tool with no output schema, the description gives enough to select and call it: both regimes, same income, comparison output, recommendation, savings, and deduction asymmetry. The rich schema covers parameter detail, though exact response fields and assumptions are not spelled out.

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 the schema already documents all 10 parameters, including age band, NPS caps, house-property loss treatment, and deduction regime. The description only adds the high-level instruction to pass claimable old-regime deductions and that the new regime ignores them, which largely repeats schema notes. Baseline 3 applies.

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?

States a specific verb (Compute tax) and resource (both regimes for the same income) and names the return (side-by-side comparison, recommended regime, savings). The 'BOTH regimes' framing distinguishes it from the single-regime sibling compute_tax, even though that sibling is not named.

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 use case is implied: compare both regimes and get a recommendation. It also gives a deduction-input rule, but it never states when to choose this over compute_tax or when not to use it, and no alternatives or exclusions are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is fully consistent with a pure computation. It goes well beyond the annotations by defining the statutory formula, the salary composition (basic + retirement-forming DA + fixed-percentage turnover commission), period-wise treatment, and the metro list for FY 2025-26. It stops short of describing the result shape, which matters since there is no output schema.

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 information-dense sentences, front-loaded with the rule and formula, with constraints following. No wasted text, though the absence of line or clause breaks makes the metro list and 80GG caveat slightly harder to scan.

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 nested objects, a 12-item period array, and no output schema, the description does a good job covering input semantics and statutory constraints. The remaining gap is that it never says what the response contains (per-period breakdown, which limb was binding, final exemption amount), which an agent calling a compute tool would want.

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%, so the baseline is 3; the description earns an extra point by clarifying that amounts are per-period totals and by defining what 'salary' includes, which gives meaning to the optional daRetirement and turnoverCommission fields that the schema only labels. The 80GG mutual-exclusivity rule also disambiguates which parameter branch to populate.

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?

States a specific verb and resource ('HRA exemption per Rule 2A') and spells out the exact least-of formula being applied, plus the dual 80GG computation. An agent can immediately distinguish this from compute_tax or list_deductions without opening the schema.

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?

Explicit exclusions are given: 'Old regime only', and 80GG applies only to rent payers who received no HRA at any time in the year, with the two declared mutually exclusive. It does not, however, route to any sibling tool (e.g., compare_regimes for regime choice), so the when-to-use context is complete but not alternative-aware.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and closed-world behavior, but the description adds substantial context: deterministic computation, Rule 119A rounding, part-month-equals-full-month treatment, and the conditional 'skipped' output. It does not contradict the annotations and goes well beyond them, though the full return shape is not described.

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 dense but front-loaded by section, with each sentence carrying statutory information. It could be more scannable with bullets, but it does not waste words and is appropriately sized for a complex tax calculation.

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 an 11-parameter computational tool with no output schema, the description explains the legal logic well but leaves the response structure largely unspecified beyond the existence of a `skipped` list. An agent would still need to infer the shape of returned interest amounts and totals.

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%, so the baseline is 3, but the description adds interpretation not present in the schema: the 90% advance-tax threshold for 234B, the 12%/36% safe harbors for 234C, and the Rule 119A rounding convention. These details help an agent understand how the supplied parameters are actually applied.

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 names the exact resource (sections 234A, 234B and 234C interest) and a specific verb (compute), and distinguishes itself from generic siblings through statutory detail. An agent can tell this is a specialized interest calculator rather than a general tax or scheduling tool.

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?

Usage is implied by the section-specific rules and the note that each section runs only when its inputs are supplied. However, it never explicitly says when to choose this over compute_tax, schedule_advance_tax, or filing_checklist, nor does it state any when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely useful behavioral context beyond that — deterministic execution from a versioned rule pack and 'never estimated', which tells the agent the numbers are reproducible and not LLM-fabricated. It stops short of describing validation failures, rounding/unit behavior on output, or what happens for unsupported FYs.

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?

Front-loaded with the purpose before the parenthetical breakdown, and every clause names a distinct rule that matters. It is a dense wall of parentheticals, though, and one or two items (e.g. the cess percentage) are arguably detail an agent does not need to choose or call the tool.

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 an 11-parameter, high-complexity tool with no output schema, the description explains inputs thoroughly but says nothing about the return payload — no indication of whether it returns a breakdown (taxable income, slab tax, rebate, surcharge, cess, effective rate), a carry-forward figure, or a comparison. An agent cannot tell what it will get back or how to read it.

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%, so baseline is 3; the description earns above baseline by disclosing cross-parameter statutory interactions the schema cannot express — rebate threshold tested on TOTAL income, rebate never offsetting 111A/112A under the new regime, the 15% surcharge cap on gains, and the 115BAC carve-outs affecting deductions and housePropertyLoss. It does not map semantics per parameter name, so not a 5.

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?

Opens with a specific verb+resource and scope ('Deterministic Indian income tax computation for a fiscal year'), then enumerates the exact statutory mechanics covered (regime slabs, 87A rebate, 111A/112A, surcharge, cess). An agent can distinguish this from compute_hra, compare_regimes, and compute_interest_234 without opening the schema.

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?

Scope is richly implied by the enumeration of covered computations, but there is no explicit routing statement such as 'use compare_regimes to decide which regime, then call this'. Notably it never says whether HRA-exempt salary should already be netted out of salaryIncome before calling (a sibling compute_hra exists), nor any prerequisites/ordering against parse_form26as or parse_ais.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real context beyond the annotations: processing is on-device (consistent with openWorldHint=false), the decryption scheme is reverse-engineered and may fail, and the return payload is described. Missing are error semantics for a wrong password or malformed JSON, which matter for a tool whose own description admits fragility.

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?

Four tight sentences, front-loaded with the action and privacy property, then credentials, then return shape, then fallback. The fallback/issue sentence is slightly operational-tangent but still earns its place as recovery guidance.

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?

With no output schema, the description correctly carries the return-shape burden ('taxpayer info and normalized information rows... with amounts, dates, and codes'). Combined with the fragility disclosure, an agent has enough to call it and to interpret partial failures, though failure-mode behavior remains unspecified.

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% and the schema already documents the overrides relationship for password. The description restates the pan+dob derivation hint but adds no format or edge-case detail (e.g., non-individual DOB handling, PAN case sensitivity) beyond what the schema provides. Baseline 3 applies.

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?

States a specific verb pair and resource ('Decrypt and parse the AIS JSON export from the income tax portal') plus scope ('entirely on-device'). The document-specific framing (AIS JSON, not Form 26AS) lets an agent distinguish it from the sibling parse_form26as without opening either schema.

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?

Explains the two credential paths ('provide pan + dob to derive the password, or pass it explicitly') and gives an explicit failure path (fall back to the portal's CSV export, file an issue). It does not explicitly route between this and parse_form26as when a user has both documents, which keeps it below a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only readOnlyHint/openWorldHint, and the description adds substantial extra context: TCS rows are split out into tcsEntries, creditableTdsDeposited counts only status F rows while the raw total is reported separately, and the DOB-password/PDF-unsupported constraints. That is exactly the kind of non-schema behavior an agent needs.

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, all load-bearing: the first defines the transformation and output shape, the second flags the creditable-vs-raw distinction, the third states how to obtain a valid input. Nothing is redundant.

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?

No output schema exists, yet the description still describes the return structure (TDS entries with deductor/TAN/section/amounts/status, totals, separate tcsEntries, creditableTdsDeposited). Combined with the single fully-described parameter, an agent has everything needed to call it correctly.

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?

Only one parameter, and the schema already documents it at 100% coverage as an absolute path to a .txt file. The description adds the qualifying constraint that it must be the TRACES Text export, not a PDF, which meaningfully narrows the accepted input 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?

States a specific verb (Parse) and a precise resource (caret-delimited Form 26AS TEXT export from TRACES) and enumerates the extracted fields, so it is immediately distinguishable from parse_ais and reconcile_documents.

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?

Gives concrete preconditions: download the 'Text' format from TRACES, the archive password is your DOB as DDMMYYYY, and PDF exports are explicitly unsupported. It does not name sibling alternatives (e.g. parse_ais) or say when another tool would be preferred, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe read (readOnlyHint=true, openWorldHint=false), and the description adds substantive behavior beyond them: it explains the Schedule CFL loss-continuity rule, the 44AD/44ADA turnover ceilings when presumptiveTurnover is supplied, the AY 2026-27 two-house allowance, and that it returns reasoning plus statutory deadlines and the 234F fee. With no output schema, this is exactly the disclosure an agent needs to trust the result.

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?

Dense but front-loaded: the recommendation target comes first, then the disambiguating rules, then the return payload. Four long sentences are justified by 25 parameters, though the deadline/fee sentence could be trimmed since it describes output rather than invocation.

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 25-parameter tool with no output schema, the description covers the decision rules and the shape of the response well. Minor gaps remain: the fy parameter's default and AY mapping are left entirely to the schema, and there is no note on what happens with conflicting flags.

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%, so the baseline is 3. The description earns above that by explaining cross-parameter semantics the schema only hints at: brought-forward business/speculative losses forcing ITR-3 even at zero current-year income, presumptiveTurnover triggering a ceiling test, and the interaction between houseProperties and the two-property allowance.

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?

States a specific verb and resource ('Recommend ITR-1/2/3/4') plus the exact input domain (income heads, residency, losses, disqualifier flags). No sibling tool does form selection — compute_tax, compare_regimes, and filing_checklist are clearly different jobs — so the agent can route without ambiguity.

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?

Scope is clearly bounded to 'an individual' and it names the triggering conditions (loss continuity, presumptive turnover, house-property allowance) that change the answer. It stops short of naming when to prefer a sibling (e.g. use compute_tax after choosing a form) or stating explicit exclusions such as non-individual filers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value beyond that by disclosing that missing inputs yield skipped checks rather than errors, and that output includes per-income-head grouping of 26AS TDS. It stops short of describing the result shape or how mismatches are counted/severity-ranked.

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?

Front-loaded with the purpose and the regulatory rationale (143(1)(a)/139(9)), then a compact enumeration of checks. It is dense and long-ish but nearly every clause names a distinct check or behavior, with little filler.

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 read-only, no-output-schema, all-optional-params tool, the description covers purpose, all checks, and degenerate-input behavior. The main gap is that the return value's structure (fields of the mismatch report) is only implied by naming, not stated.

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%, so the schema already documents all five parameters including the nested AIS/Form 16/26AS/return shapes. The description adds only the semantic framing of 26AS as "the ledger of record" and notes which document each check consumes; the fy parameter and the specific field mappings are left entirely to the schema. Baseline 3 applies.

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?

States a specific verb-like operation (cross-document mismatch report) and enumerates the exact checks performed: TDS claimed vs 26AS deposited, missing-employer detection, AIS vs declared, Form 16 vs 26AS per-TAN, and 26AS rows missing gross. This is clearly distinguishable from siblings like parse_form26as or parse_ais, which produce inputs rather than reconcile them.

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?

"Pass whichever documents you have; checks needing missing inputs are reported as skipped" gives clear operating context and explains partial-input behavior. It does not explicitly name the sibling parse tools as the source of the inputs or state when not to use it, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds useful behavioral context: it discloses the output (per-installment amounts and shortfalls against paid-so-far) and the calculation basis (net of TDS).

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 two compact sentences with no waste. The core function and schedule are front-loaded, followed by the reported output.

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 read-only, four-parameter tool with full schema coverage, the description is nearly complete: it explains the calculation basis, installment schedule, and return content. Minor gaps remain around edge cases such as omitted paidSoFar or FY-specific behavior, but nothing critical is missing.

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%, so the schema already documents all four parameters, including paidSoFar ordering and fiscal-year format. The description adds only the net-of-TDS framing and installment percentages, so the baseline of 3 is appropriate.

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 states a specific verb and resource: 'Build the advance tax installment plan'. It also specifies the schedule (Jun/Sep/Dec/Mar at 15/45/75/100%) and the net-of-TDS basis, making it clearly distinguishable from a generic tax computation tool.

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?

It gives implied usage by saying the plan is built 'for an estimated tax liability net of TDS', but it does not explicitly say when to use this instead of siblings such as compute_tax or what prerequisites are required. The compute_tax-first guidance appears only inside the schema, not the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.