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

Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered. The description adds a genuinely useful behavioural default beyond the structured fields: 'without them every instalment is treated as unpaid', clarifying the consequence of omitting advance_tax_paid. It does not describe output shape, but an output schema exists.

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, purpose front-loaded, then the instalment rules, then the default-behaviour caveat. Dense but nearly every clause carries information; the parenthetical deadline list is compact. Slightly crowded but no 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?

With an output schema present the description needn't explain return values, and annotations cover the safety profile. The description supplies the statutory rules and the key default (unpaid instalments) needed to invoke the 9-parameter tool correctly, so nothing essential is missing for a read-only calculator.

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 baseline is 3 and the schema carries the parameter detail. The description nonetheless adds domain meaning the schema lacks, namely the instalment percentages and deadlines (15%/45%/75%/100%) and the presumptive 44AD/44ADA single-instalment rule, which help the agent reason about the parameters.

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 ('Calculate') and resource ('Indian advance tax instalments and the interest for late or short payment') with statutory grounding in Sections 234A/234B/234C and 207-211. An agent can distinguish this from the sibling tax tools (tax_in, tds, tcs, gst_regular) without opening any 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?

Explicitly tells the agent to 'Pass the payments actually made and the filing date to get the interest', which is actionable guidance on inputs. It also lays out the deadline schedule so the agent understands what the tool models, but it stops short of naming when to prefer a sibling (e.g., tax_in for a plain income-tax computation) or any explicit exclusion.

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 readOnly, idempotent, non-destructive, closed-world, so 'deterministic, idempotent, zero side effects' partly restates structured data. However, the description adds real behavioral substance: pricing is modeled per million input/output tokens, cache discounts up to 95% and batch discounts at 50% are applied, and a freshness tiering system (FRESH <14d, AGING 14-30d, STALE >30d) governs rate-pack resolution.

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 text is front-loaded and organized into labeled Behavior and Usage Guidelines sections, with no filler. It runs somewhat long for a single-function calculator, and a minor typo ('pack age') slightly blunts polish, but every sentence carries information.

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 an output schema present, rich annotations, and 100% schema description coverage, the description only needs to supply purpose, behavior, and routing — all of which it does, including the sibling exclusion. Nothing an agent needs to invoke this correctly 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 description coverage is 100% (including camelCase aliases), so the baseline is 3. The description goes beyond the schema by quantifying the economics behind the parameters — the up-to-95% cache discount tied to cache_hit_ratio and the 50% batch discount tied to is_batch — which gives the agent a reason to set those values.

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 uses specific verbs and resources — calculate multi-provider LLM inference token costs, prompt caching economics, batch API savings, and cross-model cost disparity — and names the actual providers. An agent can distinguish this from generic finops siblings 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?

It gives explicit positive triggers (budgeting agent inference costs, evaluating LLM providers, deciding on caching or batch inference) and an explicit negative routing rule: 'Do not use for cloud network egress; use cloud_egress_finops instead.' The alternative is named by exact tool.

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 readOnly, idempotent, non-destructive and closed-world, so 'deterministic, idempotent, zero side effects' is partly redundant. What is not redundant is the disclosed solution chain (Gross - Expenses - Health - SECA - Income Tax = Target Net Cash) and the derivation of the hourly floor from actual billable hours, which tells the agent how the number is produced rather than just that it is safe.

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 core computation before the behavioral block and the usage routing; the labeled Behavior/Usage structure makes it scannable. It runs a bit long and restates safety traits the annotations already carry, but no sentence is filler in a way that harms selection.

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 an output schema present, rich annotations, and 100% schema coverage, the description only needs to add algorithmic intent and routing, and it does both. The agent knows what the tool computes, when to pick it, and which sibling to prefer otherwise.

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 every parameter is already documented in the schema; the baseline is 3. The description loosely maps its listed factors onto parameters (unpaid weeks -> vacationWeeks, admin drag -> nonBillablePercent, health -> healthInsuranceAnnual), but adds no units, formats or defaults beyond what the schema already states.

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 precise verb+resource: solve the minimum billable hourly rate to hit a target net cash income, and enumerates the factors it accounts for (unpaid weeks, admin drag, overhead, health insurance, SECA). It explicitly distinguishes itself from contractor_parity, so an agent can route correctly 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?

Gives an explicit use case (freelancer/consultant/agency owner setting a baseline lifestyle-supporting rate) and an explicit exclusion with the named alternative: do not use for benchmarking against a W-2 salary offer, use contractor_parity instead.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the numerical precision posture (ordinary floating-point, no dated rate table, not passed the full reference-test suite) and the exact formulas used, which the agent could not infer from 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?

Front-loads the precision caveat, then behavior/formulas, then usage routing, which is a sensible order. It is somewhat long and 'Deterministic, idempotent calculation with zero external side effects' partly repeats the annotations, but most sentences carry distinct information.

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?

An output schema exists, so return values need no elaboration, and the description still notes a detailed breakdown is returned. Combined with the formulas, the optional expectedUnitsSold behavior (margin of safety and DOL only when supplied), and the precision caveat, nothing needed to call it correctly 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 description coverage is 100%, so the schema already documents all four parameters and their constraints (e.g., unitPrice must exceed unitVariableCost). The formulas restate how inputs relate but add no syntax, format, or edge-case detail beyond the schema, so the 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 (calculate) and a precise resource set: break-even thresholds in units and revenue, contribution margin ratio, margin of safety, and degree of operating leverage. It also names the sibling it is not (billable_floor), so an agent can distinguish it without opening schemas.

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 explicit when-to-use domains (pricing strategy, manufacturing and SaaS unit economics, operational risk appraisal) and an explicit when-not with the correct alternative: 'Do not use for hourly freelance billing rate minimums; use billable_floor instead.' Routing is unambiguous.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered; the description's 'deterministic, idempotent, zero external side effects' sentence is partly redundant with that. It does add genuine value by disclosing the exact computational relations (Fisher equation, ln(2)/ln(1+Nominal)) and the returned metrics, which the annotations cannot convey.

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 tool's purpose, then behavior, then usage routing in distinct labeled blocks. The formula clauses are dense but arguably earn their place for a math utility; the sentence count is modest and there is no 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?

An output schema exists, so explaining return values is technically unnecessary, yet the description still enumerates them (nominal CAGR %, real CAGR %, gains, doubling years) for clarity. Combined with annotations covering safety and idempotency, an agent has enough to call the tool correctly, though PROJECTION mode usage is left entirely to the schema.

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 all seven parameters, including the mode enum and the PROJECTION-only expected_annual_return_rate, are already documented in the schema. The description implies how initialValue, finalValue, periodsYears and inflation combine mathematically, but never mentions 'mode' or the projection path, so it does not add parameter meaning 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 and resource (Compute CAGR, real inflation-adjusted growth, doubling time) and names the exact outputs produced. The usage section explicitly names the sibling tools compound_wealth and sip_investment it is not, so an agent can separate it from look-alike growth calculators.

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?

Provides explicit 'use for' contexts (historical portfolio track records, revenue growth, inflation drag) and an explicit 'do not use for' with the alternative tools to pick instead (compound_wealth, sip_investment). Nothing is left to inference.

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, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe, repeatable calculation. The description reinforces this with 'Deterministic, idempotent calculation with zero external side effects,' which is useful but largely redundant with annotations. It adds the pricing tiers and the return structure (monthly/annual gross, post-cache, net savings), which is extra context beyond annotations, but output schema likely covers return values. A 3 is appropriate: some added value but not deep behavioral disclosure.

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 structured into purpose, behavior, and usage guidelines, with clear front-loading of the core function. It is appropriately sized and every sentence contributes. It could be marginally tighter, but no sentence is wasted.

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 a read-only calculation with a full input schema, an output schema, and rich annotations, the description covers purpose, behavior, and routing well. The only minor gap is not explaining the structured refusal for missing price packs beyond what the schema already states. Overall, it is complete enough for correct invocation.

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 all four parameters are already documented in the input schema with descriptions, defaults, and enums. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 opens with a specific verb+resource: 'Analyze tiered AWS/GCP public cloud internet data transfer egress pricing versus Cloudflare Zero-Egress Bandwidth Alliance and edge caching proxies.' It distinguishes itself from all financial siblings by naming the exact cost domain (cloud egress) and even names the closest sibling, ai_token_arbitrage, to disambiguate.

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 guidelines are explicit: 'Use for cloud architecture budgeting, FinOps reviews, and evaluating CDN caching or Cloudflare migration economics.' It also provides an explicit exclusion: 'Do not use for LLM token pricing; use ai_token_arbitrage instead.' This is exactly the when-to-use/when-not-to-use/alternative structure that earns 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?

The annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the description's repetition of determinism and zero side effects adds little. However, it goes beyond annotations by disclosing precision limitations ('ordinary floating-point arithmetic,' 'no dated table of official rates,' 'not yet passed our full reference-test suite'), the exact formula used, and the return contents.

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 well-structured with clear sections for precision caveat, purpose, behavior, and usage. It is slightly less front-loaded because the precision caveat comes before the purpose, and the deterministic/idempotent/zero-side-effects sentence duplicates annotation data, but no sentence is seriously wasteful.

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, rich annotations, and an existing output schema, the description is complete enough: it covers purpose, usage boundaries, calculation method, precision caveats, and the alternative tool. An agent has everything needed to invoke 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?

Schema description coverage is 100%, so the baseline is 3. The description adds useful semantic mapping via the formula: P corresponds to principal, r to annualRatePercent, n to compoundFrequency, t to tenureYears, and PMT to monthlyDeposit, clarifying how the parameters interact.

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: 'Simulate long-term compound interest growth for retirement portfolios... with recurring monthly deposits.' It explicitly distinguishes itself from the sibling tool sip_investment for Indian mutual fund SIPs, so an agent can route correctly without inspecting schemas.

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 clear when-to-use guidance: 'Use for multi-year personal wealth projection and retirement nest-egg simulations.' It also gives an explicit exclusion and alternative: 'Do not use for Indian mutual fund monthly SIPs with annual step-up; use sip_investment instead.'

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the leading 'deterministic, idempotent, zero side effects' sentence restates structured data. However, it adds real context by enumerating the computational scope (FICA/SECA, QBI, 199A, 401k match, PTO, health subsidy) so the agent knows the breadth of what is modeled before invoking.

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 purpose sentence followed by clearly labeled Behavior and Usage Guidelines blocks. Length is proportionate to a 12-parameter, multi-domain tax engine and no sentence is 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?

With a full output schema, complete per-parameter descriptions, and annotations covering the safety profile, the description only needs to add scope and routing — which it does. Nothing an agent needs to call this correctly 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 description coverage is 100% with defaults and constraints documented per property, so the baseline is 3. The description adds no per-parameter meaning (e.g. no guidance on how as_of_date's rule pack or eligibleQBI interacts) beyond what the schema already documents.

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 (Calculate) and a precisely scoped resource (W-2 vs 1099 tax, benefits and net take-home parity), including the exact deliverable (breakeven $/hr). Clearly differentiated from the sibling billable_floor, which is named directly.

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 an explicit when ('deciding between a W-2 salaried offer and a 1099 contractor contract') and an explicit when-not with the named alternative ('do not use for solo freelancer baseline rate setting without a W-2 benchmark; use billable_floor instead'). The routing decision is fully determined from the description.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain behavior (statutory rule-pack analysis, Section 194A TDS thresholds of 40,000/50,000), but says nothing about rate limits, output shape, or precision/rounding behavior — a moderate but not rich addition.

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 core purpose before the TDS detail. Efficient overall, though the compounding-convention enumeration adds a claim that the schema does not support and could mislead.

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?

An output schema exists, so return values need no explanation, and the description covers purpose plus the TDS threshold behavior. The only gap is that it does not resolve the apparent mismatch between the listed compounding options and the schema's fixed quarterly enum.

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 carries parameter meaning and the baseline is 3. The description adds no per-parameter detail beyond what the schema states, and its claim of 'quarterly, monthly, half-yearly, and cumulative compounding' is not reconciled with the single-value enum in 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 and resource (calculate FD maturity amount and interest returns) and names the compounding and TDS computations performed. It is clearly distinguishable from siblings like ppf, sukanya, or sip_investment, though it never explicitly contrasts itself with 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?

There is no when-to-use / when-not-to-use guidance and no mention of alternatives among the many deposit/investment siblings. The agent must infer that this tool is the one for bank/corporate FDs rather than ppf or sukanya.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds calculation-specific behavior: it evaluates the 330-day threshold, applies the statutory cap, computes liability on excess, and flags sticky domicile states. It repeats the idempotent/read-only nature already in annotations, preventing a 5.

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 front-loaded with purpose and structured with explicit 'Behavior' and 'Usage Guidelines' labels, making it scannable. It is slightly redundant: the $130,000 2025 exclusion cap is stated in both the opening sentence and the Behavior section, which costs a perfect score.

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 an output schema present, the description need not explain return values. It covers purpose, usage, alternatives, and behavioral rules, while the schema fully documents all six parameters. Nothing an agent needs in order to call this tool correctly 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 description coverage is 100%, so the schema already documents all six parameters in detail, including enums, required fields, and legal citations. The description references the 330-day threshold and exclusion caps but adds no parameter semantics beyond what the schema provides. Baseline 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 gives a specific verb+resource: tracking IRS Form 2555 FEIE Physical Presence Test eligibility, statutory exclusion cap, and US sticky domicile risks. It explicitly distinguishes the tool from the sibling b2b_withholding_risk, so an agent can tell them apart without opening schemas.

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 states the exact audience (US citizen digital nomads and expats evaluating FEIE under Section 911), provides a clear exclusion (do not use for foreign corporate withholding tax), and names the alternative tool (b2b_withholding_risk). This is explicit when/when-not guidance.

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, idempotentHint and non-destructive, and the description partly restates that ('Deterministic, idempotent calculation with zero external side effects'). It adds genuine value by disclosing the key limitation that TrueCalci neither presets nor verifies provider pricing, so supplied fees are authoritative — an important caveat for interpreting results.

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 definition is front-loaded with purpose, then behavior, then usage, and each block earns its place. It is slightly long because the behavior sentence enumerates outputs that the output schema already covers, but there is no 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?

With a full input schema, an output schema, and rich annotations, the description only needs to add routing, the pricing caveat, and the computation intent — all of which are present. An agent has everything needed to select and 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?

Schema description coverage is 100%, so every parameter including the nested rail fields is already documented in the schema; baseline is 3. The description reinforces that rails carry the user's own account-specific fees and that the date selects the rule pack, but adds no syntax or format detail 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 states a specific verb and resource: comparing landed local currency from a USD invoice across named payment rails against the ECB reference rate. It names what is computed (net USD after fees, landed amount, cost share, ranking, best-vs-worst saving), which is far more specific than the title.

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 an explicit when-to-use ('freelancer or vendor invoicing in USD wants to compare payout providers whose fees they know') and a when-not-to-use with the named alternative ('Do not use for domestic US employee vs contractor parity; use contractor_parity instead'). This routes the agent unambiguously among siblings.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds context about computational behavior (statutory GST rate of 3%, supported karat levels, Indian regional units), which is useful but does not describe return format, rounding, or failure modes.

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?

A single sentence, front-loaded with the core action ('Calculate Gold and Silver commodity valuation') and then the components. Dense but efficient; each listed item carries information without padding.

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 pure calculation tool with full schema coverage and an output schema, the description scopes the computation adequately. However, it advertises 'Silver commodity valuation' while the schema exposes only gold inputs (weight_grams described as gold, rate_per_gram_24k), a capability mismatch that leaves the description incomplete relative to what the tool actually accepts.

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 five parameters with patterns, enum values, and defaults. The description lists the karats and units but adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Calculate Gold and Silver commodity valuation') and enumerates the computation components (purity adjustments, GST, making charges, unit conversions), making the tool's scope clear. It doesn't explicitly differentiate from siblings like land_units or gst_regular, so it falls short of a 5.

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?

Provides no when-to-use or when-not-to-use guidance and names no alternatives. The reader must infer that this is the tool for gold/silver valuation from the description alone, which is descriptive rather than directive.

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 establish it as read-only, idempotent, non-destructive, and closed-world. The description adds domain behavior by stating the applicable rates and that it enforces turnover thresholds, though it does not specify the failure mode when a threshold is breached.

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 core calculation and then the category, rate, and threshold details. Every clause carries information and there is no 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?

The tool is a deterministic calculation with a complete parameter schema, an output schema, and rich safety annotations. The description supplies the scheme, rates, and threshold enforcement so an agent can invoke it correctly; only alternative-tool routing is unaddressed.

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?

With 100% schema description coverage, the schema already documents each parameter. The description adds the rate mapping (1%, 1%, 5%) for the category parameter and reiterates the threshold-check purpose of preceding FY turnover, giving meaningful semantic lift beyond the enum.

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 (Calculate) and resource (statutory GST quarterly tax liabilities under the Composition Scheme), naming Section 10 and the three covered categories. This clearly separates it from a generic GST or regular-scheme calculator, even though it does not explicitly name the sibling gst_regular.

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 implies use for Composition Scheme taxpayers by repeatedly naming the scheme and statutory thresholds, but gives no explicit when-to-use, when-not-to-use, or alternative tool guidance. The context is enough to infer the intended audience, but routing guidance is absent.

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, idempotentHint, and destructiveHint=false, so part of the behavior sentence ('deterministic, idempotent, zero side effects') is redundant. What the description adds beyond structured data is the exact EMI formula, the rate convention (r = annualRate/12/100), and the scope of computed outputs, which meaningfully reduces ambiguity.

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 purpose, then clearly sectioned Behavior and Usage Guidelines. Slightly wasteful in restating the idempotency/side-effect profile already carried by annotations and in listing return fields that the output schema covers.

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 annotations covering safety and an output schema covering return values, the description supplies everything needed for selection: purpose, formula assumptions, and an explicit sibling alternative. Only minor gaps remain, such as how as_of_date's rule-pack selection can change results.

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 principal, rate, tenureYears default, and as_of_date. The description adds no parameter-level meaning beyond the formula's rate convention, so the 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+resource (calculate EMI, total interest, amortization) and scopes it to reducing-balance consumer loans. It explicitly positions itself against the sibling mortgage_piti, so an agent can distinguish the two 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?

Gives an explicit when-to-use ('general global reducing-balance loans and consumer debt') and an explicit when-not-to-use with a named alternative ('US residential mortgages requiring property tax, hazard insurance, and PMI escrow; use mortgage_piti instead'). This is the strongest form of routing guidance.

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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds critical context beyond annotations: deterministic conversion, refusal rather than guessing when state is missing for regional units, and the exact return composition (target value, square-foot baseline, 7-unit breakdown). This is rich behavioral disclosure.

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 front-loaded with purpose and then organized into Behavior and Usage Guidelines sections. It is somewhat long, especially the state list, but every part is relevant and well-structured. It avoids redundancy and keeps the core usage rule easy to find.

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, the description covers the legal context, conditional state requirement, universal-vs-regional distinction, and return shape. An output schema exists, so return values need not be fully explained, but the description still summarizes them helpfully. Nothing an agent needs to call the tool correctly 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 description coverage is 100%, so the schema already explains area, state, to_unit, from_unit, and as_of_date. The description reinforces that state is required for regionally ambiguous units and that to_unit omission returns all standard units, but these points are already present in the schema. It adds little new syntactic or semantic detail 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 states a specific verb and resource: 'Convert Indian regional and universal land measurement units.' It distinguishes regional from universal units and names the governing legal framework, making the tool's scope immediately clear. Sibling tools are all finance/tax calculators, so no further differentiation is needed.

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 gives explicit usage guidance: 'Specify state when converting traditional units (e.g. bigha or katha) to avoid ambiguous multi-fold variance.' It also implicitly frames usage under the Legal Metrology Act and State Land Revenue Codes. However, it does not state when not to use the tool or name alternatives, which is reasonable given the lack of sibling overlap.

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 readOnly, idempotent, non-destructive and closed-world, so the description's 'deterministic, idempotent, zero side effects' line is largely redundant. However, it adds genuinely new behavioral detail: PMI is applied automatically below 20% down until the 78% LTV threshold, and it discloses the calculation basis (fixed-rate annuity, tax/12, monthly insurance). That is useful beyond the annotations, though the repetition of annotation-covered traits keeps it from a 5.

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 clearly labeled sections (description, Behavior, Usage Guidelines) with the purpose front-loaded. Efficient overall, but the Behavior paragraph spends a clause restating annotation-provided traits (deterministic/idempotent/no side effects) that the agent already sees in structured form.

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?

An output schema exists, so return values need not be detailed, yet the description still previews the outputs (monthly total, P&I split, escrow components, lifetime interest, payoff schedule). Combined with the routing guidance and PMI rules, nothing an agent needs to invoke this correctly 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 baseline is 3, but the description adds cross-parameter meaning the schema does not: downPaymentPercent below 20 automatically triggers PMI, and PMI persists until 78% LTV. That explains the interaction between downPaymentPercent and annualPmiPercent rather than merely restating them.

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 (Calculate) and resource (monthly US mortgage PITI payments) and enumerates the components. It explicitly contrasts itself with home_loan_emi, so an agent can distinguish it from siblings without opening any 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?

Gives explicit when-to-use (US residential purchase and refinancing) and when-not-to-use (international reducing-balance loans without escrow/PMI), naming the alternative tool home_loan_emi. The routing condition is unambiguous.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the restated 'deterministic, idempotent... zero external side effects' sentence earns no credit. What does add value is the method transparency (Newton-Raphson with up to 100 iterations, tolerance 1e-7), the exact NPV formula, and the honest precision caveat that it uses plain floating-point and hasn't passed the full reference-test suite.

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?

Bold-labelled sections (Behavior, Usage Guidelines) make it scannable, and the usage contract is tight. It is slightly padded — the leading precision disclaimer sits ahead of the purpose statement, and the behavioral sentence partly restates annotations.

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?

An output schema exists, so return values needn't be spelled out, yet the description still names them (NPV, IRR percentage, PI, payback period). Combined with formula, convergence behavior, precision caveat, and a routing alternative, an agent has everything needed to call this 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?

Schema description coverage is 100%, so the schema already explains initialInvestment, cashflows, and discountRatePercent semantics and units. The description adds conceptual context (rate where NPV equals zero) but no parameter-level syntax or format detail beyond the schema, so 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 specific verbs and resources: 'Compute Net Present Value (NPV), Internal Rate of Return (IRR)... and discounted payback period' for capital budgeting. This clearly differentiates it from sibling compound_wealth, which it names explicitly for a different use case.

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 explicit when-to-use contexts ('capital investments, M&A valuations, corporate projects, and multi-year cash flow hurdle rates') and an explicit exclusion with the alternative ('Do not use for simple compound interest projections with fixed monthly deposits; use compound_wealth instead').

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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds valuable context beyond that: it is free/no-credit and returns active rate tables, hash checksums, and legal citations, though it does not discuss pagination or output limits.

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 front-loaded sentences with no filler. The first states the core purpose and free status; the second details the returned content, and nothing is wasted.

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 annotations covering safety, schema covering the only parameter, and an output schema present, the description provides enough for correct invocation. It could be slightly stronger by clarifying when engineId should be omitted versus supplied, but overall it is complete for this metadata tool.

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 schema has 100% description coverage for the single optional engineId parameter, including examples and its purpose. The description itself adds no additional parameter semantics beyond what the schema already provides, so the baseline of 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?

The description gives a specific verb and resource: it lists the official rate tables each calculator uses and shows active government rate tables, checksums, and legal citations. It is clearly distinguishable from the calculator siblings, though it does not explicitly name an alternative or sibling.

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 notes the tool is free with no credits, which is useful usage context, but does not state when to use this status tool versus the calculator tools or when it is unnecessary. The intended use is implied rather than explicit.

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 declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered; the description adds substantial domain behavior beyond that — the ₹1,50,000 ceiling, 7.1% rate, monthly 5th-day compounding rule, and Section 80C EEE treatment. It doesn't disclose error or edge-case handling (e.g., deposits exceeding the ceiling), keeping it below 5.

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?

A single dense sentence that front-loads purpose and then stacks the governing rules; nothing is wasted. It is slightly packed, but every clause carries domain value.

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 an output schema present, return values need not be explained, and the description covers the rule pack, rate, ceiling, and tax treatment. What remains missing is routing guidance among sibling instruments, which is a minor gap for a self-contained simulator.

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 three parameters, including the date's rule-pack semantics and tenure extension. The description adds the deposit ceiling and rate context but no new parameter-level syntax or format detail. Baseline 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?

Names a specific verb (Simulate) and resource (Public Provident Fund 15-year statutory compound wealth accumulation), scoping it to Ministry of Finance rules. An agent can distinguish it from fd, sukanya, and compound_wealth 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?

The description implies the usage context (Indian sovereign savings scheme simulation) but never states when to choose this over close siblings like fd, sukanya, or compound_wealth, nor any exclusions. Usage is inferable but not directed.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description goes further by disclosing the compounding formula, the step-up mechanic (installment increases each 12-month cycle), and the returned fields. It adds genuine behavioral context beyond the structured metadata, though the deterministic/idempotent restatement is partially redundant.

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 core purpose, then organized into Behavior and Usage Guidelines sections with zero filler. Slightly verbose in enumerating return fields that the output schema already carries, but overall 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?

Covers purpose, mechanics, the step-up edge case, return composition, and sibling routing; with an output schema present, return values need not be detailed yet are still summarized. Nothing an agent needs to call this correctly 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 description coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: it explains that stepUpPercent triggers a dynamic increase every 12 months and that as_of_date selects the rule pack in force. These meaningfully clarify how the parameters interact.

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 (calculate SIP mutual fund maturity wealth) with a named optional behavior (annual step-up). It distinguishes itself from the sibling compound_wealth explicitly, so an agent can route 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?

Gives clear when-to-use (mutual fund SIP, recurring deposits, goal-based planning) and an explicit when-not-to-use with the named alternative ('Do not use for US 401(k) / Roth IRA compounding with lump sum; use compound_wealth instead'). This is the strongest form of routing guidance.

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, idempotentHint, and no destructive/open-world behavior, so the sentence restating determinism and zero side effects earns no extra credit. The description does add real behavioral substance beyond the annotations: the deferral caps ($23,000 / $30,500 age 50+), employer profit-sharing math (20% of adjusted net earnings vs 25% of W-2 salary), and the statutory additions cap that governs 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?

The definition is front-loaded and organized into Purpose, Behavior, and Usage Guidelines blocks with no filler. It is dense for a single tool but each sentence, including the formulas, contributes to correct 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?

With six parameters, full schema coverage, rich annotations, and an output schema present, the description supplies everything an agent needs to decide and call correctly; return-value explanation is correctly left to the output schema.

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% and the schema descriptions are unusually rich (entityType caveat, as_of_date rule-pack selection, deprecated isAge50Plus, participant_age catch-up rationale), so the schema carries the parameter burden. The description reinforces the age/entity/rate inputs implicitly through the formula but adds no syntax or format detail 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 names a specific verb and resources: it compares Solo 401(k) and SEP-IRA contribution limits for a given tax year and computes the income-tax reduction from the pre-tax portion. The scope (owner-only retirement contribution optimization) is clear enough to separate it from siblings like scorp_optimizer or compound_wealth.

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 states explicit when-to-use (owner-only business, independent contractor, or partner optimizing pre-tax retirement deductions) and a when-not with a named alternative: multi-year compound growth modeling should use compound_wealth instead. Routing is unambiguous.

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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds substantial beyond that: deterministic calculation, zero external side effects, and concrete formulas for net burn, runway, SAFE equity percentage, and option pool dilution.

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 front-loaded and structured into purpose, behavior, and usage guidelines. Despite its density, each section adds necessary information for a complex multi-parameter financial model.

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?

The input schema is fully documented and an output schema exists, so return values need not be explained. The description supplies the purpose, behavioral model, formulas, and usage exclusions needed to call the tool 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?

Schema coverage is 100%, so the baseline is 3. The description goes further by naming relationships among parameters, such as net burn = grossBurn - revenue and SAFE equity = safeInvestment / postMoneyCap, which helps an agent reason about how inputs interact.

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 uses specific verbs and resources: models startup cash runway, Post-Money SAFE cap dilution, and Series A option pool expansion. It clearly distinguishes this tool from the explicitly named sibling npv_irr.

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 explicit when-to-use cases (venture capital fundraising planning, runway tracking, cap table dilution modeling) and an explicit when-not-to-use exclusion with the alternative tool (npv_irr for DCF or IRR).

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds domain behavior (compounding rate, 21-year maturity, Section 80C EEE exemption), but hardcoding '8.2% p.a.' sits uneasily with the schema's statement that as_of_date selects the governing rule pack, which could mislead on historical/future dates.

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 dense sentences, front-loaded with the purpose and followed by the mechanics. No filler, though the second sentence packs rate, maturity and tax treatment into a single clause.

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?

An output schema exists, so return values need no explanation, and the schema fully documents inputs. The main gap is the absence of when-to-use/routing guidance against the many sibling financial calculators.

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% – all three parameters, including the ₹250–₹1,50,000 deposit band and the under-10 age constraint, are documented in the schema. The description adds no parameter-level detail beyond that, so the 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?

Names a specific verb ('Simulate') and a specific resource (Sukanya Samriddhi Yojana), including the girl-child scope, 8.2% rate and 21-year maturity. This clearly separates it from siblings like ppf or fd, though it never explicitly contrasts itself with 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?

The description says nothing about when to use this tool versus alternatives such as ppf or compound_wealth, nor about prerequisites (e.g., account-opening age limits are only in the schema). Usage is only inferable from the scheme name.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: which statute applies at a given date, what each regime models (standard deduction, 87A rebate vs Chapter VI-A), and that the lower liability is reported.

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 tight sentences, front-loaded with the core action, then the date/statute rule, then the regime switch. No filler or 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?

All five parameters are schema-documented, an output schema exists so return values need not be described, and the one non-obvious semantic (date-driven statute selection) is explained. Nothing an agent needs to invoke it correctly 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 baseline is 3, but the description adds semantic links the schema does not: as_of_date maps to the applicable Act and regime maps to single-vs-dual computation. It does not add numeric examples or format hints for gross_income 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+resource ('Compute Indian personal income tax') plus scope (dual-regime comparison for the tax year in force on as_of_date). The regime-comparison behavior and 'naming the lower one' clearly separate it from siblings like advance_tax, tds, and gst_regular.

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 that as_of_date selects the governing Act and that passing regime narrows to a single computation, which tells the agent how to steer the call. It stops short of stating when not to use it or naming an alternative sibling, so it is clear context without explicit exclusions.

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, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds domain context (Section 206CC higher rates, the date-selected rule pack) but discloses no additional behavioral traits such as refusal modes, error handling, or thresholds beyond the s.206C(1H) ₹50 lakh mention.

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 core verb and statute, then a single compact enumeration of covered natures; nothing is redundant. The list is long but each item maps to a distinct section/rate, so it 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?

With an output schema present, return values need no explanation, and annotations plus 100% schema coverage carry the safety and parameter burden. The description supplies adequate statutory scope; only explicit usage/routing guidance 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 description coverage is 100%, so the enum values, the required 'amount'/'as_of_date' constraints, the PAN-status refusal behaviour and the 'nature' alias are all documented in the schema itself. The description adds no parameter-level detail beyond what structured data already supplies, making 3 the correct baseline.

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 ('Calculate statutory Tax Collected at Source (TCS)') and pins the exact statutory basis (Section 206C, AY 2025-26), then enumerates the covered collection natures. An agent can distinguish this from the sibling 'tds' (deducted vs collected at source) purely from the description.

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 statutory scope, but the description never states when to prefer this tool over alternatives ('tds', 'tax_in', 'gst_regular') or the preconditions for a valid call. It gives context for interpreting the result without routing guidance.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful domain behavior beyond annotations: higher deduction rate under Section 206AA for missing PAN and precedence evaluation between 194Q and 206C(1H). It stops short of disclosing the refusal for non-resident payments (that appears only in the schema), but still contributes useful behavioral context.

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 sentences, front-loaded with the core purpose, followed by supported sections and special rules. Every clause earns its place, and there is no redundant or filler content. It is appropriately sized for a complex statutory calculation 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?

Given the complexity, rich schema, annotations, and existing output schema, the description covers the essential scope (Act, assessment year, supported sections, key rules). It does not mention the out-of-scope handling for non-resident payments or the mandatory date selection, but those details are fully documented in the schema. The description is largely complete, with only minor contextual gaps that the structured fields already fill.

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 structured schema already documents all seven parameters in detail. The description adds no parameter-level syntax, format, or constraint information beyond what the schema provides. A baseline score of 3 is appropriate when the schema does the heavy lifting.

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 ('Calculate') and resource ('Tax Deducted at Source') within a precise legal context (Indian Income-tax Act, 1961, AY 2025-26). It lists the supported sections, which clearly distinguishes it from siblings like tcs or gst_regular. An agent can immediately tell this is a statutory TDS calculator for India.

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 usage by enumerating supported sections and special rules (missing PAN, 194Q vs 206C(1H) precedence), but it never explicitly states when to choose this tool over alternatives such as tcs or advance_tax. There is no 'when-not-to-use' or sibling routing guidance. The schema descriptions carry the burden of prerequisites and refusals, so the description's guidance is minimal but not absent.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds the actual arithmetic in both modes and the 2-decimal rounding of returns, which is genuinely behavioral detail beyond the annotations. The 'statutory rate verification' claim is slightly opaque given the rate arrives as a user-supplied parameter.

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 purpose, then clearly labelled Behaviour and Usage Guidelines sections. The formulas are slightly verbose but each conveys a distinct, load-bearing fact; no filler sentences.

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 single-purpose calculator with an output schema (so return values need no prose) and full parameter coverage, the description supplies modes, formulas, rounding and usage scope. Minor gaps remain around the statutory rate source implied by 'verification' and differentiation from the GST/income-tax siblings.

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 amount, vatRatePercent, as_of_date and the mode enum. The description's parameters section adds only marginal mapping (net vs gross meaning of amount per mode) and no new syntax or format detail beyond the schema, so 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 and resource ('Calculate European Value Added Tax (VAT) and global sales taxes') plus the add/remove mode scope. However, it does not differentiate against the actual tax siblings in this namespace (gst_regular, gst_composition, tax_in, tcs, tds) – its only named alternative, tip_splitter, is not a sibling 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?

Gives explicit use contexts (e-commerce, international invoicing, retail pricing, VAT compliance) and an explicit exclusion with an alternative ('Do not use for restaurant tipping and bill splits; use tip_splitter instead'). The exclusion targets a tool outside the sibling set, so it does not help the agent route among the real tax siblings.

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