DecisionsCalc calculators

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 clear and the description carries less burden. The description usefully pins the assessment period (1 April 2026 – 31 March 2027) and the tax year (2026–27), which the annotations do not. It says nothing about the shape of the result (rebate percentage? surcharge amount? net saving?), which is the main remaining gap.

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 with no filler; the country, the periods, and the varying dimensions are front-loaded. It is information-rich rather than padded, though the stacked clauses make it slightly heavier than needed.

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 six-parameter calculator with no output schema, the description covers scope and period but not what fields come back or how the two interacting calculations (rebate vs surcharge) relate. Adequate to select the tool, but an agent still has to open the schema and infer the return value.

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 six parameters (age, family, income, premium, children, hasCover) are already documented in the schema. The description confirms the key axes (income tier, single or family, age band) but adds no unit, format, or threshold detail beyond what the schema supplies. 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 resource (private health insurance rebate plus Medicare Levy Surcharge) and names the dimensions it varies on: income tier, single/family, and age band. It also frames the answer as 'whether hospital cover saves you tax', so an agent knows what the tool computes. It doesn't differentiate itself from named siblings, but the jurisdiction-prefixed naming makes the family separations obvious.

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 closing phrase 'whether hospital cover saves you tax' implies the use case (comparing having cover vs paying MLS), but there is no explicit when-to-use guidance, no prerequisites, and no mention of which sibling tool to pick for a different country's benefit question.

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 this is a read-only, closed-world computation, so the safety bar is low. The description goes beyond them by disclosing the substantive modeling assumptions: the two rate tiers, the weekly maximums, the 15-week maternity component, and the one-week waiting period that reduces payable weeks. What it does not disclose is how standard and extended parental weeks interact in 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?

One dense sentence with no filler, and the jurisdiction/scope constraint is front-loaded before the rate details. The phrase 'parental weeks' is left dangling without a number, which costs a little clarity for the sake of brevity.

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 four-parameter estimator with no output schema, the description supplies the rate structure and caps but omits the total maximum weeks (40 standard / 69 extended) and how mixed standard/extended claims are treated. An agent can select the tool confidently but cannot predict the returned figure without reading the schema closely.

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 each of the four parameters (annualIncome, includeMaternity, extendedParentalWeeks up to 61, standardParentalWeeks up to 35) is already documented. The description adds the rate ceilings that give those week counts meaning, but it does not clarify how the two parental-week inputs combine or whether they can be used together, leaving the semantics to 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 the specific benefit program (EI maternity and parental), the jurisdiction ('Canada (outside Quebec)'), and the rate mechanics it models (55% up to $729/week, 33% up to $437, 15 maternity weeks, one-week waiting period). This clearly separates it from quebec_qpip. It falls short of an explicit verb like 'calculates' for a given income, but the resource and scope are unmistakable.

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 '(outside Quebec)' qualifier implicitly routes Quebec users to quebec_qpip, which is useful. However, there is no explicit when-to-use guidance, no mention of related siblings such as parental_leave_income_gap or ireland_maternity_leave_pay for comparison, and no statement of prerequisites or typical caller intent.

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 real value by scoping the calculation to specific tax heads and stating the result is 'line by line' itemized, which partly compensates for the missing output schema. It does not disclose assumptions, exclusions, or what happens with unsupported status/pay combinations.

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?

One dense sentence, front-loaded with the jurisdiction and the core comparison, with the component list in a compact parenthetical. No filler, though the leading 'Ireland:' label and trailing 'line by line.' are slightly fragmentary.

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 6-parameter calculator with high schema coverage, the description supplies the essential frame: two-year comparison, tax heads included, itemized output. Remaining gaps (assumptions, treatment of the enum statuses, whether PRSI/USC rates are 2026 or 2027 vintage) are modest given the schema carries parameter detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents most parameters (gross pay, partner pay, renter, home carer, self-employed). The description's only added semantic is confirming rent credit is modeled, which corresponds to the 'renter' flag. 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 names a specific output (take-home pay comparison for 2026 vs 2027 after Budget 2027) and enumerates the tax components in scope (income tax bands/credits, USC, PRSI, rent credit). An agent can tell this is a net-pay calculator, not a benefits/eligibility checker. It doesn't differentiate itself from siblings like ireland_rent_tax_credit, so it stops 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?

Usage is only implied: the mention of 'Budget 2027' and the year-over-year framing suggests when it applies, but there is no explicit when-to-use/when-not guidance or pointer to alternatives such as ireland_rent_tax_credit for the rent-credit portion alone. Adequate but leaves routing 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 and openWorldHint=false, so safety is covered. The description usefully discloses the substantive rules the computation applies (31% from 7 Oct 2026 vs 33% before, 33% on development land, €1,270 exemption, losses, 15 December deadline), which lets an agent sanity-check results. It never says the tool returns an estimated liability figure or a breakdown, and gives no indication of result precision or handling of edge cases.

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 front-loaded sentence with no filler; the rate structure and the exclusion are packed in the right order. It reads as a dense run-on, though, and the parenthetical rate history takes space that could have been spent stating what the tool returns.

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 eight parameters and no output schema, the description should clarify the return value, which it does not – an agent cannot tell whether it receives a single tax figure, a line-by-line computation, or just rule text. The tax rules it does supply compensate for much of that gap, but the output contract remains undefined.

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 would be 3, but the description earns more: it explains the rate split that the 'asset' enum implies (development land at 33% regardless of date), the date-dependent rate change tied to disposalDate, and the annual exemption that exemptionUsed partially consumes. Losses are named as allowable, clarifying what the losses parameter accepts.

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 specific tax and the resources it applies to (disposals of shares, crypto, property other than the home), so an agent knows this is an Irish CGT computation tool. It lacks an explicit verb such as 'calculate', which is implied only by the parameter set, but the domain is unambiguous against siblings like ireland_rent_tax_credit or uk_stamp_duty_england_ni.

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 a concrete exclusion: 'Not for Irish/EU ETFs or funds, which pay exit tax.' That is a real routing rule an agent can act on. It does not, however, state when the tool should be preferred over a general Irish tax sibling or what prerequisites (residency, tax year) apply.

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 this is a read-only, closed-world calculation, so the bar is lower. The description adds real value beyond them by naming the authoritative basis (official means test, Department rate table) and versioning the rules by period (July 2026, July 2027 thresholds). It does not state that inputs are optional/default to zero or that the result is an estimate rather than an entitlement determination.

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 front-loaded sentence that opens with jurisdiction, verb, and resource, then layers the means-test detail in a parenthetical. Dense and wasteful-free, though the nested thresholds make the parenthetical hard to scan and slightly delay the core statement.

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 7-parameter means-test calculator with no output schema, the description should say what comes back (weekly rate, whether an eligibility verdict is included) and that unset parameters default to zero. It covers the inputs and their legal basis well but leaves the return shape entirely unstated.

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 would be 3, but the description supplies meaning the schema lacks: the income disregard figures (€1,000/€2,000, then €1,150/€2,300) that explain how earn1/earn2 and period interact, plus a reference to savings bands underpinning 'capital'. It still does not explain the couple/aged66/caringForTwoOrMore rate escalation explicitly.

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 ('estimate') and a specific resource ('the weekly Carer's Allowance') scoped to Ireland, and grounds it in the official means test. The named benefit distinguishes it clearly from siblings such as ireland_fuel_allowance or ireland_working_family_payment without needing to open 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?

Usage is implied by the tool name and the 'estimate' framing, but there is no explicit when-to-use guidance, no when-not-to-use condition, and no pointer to alternatives like ireland_what_can_i_claim or ireland_where_to_put_savings. An agent can infer the purpose but must decide routing on its own.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds real domain behavior by disclosing the decision rules and thresholds that drive the result, but it never says what the call returns (eligibility verdict, weekly rate, lump-sum option) nor how missing optional inputs such as capital or householdOk are treated.

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 front-loaded sentence opens with the jurisdiction and the resource, then packs in the thresholds with no filler. The dense parenthetical of figures is efficient but makes the sentence heavy to parse in one pass.

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 8-parameter calculation tool with no output schema, the description should say what comes back and how the unmentioned inputs (capital, householdOk, couple) affect the result; it does neither. It is complete on the policy rules it chooses to state, but leaves the agent guessing at the response shape.

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 88%, so the schema already documents each field and the baseline would be 3. The description goes beyond it by giving the actual comparison values behind incomeWeekly (€534 single, €640.80 from January 2027), tying qualifyingPayment to the under-66 path, and explaining the 2026 vs 2027 period distinction. It leaves couple, capital, and householdOk uninterpreted, keeping it from 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?

States a specific verb ('check') and a precisely named resource ('Fuel Allowance means test' plus the 2026/27 season amount), so an agent can instantly tell it apart from siblings such as ireland_carers_allowance or ireland_working_family_payment. It stops short of naming the overlapping ireland_what_can_i_claim sibling, so routing between the two is left implicit.

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 only implied by the topic: an agent can infer it should be called for Irish Fuel Allowance eligibility/amount questions. There is no explicit when-to-use, when-not-to-use, or reference to alternatives like ireland_what_can_i_claim, and no statement of prerequisites such as needing the applicant's age or income first.

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 real behavioral context beyond that — a time-dependent rate change (contracts from 7 October 2026), a hard scheme end date of 2029, and multiple caps that determine the outcome. It does not state the return shape or how the candidate amounts are surfaced, but for a pure read-only calculator the disclosure is strong.

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 the scheme identity and then packs the eligibility and calculation constraints into dense, purposeful clauses with no filler. It is a single long run-on stretch of semicolon-separated conditions rather than clearly structured sentences, which costs it a point but not more.

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 four-parameter calculator with a fully described schema and no output schema, the description supplies everything needed to invoke it correctly: eligibility gates, the formula, the caps, and the date-dependent rate. The only gap is that it does not say what the tool actually returns (e.g., the qualifying refund amount and which cap binds), leaving the result shape to inference.

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 the baseline is 3. The description does add interpretive value by explaining how price, taxPaid and mortgage interact in the lesser-of rule and the 70% mortgage threshold, but it does not clarify contractDate's self-build drawdown behavior beyond what the schema says.

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 specific scheme (Ireland Help to Buy refund) and enumerates the exact computation rule — lesser of €35,000/€30,000, 10% of price, or 4-year tax+DIRT — so the resource is unambiguous. It never uses an explicit verb like 'calculate' or 'estimate', which keeps it just short of a 5, though the scheme name and eligibility conditions clearly separate it from the other jurisdiction-specific calculators in the sibling list.

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 stated eligibility conditions (first-time buyer, new build or self-build, price ≤ €500,000, mortgage ≥ 70%, scheme runs to end of 2029), which tell an agent when the tool applies. However, there is no explicit when-not guidance and no pointer to alternatives such as ireland_what_can_i_claim or ireland_budget_2027_take_home for users who turn out to be ineligible.

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 only declare readOnlyHint and openWorldHint=false, so the credit here goes to the description's substantive additions: the 2026/2027 Maternity Benefit rates (€299/€309 weekly) and the tax treatment (taxed but exempt from USC and PRSI). These materially affect the computed result and are not available in the schema or annotations, though assumptions about top-up taxation and model limits are not stated.

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?

It is a single dense sentence with the jurisdiction and subject front-loaded, followed by outputs and then rate details in a parenthetical. Nothing is redundant, though the rate figures crammed into the parenthetical make it slightly harder to parse at a glance.

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 8 parameters, no output schema, and only read-only annotations, the description usefully compensates by spelling out the three return components (per-parent take-home, household gap, monthly saving target). It is nearly complete for an agent to call it, missing only default behavior for the optional weeks/salary fields.

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 year enum, top-up weeks, and parent's benefit flags is already documented. The description adds only indirect context (that both parents are modeled and that the year drives the benefit rate), 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 names a specific domain (Ireland maternity/paternity/parent's leave pay) and enumerates the concrete outputs: each parent's take-home pay versus a normal year, the household gap, and a monthly saving target. The verb is implicit (it computes/compares) rather than stated, and it never distinguishes itself from the very similar sibling parental_leave_income_gap.

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 guidance on when to use this versus alternatives, despite a nearly identical-looking sibling (parental_leave_income_gap) and other income tools (ireland_budget_2027_take_home, ireland_what_can_i_claim). No prerequisites or exclusions are stated; the agent must infer the use case entirely from the topical phrasing.

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 and the description only needs to add context – which it does, disclosing the statutory rate schedule (1.5/1.5/0.5% rising to 6/6/2% by year 10) and the €80,000 earnings cap. It stops short of saying results are illustrative projections driven by default assumptions (charges, pay growth, return), which is the one behavioral caveat an agent would want.

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 front-loaded sentence that leads with the scheme name and date, then the contribution mechanics, then the output. The dense parenthetical is justified because the rates and cap are the core domain facts, though it could be split for readability.

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 must carry the return story, and it does at a high level ('the projected pot at retirement'). However, it omits eligibility bounds that matter for a tool taking age (auto-enrolment age bands) and does not indicate whether the response breaks out employee/employer/State contributions separately or is a single figure.

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 six parameters, including defaults and the note that investReturn is an assumption. The description adds domain meaning to 'salary' by stating the €80,000 cap and contribution percentages apply to pay, but says nothing extra about age, retireAge, or how the year-10 phase-in interacts with the projection horizon. 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?

The description names the exact scheme (Ireland's MyFutureFund auto-enrolment, live from January 2026) and states precisely what the tool computes: the employee/employer/State contribution split and the projected pot at retirement. The scheme-specific naming cleanly separates it from siblings such as ireland_state_pension_contributory or new_zealand_kiwisaver.

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 only implied – an agent can infer this is for someone with an age and salary wanting a MyFutureFund projection. There is no explicit when-to-use framing, no exclusions, and no pointer to related siblings like ireland_state_pension_contributory or ireland_where_to_put_savings.

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 establish readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds real value beyond that by disclosing the 20% calculation with a per-year cap, support for back-claims, and the Revenue four-year rule deadline of 31 December 2026 for 2022 claims. It stops short of describing the shape of the answer (a single figure versus a per-year breakdown) or the effect of the couple flag.

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?

Everything is packed into one front-loaded sentence: scope, years, formula, and the deadline caveat. Dense and efficient, though the parenthetical and trailing deadline clause make it slightly harder to scan than a two-sentence split would be.

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 two-parameter read-only calculator with no output schema, the description covers the key inputs' treatment (constant monthly rent, per-year caps, back-claims) and the main temporal constraint. The only material gap is that it does not indicate whether the result is a single amount or a per-year series, which matters given the five-year span.

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 both monthlyRent and couple are already documented in the schema, which sets the baseline at 3. The description reinforces that rent is treated as constant across years and that a per-year cap applies, but it adds no meaning about how the couple parameter changes the computation.

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 computation (the Rent Tax Credit a renter can claim), the exact years covered (2022–2026), and the calculation basis (20% of rent, capped per year). This is clearly distinguishable from siblings such as ireland_capital_gains_tax or ireland_help_to_buy 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?

The description implies the audience (a renter claiming the credit) and the relevant window (2022–2026), and it flags back-claims. However, it never states when to prefer this over related siblings like ireland_what_can_i_claim, nor does it give explicit exclusions or prerequisites beyond the 2022 filing deadline.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it discloses the counting model (paid PRSI + up to 520 credits + HomeCaring Periods) and the 2,080-contribution threshold for the full rate, which an agent needs to interpret results. It stops short of stating output format or how drawdown variants change the answer, but with no output schema the 'weekly rate' phrasing still signals the return type.

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 front-loaded sentence with the estimate target stated first and the formula detail parenthetically appended. No filler, no repetition of the tool name, and nothing that could be cut without losing 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?

For a four-parameter deterministic calculator with full schema coverage and no output schema, the description supplies the domain rules needed to call it sensibly and to interpret the result. The remaining gap is the drawdown parameter's effect on outcomes and any note on partial-rate behavior below thresholds.

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 meaning beyond the schema by tying paidWeeks, creditWeeks, and homeCaringWeeks to the TCA aggregation and by stating the 520-credit cap and the 2,080 full-rate threshold. It does not explain how the drawdown enum values influence the calculation, which is the one parameter left purely to its schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource — 'estimate the State Pension (Contributory) weekly rate' — plus the governing methodology (Total Contributions Approach). This clearly distinguishes it from siblings like ireland_myfuturefund_pension and ireland_what_can_i_claim without needing to open 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?

Usage is implied: an agent should call it when it has PRSI contribution data and wants a weekly pension estimate. There is no explicit when-to-use or when-not-to-use statement, and no routing to alternative calculations (e.g., a means-tested or non-contributory pension sibling).

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 this is a safe, closed-world read (readOnlyHint=true, openWorldHint=false), so the description only needs to add operational context. It adds that amounts are estimates based on official 2026/2027 rates, which usefully sets precision expectations, but says nothing about how results degrade when the twelve optional inputs are omitted — a meaningful behavior gap.

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 front-loaded sentence with the scope stated first and the covered schemes and rate years as supporting detail; the parenthetical list is long but earns its place by telling the agent what is and isn't covered. No boilerplate 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?

For a 12-parameter, all-optional aggregator with no output schema, the description should explain default behavior when inputs are missing and roughly what the response contains (per-scheme eligibility plus estimated amount). It covers coverage and rate years but leaves the omitted-parameter behavior and return shape unstated.

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 (pay1, pay2, savings, prsiYears, hoursFortnight, etc.) is already self-documented, setting the baseline at 3. The description adds no interpretation beyond the schema — for example, it does not explain that hoursFortnight is combined across the household or how pay1/pay2 are assessed relative to the couple flag.

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 ('list') and resource ('social welfare payments and tax credits a household may get') and enumerates the covered schemes with amounts and reference years, so an agent knows precisely what comes back. It stops short of a 5 because it never explicitly distinguishes itself from the sibling single-scheme tools (ireland_carers_allowance, ireland_fuel_allowance, ireland_rent_tax_credit, etc.).

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 only implied by the 'what can I claim' framing — an agent can infer this is the broad eligibility sweep. There is no statement of when to prefer it over the individual scheme tools or over ireland_budget_2027_take_home, and no guidance on what inputs are needed to get a meaningful answer.

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 needs no restating. The description adds genuine context beyond them by naming the tax treatment applied to each product (DIRT 33%, exit tax with 8-year deemed disposal, CGT 31%, pension tax relief) and by flagging that market growth is a user-supplied assumption rather than a forecast — an important caveat that shapes how the agent should present results. It stops short of describing the response shape, but with annotations present that gap is minor.

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?

One sentence, front-loaded with the jurisdiction and the comparison action, then a compact parenthetical list of the five vehicles with their tax rates. The assumption caveat closes it out. Nothing is redundant and nothing essential is deferred.

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, but the description effectively enumerates the output dimensions by naming all five products and their tax bases, so the agent knows what a result will compare. It could go slightly further on model boundaries — e.g. whether pension drawdown taxation, USC or PRSI are reflected — but for a single-purpose calculator it is nearly 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 description coverage is 100%, so the schema already explains amount, years, growth, depositRate and marginalRate. The description substitutes prose ('a lump sum', 'a number of years', 'an assumption you set') that largely restates the schema and never explicitly ties the 20/40 marginalRate enum or the depositRate default to the modelled outcomes. 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 ('compare where a lump sum ends up after tax over a number of years') and enumerates the exact vehicles compared: State Savings, bank deposit, ETFs, shares, pension. An agent can distinguish this from siblings like ireland_capital_gains_tax or ireland_myfuturefund_pension, which each cover only one of those pieces.

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 comparison framing implies when to use it — a holistic 'where should I put a lump sum' question rather than a single-scheme lookup. However, it never names the sibling tools it supersedes (e.g. ireland_capital_gains_tax, ireland_myfuturefund_pension) or states what this tool does not cover, so routing must be inferred from the product list.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds real value by disclosing the calculation basis (official 2026 income limits, +€30 from January 2027, the 60% rule) and the fact that the result is a weekly tax-free estimate. It stops short of saying what happens when an income exceeds the limits (zero entitlement?) or whether the estimate handles couples and pensions correctly, which is the detail that matters most for a calculator.

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?

One front-loaded sentence: jurisdiction, action, benefit, output nature, inputs, and method, in that order. It is dense but every clause carries information; the only friction is that the parenthetical rule details make it a long single sentence.

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 does its job by characterizing the return as a weekly tax-free estimate, and it explains the governing rules that determine the value. The gaps are minor: no treatment of partner income, pension, or other weekly income as eligibility levers, and no statement of what a nil entitlement looks like.

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 defines all eight parameters including units and the 2026/2027 enum. The description restates three of them (gross pay, number of children, hours) without adding unit, format, or interaction guidance beyond the schema. 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 ('estimate the Working Family Payment') plus the jurisdiction and output cadence, so an agent can tell it apart from siblings like ireland_carers_allowance or ireland_fuel_allowance. It never explicitly says how it differs from ireland_what_can_i_claim, but the tool name and sentence make the target benefit 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?

The inputs imply the applicable situation (family, children, hours worked), but there is no explicit when-to-use/when-not statement and no named alternative for adjacent questions such as what-else-can-I-claim. An agent can infer the trigger conditions but must reason about them from the parameter list rather than the text.

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?

Beyond the readOnly/openWorld annotations, the description discloses the full modeling rules (3.5% default and employer minimum rising to 4% in April 2028, 25c-per-$1 government contribution capped at $260.72, ESCT on employer contributions, PIR on returns) and flags that the return rate is a user assumption rather than a modeled figure. That is meaningful context about how the answer is derived; it stops short of describing output shape or modelling limits such as contribution holidays or withdrawals.

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 purpose and 2026 rule context are front-loaded in a single sentence, with the important caveat ('Returns are an assumption you set') placed last. The parenthetical rule list is dense but each clause is substantive; only minor tightening is possible.

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 seven-parameter projection tool with no output schema, the description supplies the essential input assumptions and states the computed quantity (balance at 65). It omits what the response contains (single figure vs. breakdown by contributions/returns) and edge-case behavior, which keeps it short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by explaining the rule context behind parameters: why employeeRate may be 3.5% now and 4% from April 2028, and that grossReturn is an assumption the caller supplies. It does not separately explain pir or feePct beyond the schema, so it is not a full 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?

The description names a specific resource and scope: KiwiSaver balance at 65 under the 2026 rules, with the exact contribution, government-contribution, ESCT and PIR rules modeled. It is unmistakably a New Zealand retirement-balance projection and cannot be confused with the Ireland/Canada/Australia siblings, although it never uses an explicit verb such as 'calculates'.

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 rather than stated: an agent can infer this is the tool for projecting a NZ KiwiSaver balance at retirement, but there is no explicit when-to-use/when-not guidance or mention of alternatives. Given the sibling set is other-country calculators, the country prefix does most of the routing work.

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 new behavioral context by specifying that figures are gross/before tax, that amounts are statutory, and that us-XX means no state program (FMLA unpaid). It still doesn't say anything about output shape or assumptions such as continuous employment eligibility.

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 core verb (statutory pay + income gap) is front-loaded in a single dense sentence, then jurisdiction coverage. It is long but almost every clause carries information; the nested parenthetical scheme names are arguably more detail than an agent needs for tool 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?

There is no output schema, and the description compensates by stating what is produced: statutory leave pay and the income gap versus normal gross pay. For a five-parameter, read-only calculator that is largely sufficient, though eligibility conditions and currency handling for the return values are left implicit.

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 five parameters are already documented, making 3 the baseline. The description adds one meaningful clarification beyond the schema — that us-XX denotes no state program — but does not explain the interaction between topUp and topUpWeeks or how weeks defaults behave.

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 computation: statutory parental leave pay for a birth parent plus the income gap against normal gross pay, and enumerates the supported jurisdictions (UK SMP, IE Maternity Benefit, CA EI, QC QPIP, AU PLP, US states). Its multi-jurisdiction scope implicitly sets it apart from single-country siblings like ireland_maternity_leave_pay or quebec_qpip, but it never states that distinction explicitly.

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 enumerated jurisdictions and the mention of an optional employer top-up, so an agent can infer this is the cross-country comparison tool. However, there is no explicit when-to-use/when-not guidance and no routing away from overlapping siblings such as canada_ei_maternity_parental, quebec_qpip or ireland_maternity_leave_pay, which cover subsets of the same ground.

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?

With readOnlyHint=true and openWorldHint=false already supplied, the description adds useful context: the $103,000 earnings ceiling, weekly amounts and totals, and the split of shareable weeks between parents. It does not detail output structure or calculation assumptions, but it adds meaningful behavioral context beyond the 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?

The description is a single front-loaded sentence that packs the scope, plan/event coverage, earnings cap, output nature, and week-sharing context without filler. Every clause contributes to selecting or interpreting 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 a six-parameter read-only calculator with no output schema, the description covers the jurisdiction, year, plan and event scope, earnings cap, output nature, and shared-week behavior. It could more explicitly state that the tool calculates/estimates amounts and how singleParent affects results, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by stating the earnings cap, that amounts are weekly and total, and that shareable weeks are split between parents. This clarifies key semantics for salary and sharedWeeks1.

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 identifies a specific resource and scope: Quebec QPIP/RQAP parental insurance for 2026, covering plans, events, earnings, weekly amounts, totals, and shareable weeks. The verb is implicit rather than explicit, so it stops short of a 5, but an agent can clearly distinguish it from the Canada EI 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?

The description provides clear usage context by naming Quebec, QPIP/RQAP, 2026, both parents, basic or special plan, and birth or adoption. It does not explicitly name alternatives or when-not conditions, which keeps it from a 5, but the domain scope is clear enough for selection.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuine behavioral value: the rate year, that the result is computed band by band, and the specific relief/surcharge rules applied for first-time buyers and additional dwellings.

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 front-loaded sentence with no filler; jurisdiction, rate year, method, and both special regimes are packed in without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only calculator with no output schema, this covers what an agent needs to invoke it correctly. It could add a hint about the return shape (per-band breakdown plus total), but that is a minor gap 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?

Schema coverage is 100% but the schema's own descriptions are thin ('Purchase price, GBP', 'Buyer'). The description compensates by explaining what firstTimeBuyer and additional actually mean in tax terms (nil band to £175,000, 8% ADS), which is meaning the enum labels alone do not convey.

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 tax (Land and Buildings Transaction Tax), the jurisdiction (Scotland), the rate year (2026/27), and the calculation style (band by band), which cleanly separates it from uk_stamp_duty_england_ni and wales_ltt among the siblings.

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?

Jurisdiction and buyer type imply when the tool applies, but the description never explicitly routes the agent away from the England/NI or Wales calculators, nor states eligibility preconditions. Usage is inferable rather than stated.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it is a band-by-band computation at fixed 2026/27 rates, it discloses the relief thresholds (nil to £300,000, up to £500,000) and the surcharge mechanics (+5% on every band, 2% non-resident). It stops short of saying how the result is presented.

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 with the jurisdiction and rate year front-loaded and zero filler. The parenthetical thresholds make it slightly crammed, but every clause carries substantive rate information that an agent would otherwise have to guess.

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?

There is no output schema, so the description carries the burden of indicating what comes back, and it does not: it never says whether the tool returns a total liability, a per-band breakdown, an effective rate, or relief amounts. For a three-parameter calculator this is a noticeable gap, though the input-side semantics are fully covered.

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 and the schema already documents all three parameters. The description does add meaning for the buyerType enum by spelling out what first-time buyer relief and additional-property treatment actually mean in money terms, and it clarifies that nonResident is a 2% surcharge rather than an alternative classification. That is real but partial value on top of an already-complete 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?

Names a specific tax (Stamp Duty Land Tax), a specific jurisdiction (England and Northern Ireland) and a specific rate year (2026/27), so the agent knows exactly what is being computed. The geographic scoping implicitly routes away from the sibling calculators scotland_lbtt and wales_ltt, though it never names 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?

Usage is implied by the jurisdiction and rate-year framing rather than stated: an agent can infer this applies to English/NI residential purchases in 2026/27. There is no explicit when-to-use statement, no exclusion clause pointing at scotland_lbtt or wales_ltt, and no statement of prerequisites or limits.

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 adds real domain behaviour: Class 2 eligibility limited to years up to 2025–26, the 6 April 2026 rule change, fixed weekly rates, and the 35-year cap. It does not disclose edge-case handling or validation of out-of-range gap years, keeping 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?

It is a single long sentence, but it is front-loaded with the purpose and every clause (rates, deadlines, 1/35 accrual, payback) carries distinct information. Slightly denser than ideal to parse, 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?

There is no output schema, and the description compensates by stating what the tool returns: per-year cost, 5 April deadline, pension gain (1/35 of £241.30/week, capped at 35 years), and payback. For a read-only calculator of this complexity, that is enough for an agent 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?

With 100% schema description coverage across all 7 parameters, the schema already carries the per-parameter meaning. The description explains the underlying rules (rates, caps, deadlines) but does not map them to specific inputs such as qualifyingYears or appliedBefore2026, 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?

The description names the exact resource (voluntary National Insurance gap years for UK State Pension for people living outside the UK) and its scope boundary (2020–21 to 2026–27, post-6 April 2026 rules). Nothing in the sibling list overlaps, so an agent can route to it unambiguously.

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 context is implied by the topic (living abroad with UK NI gaps), but there is no explicit when-to-use/when-not guidance and no named alternative for someone resident in the UK or for a different pension question. The agent must infer the trigger from the subject matter alone.

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 behavioral context by pinning the rate year, the £225,000 nil band, and the absence of first-time buyer relief. It does not describe the shape of the result (e.g. whether a band breakdown or a single total is returned), which is the main remaining gap.

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?

One sentence, front-loaded with the jurisdiction and tax name, with the key rate facts packed into a parenthetical. No wasted clauses and nothing an agent must scan past to find the subject.

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 two-parameter read-only calculator with full schema coverage and no output schema, the description supplies the tax regime details an agent needs to trust the result. It is only slightly incomplete in not stating what the response contains, though 'band by band' hints at a per-band breakdown.

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 goes beyond the schema by explaining that the nil band is £225,000 'for everyone' and that 'additional' means the higher rates for additional properties rather than merely an opaque enum label. That meaningfully disambiguates the buyerType parameter.

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 tax (Wales Land Transaction Tax), the rate year (2026/27), and the computation basis (band by band), which clearly separates it from siblings like scotland_lbtt and uk_stamp_duty_england_ni. It stops short of an explicit verb such as 'calculate', leaving the agent to infer that from the name and context.

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?

Jurisdiction is stated, so an agent can infer this is the tool for Welsh property purchases rather than the England/NI or Scotland equivalents, but there is no explicit when-to-use or when-not-to-use sentence naming those alternatives. The buyerType distinction is implied by 'additional properties' but not framed as guidance.

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