Geo-Parity

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on genuinely new behavior: the total is a FLOOR whenever `complete` is false, `missing` enumerates every unpriced component, a total of 0 is legitimate-but-misleading, and `depositMonths` is a stated assumption rather than a measurement. This is exactly the kind of context structured fields cannot carry.

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 front-loaded with the core definition and each sentence carries distinct information — floor semantics, missing list, zero-total caveat, deposit assumption, entry-route derivation. It is dense and leans on emphatic capitals, but avoids padding; 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?

An output schema exists, so return values need not be explained, and the description instead supplies the interpretive frame the output requires (complete/missing/floor logic). For a 4-parameter required-passport/destination tool, nothing an agent needs to invoke or read the result 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 meaning beyond the schema: it says the entry route is 'derived exactly from passport mobility data' and explains the rationale for `depositMonths` ('no free global dataset of deposit norms exists'), which the schema does not state. The `destination` parameter gains nothing new over the schema's registry note.

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 — 'the cash needed to ARRIVE somewhere' — and immediately contrasts it with 'what a month costs once you live there,' which cleanly separates it from cost-of-living siblings like compare_total_cost. It even enumerates the components the total is built from (entry fee, first month's rent, deposit, verified long-stay visa fee).

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 operational guidance ('READ `complete` BEFORE `totalUsd`') and routes the agent elsewhere in one case, naming find_nomad_visas for countries absent from the PPP registry. The intended context (pre-move arrival budgeting vs ongoing monthly cost) is clear, though there is no explicit when-not-to-use statement beyond the opening contrast.

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?

Goes well past the readOnly/idempotent annotations by disclosing data provenance (hand-curated over 186 spine countries, added 17 Sep 2026), per-row scheme/regulator page and check date, `confidence: "secondary"` semantics, and the critical absence-vs-zero distinction for `depositGuarantee` and `instantPayments`. It also discloses the mandatory non-advice disclaimer returned in every response.

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 question is front-loaded, and every clause carries information, but it is delivered as two sprawling run-on sentences with dense parentheticals and backtick-heavy inline syntax. Readable enough, but not efficiently structured or chunked for fast agent parsing.

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 shape, and it still covers the interpretation traps (no scheme means no field, not zero; absent from FASTT is not the same as no instant payments) that an agent would otherwise misread. 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 coverage is 100%, so baseline is 3, but the description adds genuine meaning: `sort=lowest` flips the direction for `instantPaymentsSince` (longest-running first), `metric` defaults to `depositGuaranteeUsd`, and `access` is a narrowing filter on rankings rather than a selector for single-country lookup. This is more than restating 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 with unusual precision: newcomer account-opening rules, statutory deposit guarantee (local + USD), instant payment systems, EU basic-account right, and FATCA flag. An agent can distinguish this from compare_banking_access (which is a comparison sibling) 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?

Explicitly routes among modes: `country` for a single entry, `countries` for a side-by-side, and neither to get a ranking by `metric` (with `sort` semantics and `access` narrowing, plus `excluded` for countries lacking the metric). It does not name the natural alternative (compare_banking_access) or state when-not-to-use, so it stops short of a 5.

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

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

The description adds rich behavioral context beyond the annotations: it explains the floor/midpoint/ceiling output, the basis field, the caveats array that should be reproduced, how seniority is applied as a percentile offset, and that gender pay gap data is reported separately. These details help an agent understand the tool's limitations and usage constraints.

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 the core output before moving to use case, caveats, and methodology. It is dense and somewhat long, but most sentences add substantive context for this legal-adjacent, statistics-based 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?

With rich annotations and an output schema, the description covers the remaining important context: methodology, legal disclaimer, required caveats, interpretation of seniority, and occupation group limitations. Nothing essential for correct invocation appears to be 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 meaningful semantic detail. It clarifies that seniority is a local percentile offset rather than a fixed multiplier and that ISCO-08 major groups are broad families of work, not job titles.

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: it returns floor, midpoint and ceiling salary for a broad occupation and seniority in a country. It clearly defines scope, including ILO measured vs modelled basis, but does not explicitly differentiate this tool from similar siblings such as calculate_wage_bands or compare_occupation_pay.

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 clear use context: employer-side pay transparency and EU job-advert requirements. It also warns that it is not legal advice and does not certify compliance. However, it does not name alternative tools or explicitly state when a different sibling should be used 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 establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine value beyond them: it discloses the exact formulas used for each returned figure, the US baseline of 1.0, and the real-world data sources (World Bank, IMF, OECD, Penn World Table), which helps the agent trust and interpret 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?

One front-loaded sentence that opens with the inputs and moves to the outputs and provenance. Slightly dense with three formula definitions packed in, but 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?

For a read-only calculation tool with a 100%-covered schema and an output schema, the description supplies everything the agent needs: the computational model, the baseline convention, and the data sources. Any remaining return-format detail is covered by 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%, so the baseline is 3; the enum values, defaults, and per-parameter nuances (city slug heuristic, source dataset semantics) are all documented in the schema itself. The description only restates the two required inputs (US-denominated income, country code) and adds no syntax or selection 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?

States a precise operation with three named outputs (effective local purchasing power as income/pppIndex, lifestyle equilibrium cost as income*pppIndex, purchasing power ratio as 1/pppIndex) and names the data provenance. An agent can distinguish this computation tool from sibling cost/salary comparison tools 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?

Usage context is implied by the required inputs (US-denominated income + country code), but there is no explicit when-to-use guidance, no mention of when this is preferable to siblings like localize_salary, compare_total_cost, or compare_food_cost, and no stated prerequisites or limitations.

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 safety (readOnly, idempotent, non-destructive), yet the description adds genuine behavioral context: the fixed/local burn split, city-level vs national scaling, Factbook-only country fallback, and the 'purchasing-power estimate, not financial advice' caveat. That is meaningful added transparency beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the audience and the core computation, then the methodology, then the return summary and caveat. Dense but every clause carries information; slightly long, though nothing is truly 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 an output schema present, the description need not enumerate return fields, and its inclusion of them is harmless but slightly redundant. For a 7-param analytical tool it supplies adequate scope, methodology, and caveats; only explicit alternative-tool 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 coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the conceptual model behind `fixed` (location-independent slice that won't fall) and the cost-of-living ratio logic applied to `targets`, adding interpretive meaning beyond the field text.

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 ('computes how many extra months of runway relocating... buys') with the resource and scope, and even names the audience (founders/freelancers). An agent can distinguish it from siblings like find_fire_locations or retire_on_budget 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 framing 'For founders/freelancers stretching savings' clearly signals the use case and implicitly excludes retirement/visa-planning tools. It does not, however, name an alternative or state when NOT to use it (e.g., vs. find_fire_locations), so it stops short of explicit routing.

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, and non-destructive behavior, so the bar is lower. The description goes well beyond them, disclosing the statistical model (log-normal), the calibration sources (World Bank GNI per capita, Gini index, ILOSTAT with curated fallback), the 'null where none exists' handling, and the estimate-vs-payroll caveat.

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 paragraph, but the methodology is front-loaded and every clause carries information (inputs, formula, outputs, caveat). No filler sentences, though the em-dash chain is heavy and would benefit from light structuring.

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 explained, and annotations cover the safety profile; the description still fully specifies the model, sources, and outputs. It is essentially complete, missing only sibling-relative routing guidance.

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 still adds value: it explains that 'salary' locates a pay figure on the curve returning a percentile and out-earns %, and that 'percentile' returns the exact threshold wage — semantics that go beyond the terse schema field descriptions.

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

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

The description states a specific verb and resource ('Models a country's wage distribution', 'returns the ... bands') and enumerates the exact outputs (survival floor, minimum, p50, p75, p90, p99). It does not name or distinguish itself from close siblings like build_pay_range, localize_salary, or compare_occupation_pay, so an agent must infer the boundary.

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: the closing clause 'Model estimates for benchmarking, not payroll data' signals the intended use case and warns against misuse. However, with ~50 sibling comparison tools, there is no explicit guidance on when to pick this over build_pay_range or localize_salary, nor when the optional salary/percentile paths apply 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so credit here goes to what the description adds: the exact rule sets applied (generic 183-day, US SPT weighted 3-year formula, UK tax-year test) and an explicit disclaimer that results are not tax advice. That is 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?

Two sentences, front-loaded with the computation and its scope, then the rule sets, then the disclaimer. No filler and nothing buried.

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 names all three evaluated tests. What remains uncovered is the counting convention for ambiguous date ranges and the overlap/duplicate-day behavior, which matters for correctness of the input.

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 50%: referenceDate and country are documented in the schema, while entry/exit carry only date formats. The description's 'per country per calendar year' hints at grouping but does not clarify day-counting conventions such as whether entry and exit days are inclusive or how overlapping/duplicate stays are handled — a real gap for a day-count tool.

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 ('count distinct days of presence per country per calendar year') and enumerates the three rule sets evaluated, so the computation is unambiguous. It does not differentiate itself from overlapping siblings such as check_tax_residency_risk or check_travel_residency, which an agent would need to disambiguate at selection time.

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 clause 'Early-warning day counter — not tax advice' implies a screening use case and sets a scope boundary, but there is no explicit when-to-use/when-not guidance and no routing to the closely related residency siblings. Usage is inferable but not 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 declare readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds valuable behavioral detail beyond that: entry and exit days both count as presence, overlapping trips are de-duplicated, and the response includes specific compliance outputs. It does not cover edge cases like timezone handling or the default reference date, but the core semantics are well disclosed.

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 three tightly written sentences with zero waste: the first states the rule, the second clarifies counting and de-duplication, and the third summarizes the outputs. It is front-loaded with the purpose and appropriately sized for the tool's complexity.

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 complete annotations, the description is largely complete for correct invocation. It does not mention the optional plannedEntry plan computation or referenceDate behavior, but those are fully covered by the schema, so the definition as a whole is 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 fully documents the trips, plannedEntry, and referenceDate parameters. The description adds no parameter-specific meaning beyond what the schema provides, which matches the baseline of 3 when structured data 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 (Validate) and a precise resource (a set of trips against the Schengen 90/180-day rule), making the tool's purpose immediately clear. It does not explicitly differentiate itself from the overlapping sibling check_travel_residency, 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?

Usage is implied by the domain statement—the agent can infer this is for Schengen day-count validation—but there is no explicit when-to-use guidance, no conditions for choosing it over sibling tools like check_travel_residency, and no exclusions or prerequisites.

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 real value beyond them: the 43-jurisdiction coverage, the resident-vs-expat regime comparison model, that arrival adds leaveBy/residencyDate to the response, the Schengen 90/180 cross-warning, and the explicit 'early-warning estimates — not tax advice' caveat.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, which is good, but it is a single sprawling ~90-word sentence. The parenthetical regime examples (Beckham Law 24%, IFICI 20%, impatriati, territorial/remittance, …) with a trailing ellipsis are padding that lengthens an already dense line without adding invocation-critical 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 not be restated, and the description still volunteers that arrival yields leaveBy/residencyDate. Scope, caveats and the Schengen interaction are covered; what is missing is sibling differentiation against check_residency/check_schengen, which is the main residual gap for a tool with this many near-neighbors.

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 framing (183-day counting period, per-country variations, income exposure measured on the FULL annual income if the cliff is crossed) but does not supply formats or semantics beyond what the schema already documents for days, income, country and arrival.

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: it evaluates proximity to a tax-residency threshold and estimates tax owed if crossed, with concrete scope (183-day rule, 43 jurisdictions, resident vs expat regimes). The purpose is unmistakable, though it never names or contrasts with the obvious siblings check_residency, check_travel_residency, or check_schengen, so an agent must infer the boundary itself.

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: 'evaluates how close a stay is to triggering tax residency' plus 'Optionally computes leave-by/residency dates' signals a planning/early-warning use case. There is no explicit when-to-use/when-not statement, no prerequisites (e.g. that it needs a presence count or arrival date), and no routing to alternatives despite several overlapping 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 cover the read-only, idempotent, non-destructive profile, so the bar is lower, yet the description adds real behavioral nuance: the Cyprus conditional 60-day rule is flagged only when you're not 183+ resident elsewhere, ratings are safe/warning/triggered, and it frames the output as early-warning day math rather than tax advice. It does not discuss pagination or limits, but for a computation tool that 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?

Front-loaded with 'The comprehensive engine' and organized into three numbered output groups, so the structure is clear. It is dense to the point of reading as one long passage, but nearly every clause carries useful 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 and rich annotations already present, the description completes the picture by stating scope (single itinerary input), the caveat (not tax advice), and the sibling supersession. 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 67% and the description only elaborates on the optional income parameter ('enables the tax-cost projection for at-risk countries'). The stays structure and referenceDate are documented by the schema itself, so the description adds marginal meaning beyond structured fields. Baseline 3 is appropriate here.

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 engine and enumerates exactly the three outputs it produces (Schengen 90/180 status, per-country tax-residency risk, optional tax-cost projection). It explicitly distinguishes itself from check_schengen / check_residency / check_tax_residency_risk by declaring it supersedes them, so an agent can disambiguate 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 clearly frames this as the comprehensive replacement for three named sibling tools (all still available), which gives strong routing context. It stops short of saying when the narrower siblings are still the better choice, so a full 5 is not warranted.

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 (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral context on top: the data is triennial so the survey year travels with each figure, and a missing figure is absent and dropped from rankings, never 0. That last point directly prevents a misread of empty results as zero banking access.

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 what is measured, then the usage modes and the caveats. The prose is dense and dash-heavy, but every sentence carries information (source, periodicity, missing-value handling, scope limit); nothing is 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?

Output schema and annotations exist, so return-format and safety details need not be repeated. The description still supplies the interpretive boundaries an agent needs (survey year is attached, cannot answer account-opening eligibility, missing values are dropped), making it complete for this comparison 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?

Schema description coverage is 100%, so the schema already documents all four parameters, including that `sort` and `metric` are ignored when `countries` is given. The description restates the metric options and the ranking default but adds no syntax or format 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 precisely what is measured (share of adults 15+ with an account at a bank, other financial institution, or mobile-money provider, plus personal remittances as a share of GDP) and the source (World Bank Global Findex). It also draws the crucial boundary that account ownership means adults CAN bank, not that a newcomer can open an account, which is what a sibling like banking_access or check_residency would answer.

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 describes the two modes: give `countries` (two or more) for a side-by-side, omit it to get the 41-country spine ranked by `metric`. Clear context, but no sibling tool is named as an alternative (e.g. banking_access for a single country), so it stops just short of full 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?

Goes well beyond the annotations (which already cover readOnly/idempotent/non-destructive). It discloses that B-READY is a rotating cohort (22 of 41 spine countries in the 2025 edition), that an out-of-cohort country returns the new-company rate alone with a caveat naming the gap, that a country with neither returns NO_DATA, and that every response leads with a not-advice disclaimer. This is exactly the behavioral context an agent cannot 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?

The core purpose is front-loaded and every clause carries real information, but the body is one dense, run-on enumeration that is harder to scan than a broken-out list would be. Appropriate length overall, slightly overwrought in sentence structure.

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 it fully covers the tricky cases an agent must anticipate: cohort gaps, the single-rate fallback, NO_DATA, and the mandatory disclaimer. Combined with its parameter routing, an agent has everything needed to call and interpret 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 coverage is 60%, and the description compensates meaningfully: it defines the country/countries/neither semantics, the default metric (daysDomestic) and the full metric enum, clarifying what each ranking means. It does not explain the `limit` parameter or the sort defaults (those live only in the schema), so it stops short of full coverage.

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

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

States a specific verb+resource: it returns how long and how much it takes to register a limited company, enumerating the exact facts (calendar days, cost, paid-in minimum capital, ownership restrictions, employee quota, online/e-signature status, new-LLC density). The scope is unmistakable and no sibling tool covers company-registration entry, so the agent can pick it 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?

Gives clear invocation routing: '`country` for one, `countries` to compare, neither ranks by `metric`' with the metric enums listed. However it never states when to prefer this over adjacent siblings like compare_countries or country_dossier, and offers no explicit exclusions — usage is implied rather than guided.

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 read-only/idempotent annotations, it discloses the coverage gap (22 of 41 spine countries) and that missing countries return NO_DATA naming the gap rather than a modelled figure. It also flags that responses carry a 'for information only' disclaimer, which is non-obvious behavioral context an agent must relay.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded, with scope stated before caveats and parameter mechanics. The long parenthetical and run-on clauses make it heavier than necessary, though nearly every clause 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?

For a 6-param tool with an output schema, the description covers scope, coverage limitations, default ranking behavior, and the informational disclaimer. Return-value description is correctly delegated to the output schema, leaving only minor parameter details 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 schema coverage at 50%, the description compensates by explaining the interaction the schema cannot: that omitting `country`/`countries` triggers a ranking, ordered cheapest first by `household` and `unit` with their defaults. It adds little on `limit`, but the enum parameters are well covered.

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 (net full-time centre-based childcare cost after benefits and tax, from the OECD tax-benefit model) with the exact household scenarios modelled. The scope is precise enough to separate it from siblings like compare_total_cost and compare_food_cost 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 clear routing for `country` (one) vs `countries` (side-by-side) vs neither (ranking), plus sort direction and the OECD-membership limitation. It never names a sibling alternative or an explicit when-not-to-use condition, so it falls short of a 5.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds genuinely non-obvious context: the ERA5 reanalysis source and 2015-2024 window, the reanalysis-vs-station caveat, and the crucial disclosure that 'comfortable days' is a stated temperate-biased preference rather than an objective measure. It does not describe pagination or the output shape, but the output schema exists, so that is a minor 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?

Well front-loaded — source, metrics, then mode selection, then the caveat. It is on the long side and includes a couple of editorial asides ('the seasonal question is the one people actually have, and an annual total hides it'), but those asides carry routing value rather than 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?

With annotations carrying safety and an output schema present, the description only needs to supply source provenance, metric definitions, mode routing, and caveats — and it does all four. An agent has everything required to call this correctly and to interpret the ranking honestly.

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 real interpretive value beyond the schema: what `country` actually resolves to (a named representative city, since a country has no single climate), and that `minComfortDays` operates over the ranked window. Format details like the slug and alpha-2 forms are already 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 (compare monthly climate normals) and enumerates exactly what is returned: mean daily max/min temperature, average monthly rainfall, and a comfortable-day count. It also distinguishes its two operating modes (single-place lookup vs. ranked comparison), which no sibling tool covers.

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 routes the caller: pass `city` or `country` for one place's twelve months, otherwise cities are ranked. It also explains the `month` vs. year choice and justifies the seasonal default, so an agent knows which path to take without 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 readOnly/idempotent/non-destructive, and the description goes well beyond them: provenance (real connections, not crowdsourced or self-reported), time window (28-day aggregation), coverage breadth, and a crucial null-semantics rule — 'a country Radar has too little data for is absent, never zero'. That absence rule is exactly the kind of behavior an agent cannot infer from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and metric list, and every sentence carries information — the 28-day window, the coverage claim, and the absent-never-zero rule all earn their place. It is a dense single run-on paragraph rather than clearly segmented, which costs it the top mark.

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 shape need not be explained; the description instead covers the things structured fields cannot — data provenance, aggregation window, coverage limits, and null handling. Required parameters are zero and defaults are schema-documented, so 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%, including the sort-direction caveat and filter examples, so the parameters are fully documented without the prose. The description adds conceptual framing (why the call-quality verdict exists) but no syntax, format, or interaction detail beyond what the schema already supplies — baseline 3.

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 — measured connection quality per country — and enumerates the exact metrics returned (median download/upload Mbps, idle latency, jitter, call-quality verdict), with the data source named (Cloudflare Radar). No sibling in the compare_* family covers connectivity, so the agent can place 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?

Gives a clear decision context — this is the tool that answers 'can I work from here', where latency/jitter matter more than bandwidth — and points out that coverage exceeds the site's country pages (~200 locations), implicitly routing users who find no country page. It does not, however, explicitly name an alternative or state when not to use it.

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 (readOnly, idempotent, non-destructive). The description adds meaningful behavior beyond that: country tax presets are transparent effective rates and all overridable, and brackets mode falls back to flat outside US/GB. The 'estimates only — not tax advice' caveat is also useful, though response shape is left to the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences that front-load the calculation, then the methodology and the override/fallback caveat, ending with the disclaimer. 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?

Given an output schema exists, return values needn't be explained, and the description still names the key output (break-even rate). It covers presets, override behavior, and the brackets fallback. Slightly incomplete on how hours/weeks affect results, but strong overall for an 11-param 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?

Schema description coverage is 100%, so parameters are already well documented, making 3 the baseline. The description adds the notion that presets are overridable and mentions tax-mode fallback, but does not clarify individual parameter interactions (e.g., weeks/hours effect on the break-even calculation) beyond what the schema 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: computes gross-to-net parity between a contractor hourly rate and an employee W2/EOR rate, and returns the break-even contractor rate. This clearly distinguishes it from sibling tax tools like compare_effective_tax or compare_tax_burden.

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 conveys the scenario (comparing contractor vs employee take-home) but never explicitly says when to pick this over alternatives such as compare_effective_tax, required_rate, or estimate_employer_cost. Usage is implied by the scenario rather than stated with 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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds that comparisons are US-relative and span multiple datasets with a consensus ratio, plus a bidirectional salary equivalence, which is genuinely useful context beyond the structured fields, but it does not disclose anything about determinism, latency, or data freshness.

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 the core action and then lists distinct outputs, with no filler. It is somewhat run-on, but every clause carries information an agent can use.

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 a 2-parameter schema at full coverage, rich annotations, and an existing output schema, the description is largely complete; the output enumeration is arguably redundant but harmless. The only real gap is routing guidance versus the many compare_* siblings, which is not addressed.

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 already explains both 'a' and 'b' as ISO 3166-1 alpha-2 codes with the differing requirement. The description adds no meaning beyond the schema, 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 states a specific verb and resource (side-by-side comparison of two countries) and enumerates the concrete outputs: US-relative price levels across named datasets, consensus ratio, percent difference, and salary equivalence. It implicitly distinguishes itself from narrower siblings like compare_food_cost or compare_housing by being the comprehensive cost-of-living comparison, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance and no reference to any sibling tool. An agent must infer from the output enumeration that this is the broad cost-of-living comparison rather than a slice like compare_inflation or compare_total_cost. No prerequisites or exclusions are 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 safe read-only behavior, and the description adds meaningful traits beyond them: the default sort order (safest-first), the ABSENT-not-zero semantics that would otherwise silently misrank unassessed countries, and the guarantee that it never reweights cost or livability scores. These are exactly the behavioral details annotations can't express.

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 definition and scale before any editorial, and every clause is relevant. It runs a bit long, and the earthquake/copingCapacity aside is more persuasion than specification, but nothing is truly 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 an output schema present, return values need no explanation, and annotations cover the safety profile. The description still fills key gaps — scale direction, absence handling, coverage breadth, and its isolation from other rankings — leaving only explicit alternative-tool routing 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?

Schema description coverage is 100%, so the schema already carries parameter meaning; baseline 3 applies. The description reinforces a few semantics — that copingCapacity is the decision-relevant dimension and that unsorted output is safest-first — but adds little parameter 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?

Names the exact data source (INFORM, EC JRC), states the resource (composite risk plus hazard/vulnerability/copingCapacity dimensions), the scale direction (0-10, higher is worse), and the coverage scope (191 countries). It also distinguishes itself from other rankings with 'Deliberately not folded into any other ranking here,' so an agent can tell it apart from compare_safety_stats or compare_climate.

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?

Implies a use case ('when choosing where to live') and leads with a safest-first default, but never names a specific alternative tool or states when NOT to use it. An agent gets a general sense of fit but no explicit routing rule to a 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?

Goes well beyond the readOnly/idempotent annotations: discloses that 39 of 41 countries are modelled, that the Philippines and UAE keep only a statutory rate with a caveat and never a borrowed effective rate, and that every response leads with a disclaimer. This is exactly the kind of coverage/caveat context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded, leading with what the tool computes and the gap. Every sentence carries information, though the disclaimer and 41-country caveat sentences make it heavier than strictly 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?

An output schema exists, so return values need not be explained. Combined with annotation safety profile and the disclosed country coverage caveats, an agent has everything required 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?

Adds meaning beyond the 80%-covered schema: `metric` selects the ranking metric with eatr as default, `sort=highest` overrides the lowest-first default, and the country/countries/neither interaction defines when each param applies. Marginal gains only, since the schema already documents most 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+resource: forward-looking effective average/marginal tax rate and cost of capital beside the statutory rate, with the gap. It clearly distinguishes itself from siblings like compare_tax_rates, compare_tax_burden and withholding_tax by naming the OECD EATR/EMTR methodology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the three usage modes explicitly: `country` for one, `countries` for a side-by-side, neither for a ranked list, plus metric and sort defaults. It does not name alternative sibling tools, but the routing within the tool is fully specified.

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 read-only/idempotent/non-open-world, and the description adds substantial context beyond them: the data is scraped from Knowledgebase country pages because no data file is published, the survey is biennial and the caveat names its year, it measures provision/infrastructure/skills rather than newcomer usability, and every response leads with a 'for information only' disclaimer. That is exactly the extra behavioral detail annotations cannot carry.

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 what the index measures, then scope, caveat, and parameter behavior in a dense but well-ordered passage. It is on the long side for a single paragraph, but nearly every clause adds distinct value; no obvious 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, return values need not be explained, and the description still covers scope (41 countries), data provenance, survey cadence, semantic caveats, and parameter modes. 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 60%, and the description compensates well: it disambiguates `country` vs `countries`, explains the `index` enum values (egdi default; osi, tii, hci) and the `sort` default/override. Only `limit` is left unaddressed in prose, though its schema description already covers it.

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 (UN E-Government Development Index, 0–1) with its three named components and the reading scope (all 41 spine countries). An agent can distinguish this instantly from siblings like compare_countries or compare_connectivity, which handle different datasets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the three usage modes clearly: single `country`, side-by-side `countries`, or a ranking by `index`, with default ordering (highest first) and the `sort=lowest` override. It does not, however, explicitly steer against any sibling or state exclusions such as when a broader country-comparison tool would be preferable.

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 (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: dollar figures/comparisons are withheld when local currency does not convert consistently, NO_DATA is never zero, responses always lead with a disclaimer, and it feeds no total. These are real behavioral traits an agent cannot infer from 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?

It is front-loaded with the noun phrase defining the tool, but the body is a dense, run-on paragraph laden with parentheticals. Much of it earns its place, yet the measured/modelled comparison and the trailing disclaimer sentence are restated across several clauses, costing 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?

For a complex measured-vs-modelled cost tool, the description covers source, coverage, units, the modelError comparison, withholding caveats, NO_DATA semantics, and the scope limitation (least-cost diet, not typical household spend). With an output schema present, the extra field detail is redundant but not harmful, and 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?

With 60% schema coverage, the description usefully explains semantics the schema omits: `country` means one, `countries` means two-or-more, neither `country` nor `countries` triggers a ranking, and `metric` selects dailyUsd (default) or unaffordablePct. It adds meaning over the enum/default fields, though it leaves `limit` and `sort` largely 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 gives a specific verb+resource+scope: the World Bank's Food Prices for Nutrition measured cost of a healthy diet per person per day, naming the data source, coverage (165 of 186 spine countries), and explicitly labeling it 'measured' as opposed to the site's 'modelled' grocery prices. This separates it from siblings like compare_total_cost and estimate_micro_costs, which are not diet-cost tools.

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 mode-selecting parameters explicitly: `country` for one, `countries` for a side-by-side, and neither ranks unless you pass `metric`, with `sort=highest` reversing the default cheapest-first ordering. It also flags the 'for information only' caveat context. It does not, however, route the agent to any named sibling alternative, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond that: vintage/coverage figures (36/41 for doctors-nurses, 31 for beds), source attribution per row, the rule that older figures are omitted rather than served as current, default sort direction, and a disclaimer that every response carries. That is unusually 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?

Dense but well front-loaded — the core capability opens the sentence and caveats follow. Em-dash heavy and packed, but each clause carries distinct information (sources, caveat, coverage, param behavior, disclaimer) rather than 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?

An output schema exists, so return format need not be explained, and the description doesn't waste space on it. It covers sourcing, coverage limitations, sorting, and the informational-only caveat — enough for an agent to call this correctly. Minor gap: the `limit` parameter's interaction with default sort is left 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?

With 60% schema coverage, the description compensates meaningfully: it clarifies that `metric` does not rank (only doctors by default; nurses and beds selectable), that `sort` defaults to highest and `sort=lowest` flips it, and that `country`/`countries` map to single vs side-by-side. It leaves `limit` to the schema, but the enum-bearing parameters are well explained.

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?

It names a specific resource (doctors, nurses, beds per 10,000), the data sources (WHO GHO, OECD), and the companion metric (UHC service-coverage index). This is clearly distinguishable from siblings like compare_healthcare or health_prep because it frames itself as density rather than access. An agent knows exactly what this returns 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 a strong limitation cue ('Density is not access... not whether a visitor can use it or what it costs'), which implicitly points to a different tool for access/cost questions. It also explains when to use `country` vs `countries`. But it never names an alternative sibling to route to, so the when-not guidance stops short of explicit redirection.

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 annotations already confirming a safe read-only, idempotent, non-destructive call, the description still adds substantial behavioral context beyond them: data provenance (World Bank/WHO measured series, never price-index derived), the explicit warning that shares and absolute burden are separate facts, the decision to report dental as access rather than price, and the national-average/not-advice disclaimer. This is exactly the kind of limitation disclosure that prevents misuse.

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 opening sentence is front-loaded with the tool's core output and scope, and the content is dense rather than padded. It runs long for an MCP description and includes illustrative asides (the 1.2x-5.4x overstatement figure, the US ~11% example) that justify methodology more than they guide invocation, but nothing is purely redundant.

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

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

For a read-only comparison tool with an output schema and full annotation coverage, the description supplies everything an agent needs: metric definitions, units, country scope, data source, interpretation caveats, and what the tool deliberately does not do. 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 each parameter (sort enum, country code, the two numeric filters) is fully documented in the schema, so the baseline of 3 applies. The description's metric list loosely corresponds to the sort enum but adds no syntax, format, or unit detail beyond what the schema already gives.

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 resource (healthcare cost and financial exposure) and enumerates the exact metrics returned (out-of-pocket spend, share of spending, total spend per capita PPP, government share, physician/dentist density) plus a clear scope of 41 countries. It is unambiguous about what the tool produces, but it never distinguishes itself from the closely related sibling compare_health_capacity, which likely also covers physician density.

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 it should use this to compare healthcare cost/burden across countries, and the description usefully excludes some interpretations (not a price index comparison, not an individual quote, not advice). However, there is no explicit when-to-use/when-not statement and no named alternative (e.g. compare_health_capacity for capacity-only questions), so routing relies on 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?

Goes well beyond the readOnly/idempotent annotations: discloses data provenance (Eurostat, OECD, ECB), that euro-area-only mortgage rates are simply absent rather than estimated, that 'modelled' rent understates housing by up to ~40%, that percentages are country-relative not cross-country, and a 'not financial advice' disclaimer. This is exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core value proposition and the gap metric come first, with caveats (OECD interpretation, rentBasis, modelled understatement) following. Each sentence adds interpretive value, though the block is long enough that a reader must work to parse it.

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 5-parameter, zero-required, output-schema-backed tool, this is complete: it covers what is returned, how the key derived metric is produced, the data sources, and the interpretation traps. Nothing an agent needs to call or interpret 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 real meaning: it explains what `remoteIncome` unlocks (`rentPctOfYourIncome`, `arbitrageGap`) and clarifies that the affordability ratios are self-referential. It doesn't restate every field, which is appropriate given the schema already covers 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 and resource ('housing cost and affordability across countries') and carves out a niche against siblings like compare_food_cost and compare_total_cost by naming the exact question it answers (local burden vs. remote-income affordability and the `arbitrageGap`). An agent can distinguish it 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?

Gives clear conditional usage guidance for the key parameter ('pass `remoteIncome` to get it'), distinguishing the local-only view from the personal-affordability view. It never explicitly names an alternative sibling tool or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial beyond-annotation context: data sources (World Bank, IMF, BIS, ECB viaEuroArea flag), the Fisher-relation constraint requiring nominal and inflation within a year, the ex-post (not expectation) nature of real rates, and the flat-not-forecast projection caveat.

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 a plain-language framing sentence, then dense, information-bearing detail on sources, computation rules and caveats. Long but nearly every clause carries meaning, so no serious waste.

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-shape explanation isn't needed. The description nevertheless covers both invocation modes, source hierarchy, the computation guard, and the drop/ranking semantics — everything an agent needs 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?

Schema coverage is 100%, so the baseline is 3. The description adds the ranking universe ('41-country spine') and the important drop policy ('missing a metric lacks the key and is dropped from a ranking, never scored 0'), but the core parameter semantics (codes, ignored params) largely restate 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 ('real rates... returns side by side: consumer-price inflation, policy rate, deposit and lending rates') and is unmistakable against siblings like compare_tax_rates or calculate_ppp. An agent knows exactly what this returns 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?

Explicitly describes the two modes: with `countries` (two or more) it returns side-by-side comparison; omitting `countries` ranks the 41-country spine by one `metric`. It also states that `sort`/`metric` are ignored in comparison mode. No sibling alternative is named, keeping it short of a 5.

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

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

Annotations already cover the read-only/idempotent safety profile, but the description adds real behavioral context beyond them: employees-only scope excluding self-employed and informal workers, pre-tax basis, the sign convention for the gender gap (negative values kept), and the NO_DATA fallback. This is unusually rich 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?

Dense and front-loaded: the core purpose, the sibling disambiguation, and the coverage caveats lead. It is longer than strictly necessary and could trim the informal-sector explanation, but nearly every sentence carries distinct decision-relevant 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, return values need no explanation, and the description still supplies scope, metric units, caveats, and fallback behavior. Nothing an agent needs 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 coverage is 100% and the enum is self-documenting, so the baseline would be 3. The description goes further by warning that the ten ISCO-08 groups are broad families, not job titles ('one group covers a surgeon and a junior developer alike'), which meaningfully shapes how an agent interprets the occupation argument.

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: measured gross monthly earnings of employees by ISCO-08 major group from ILOSTAT, with metric variants and country coverage. It explicitly distinguishes itself from calculate_wage_bands as the 'only measured wage series', so an agent can separate 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?

Names the adjacent tool (calculate_wage_bands) and the exact condition that separates them ('MODELLED, and the two are not interchangeable'), and states that countries without ILO data return NO_DATA rather than a substitute. Use vs. alternatives is fully specified.

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 read-only annotations, it discloses data provenance (OECD, World Bank, WBL), country coverage, projection exclusion, missing-metric handling, and that every response carries a disclaimer. These are substantial behavioral details an agent would not get from annotations alone.

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 dense single paragraph that lists many returned metrics already covered by the output schema, and it opens with an ambiguous "there" before giving the primary country/countries instruction. It is informative but not tightly front-loaded or appropriately trimmed.

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, output schema, and annotations, the description covers coverage limits, ranking behavior, missing data, projection exclusions, and the required disclaimer. An agent has enough context 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 schema already explains each parameter. The description mostly repeats the country/countries/metric selection logic and adds little parameter-specific meaning for `sort` or `limit`, making 3 the appropriate 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?

The description clearly identifies the resource as state pension system indicators by country and lists the specific metrics available. It does not explicitly distinguish itself from nearby siblings such as pension_abroad or retire_on_budget, 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?

It gives explicit parameter-mode guidance: use `country` for one profile, `countries` for a side-by-side, or neither for a ranking by `metric`. It does not name alternative tools or state when not to use this one, so it lacks full alternative routing.

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 safe-read profile (readOnly, idempotent, non-destructive), and the description still adds substantial behavior: 204-country coverage with named exclusions, NO_DATA distinct from an empty calendar, weekend holidays excluded, and regional counted separately from national. This is exactly the kind of context annotations cannot express.

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 'Two questions in one' and organized by mode, but padded with persuasive framing ('the number a distributed team actually plans against', the London/Tokyo anecdote) that adds flavor more than invocation guidance. Still readable and mostly earning its length.

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, and it covers the remaining gaps: both modes, coverage limits, edge-case semantics (NO_DATA vs empty), and holiday-counting rules. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by requiring 'two or more' codes for the overlap mode and by explaining the NO_DATA outcome for unsupported country codes — a parameter-value behavior the schema does not state.

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 dual-mode verb+resource: shared working days across given countries, or a ranked table of public holidays when countries is omitted. An agent can immediately distinguish this from sibling tools like compare_working_time or find_meeting_slot because the description frames it as the holiday-overlap half that timezone tools miss.

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 conditions for both modes (with countries = overlap; without = ranking) and contrasts the tool against timezone-overlap tools. It does not name a specific sibling tool to use instead, so the routing guidance is contextual 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 already declare readOnly/idempotent/non-destructive/openWorld=false, and the description goes well beyond them: the vintage floor rule, that a stale country is dropped rather than scored 0, the concrete UK example, and what each metric actually measures ('intentional killings only, not petty crime or road deaths'; population-weighted PM2.5). It even discloses that the disclaimer leads every response.

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 two operational modes are front-loaded and each sentence carries information (sources, floor rule, example, metric definitions). It is dense and slightly overstuffed with the closing disclaimer/liability sentence, which is a mild cost against an otherwise efficient structure.

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, annotations covering the safety profile, and 100% schema coverage, the description fills every remaining gap an agent needs: when countries are dropped, what the metrics mean, and how the two modes behave. Nothing required 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 coverage is 100%, so the schema carries the parameter syntax (baseline 3). The description still adds real meaning beyond it: the ranking is over the '41-country spine', default direction is lowest-first, and it clarifies the two-mode split between `countries` and `metric`/`sort`/`limit`.

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 (returns side by side / ranks) with concrete resources: intentional homicides per 100,000, PM2.5 exposure, and INFORM disaster-risk score and band. The framing 'Measured danger once there' plus the named data sources distinguish it from siblings like compare_country_risk or compare_climate without opening a 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 branches usage: pass `countries` (two or more ISO alpha-2 codes) for a side-by-side comparison, omit it to get a ranking by one metric. That is clear context for both modes, but no sibling alternative is ever named (e.g. compare_country_risk), so the 'vs alternatives' half 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 cover safety (readOnly, non-destructive, idempotent, closed-world), and the description adds genuinely new behaviour: coverage is 22 of the 41 spine countries, anything outside that cohort returns NO_DATA, and every response leads with a 'not tax or legal advice' disclaimer. That coverage-limit and disclaimer disclosure is exactly the kind of trait annotations cannot carry.

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 long and written as a single dense run-on, but it is well front-loaded — the metrics list and the sibling-disambiguation caveat lead, with the coverage and disclaimer qualifiers trailing. Nearly every clause adds decision-relevant information, though the metric enumeration could be tightened.

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 5-param, read-only comparison tool with an output schema, the description covers purpose, metric vocabulary, sort direction, coverage limits (22 of 41, NO_DATA outside), and the mandatory disclaimer — nothing an agent needs to call it correctly is missing. Return-value formatting 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 coverage is 60%, so the description usefully compensates by naming the `metric` enum values and its default, explaining `sort` direction semantics ('lowest first unless sort=highest'), and clarifying that `country` takes one code while `countries` is for a side-by-side. Only `limit` is left entirely to the schema, and metric-specific meanings are spelled out rather than left implicit.

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?

It names a specific resource (World Bank B-READY Taxation firm-survey data) and enumerates exactly what it reports: compliance hours, e-filing share, audit/VAT-refund weeks, refund-process complaints, social-security share of labour cost, and the reported effective rate. It goes further than the title by distinguishing the reported rate from the statutory rate and from OECD's modelled effective rate, which separates it cleanly from siblings like compare_tax_rates and compare_effective_tax.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'which is neither the statutory rate ... nor OECD's modelled effective rate ... the caveat keeps the three apart' passage gives clear disambiguation guidance for choosing among the tax siblings, and the NO_DATA note sets scope. However, it names the alternatives descriptively (Rules hub, Business hub) rather than by tool name, so an agent must map them itself; there is no explicit when-not-to-use statement.

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 mark this read-only/idempotent, and the description goes well beyond them: it discloses that OECD-uncovered countries have no `personal` block, are dropped from PIT rankings and are never scored 0, that figures are statutory not effective, and that a disclaimer is prepended to every response.

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 paragraph that leads with the core purpose and then layers scope, fallbacks and caveats. Nearly every clause carries information, though the closing disclaimer sentence is somewhat expendable for tool-selection purposes.

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

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

For a read-only multi-metric comparison tool with a full schema and an output schema, the description covers the invocation branch, the data limits, edge-case country handling and caveats. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it expands what the `metric` options actually measure (combined vs. central vs. small-business corporate rate; PIT top, threshold as a multiple of average wage, marginal rate including employee social contributions) and clarifies `sort`/`metric` are ignored when `countries` is given.

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 — statutory corporate and top personal income-tax rates compared or ranked by country — and names the source datasets and country scope. An agent can tell it apart from compare_effective_tax and compare_tax_burden without opening a 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 branches on the presence of `countries` (side-by-side comparison vs. ranking) and routes the agent away from alternatives by stating this is not the effective/blended take-home data behind `compare_contract`. It also names the exclusion cases (non-OECD-PIT countries).

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the four summed lines, why rent is excluded from the basket (double-counting caveat), that VAT is already embedded and never added, and the tax model assumptions (tax-resident, single filer, no deductions, special regimes like IFICI reported separately). This is exactly the extra behavioral context 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 core purpose, then method. The prose is dense and largely earns its place through the double-counting and tax-assumption caveats, though a few clauses (e.g., the VAT parenthetical) are verbose enough to slow scanning.

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 four parameters, no output schema, and a comparative calculation, the description supplies enough methodological grounding to call it safely. It stops short of describing the returned row/ranking structure, which is the one remaining gap given there is no output schema to cover it.

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

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

Schema description coverage is 100%, so sort, income, country, and maxPctOfIncome are fully documented in the schema itself (including the 'remaining' vs 'share' enum semantics). The description adds no parameter-level syntax or constraints beyond what the schema provides, 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 and resource ('what a month actually costs in each of 41 countries on a stated income, and what is left over') with clear scope. It is immediately distinguishable from siblings like compare_housing, compare_food_cost, or compare_tax_burden, which each cover only one of the four lines this tool sums.

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 'Estimates for comparison — not a quote and not tax advice' and by the methodological framing, but no explicit when-to-use/when-not guidance or named alternatives are given. An agent can infer intent but must guess whether compare_effective_tax or compare_tax_burden is the better pick for tax-only questions.

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 the safety profile is covered. The description adds genuinely useful behavioral context beyond that: B-READY is a rotating cohort (22 of 41 spine countries in 2025), out-of-cohort countries return NO_DATA rather than a borrowed figure, and every response leads with a not-advice disclaimer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded — the core purpose and data source come first, then coverage caveat, then query modes, then disclaimer. Every sentence carries information, though the single long paragraph could be trimmed slightly.

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?

Output schema exists so return format needn't be restated, and the description covers the data-coverage limits, ranking behavior, and disclaimer caveat. Combined with the annotations, an agent has what it needs; only minor implicit points (e.g., behavior of `limit`) remain.

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 60%, and the description compensates well: it enumerates the metric options, states the default (importDays), and explains the ordering semantics of `sort` (lowest first, `highest` to reverse). It also clarifies that `countries` is for a side-by-side; only `limit` is left to its own 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?

States a specific verb and resource (compare customs clearance days and compliance costs by country) and pins the exact source (World Bank B-READY International Trade topic) plus the four metric names. An agent can tell this apart from generic siblings like compare_countries 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?

Gives clear invocation patterns: fetch one country via `country`, a side-by-side via `countries`, or a ranked list by `metric` (default importDays, ascending unless `sort=highest`). It stops short of naming which sibling to use instead (e.g., compare_countries), 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?

The annotations already confirm this is a read-only, idempotent, non-destructive, closed-world operation. The description adds substantial behavioral context beyond that: hand-curated provenance with source URL and checked date, a `confidence: "secondary"` marker, yearly review rather than live feed, and an explicit legal-information disclaimer.

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 long but front-loads the core purpose and packs in relevant caveats for a tax-data tool: confidence marking, exclusions, review cadence, and disclaimer. Most sentences earn their place, though the volume of caveats makes it less tight than a maximal score would require.

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 output schema exists and annotations cover safety, the description still fills the important contextual gaps: how ranking differs from country lookup, how excluded countries are handled, how secondary sources are flagged, and how often data is refreshed. An agent has enough information to invoke and interpret 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 description coverage is 100%, and the description largely restates the schema's own semantics — comma-separated ISO alpha-2 codes, two or more, omit for ranking, and sort is ignored when countries are supplied. It ties parameters to output behavior well, but does not add much syntax or meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (compare/rank) and resource (standard and reduced VAT/GST rates by country), with the 41-country spine and source provenance made explicit. It is clear what the tool does, but it does not distinguish itself from nearby siblings such as compare_tax_rates or compare_tax_burden, 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?

It clearly describes the two usage modes: pass `countries` to get per-country rates, or omit it to rank standard rates. It also explains how countries without a single national rate are excluded and named rather than assigned a 0%. However, it does not explicitly state when to choose this tool over sibling alternatives, so a 5 is not warranted.

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 (readOnly, idempotent, non-destructive, closed-world), so the description goes further with genuinely useful behavioral context: data sources and vintage (ILOSTAT 2023+, OECD members only, World Bank WBL 2026), the OECD non-comparability caveat, drop-from-ranking semantics, legal-score-below-1 meaning, and an explicit statement about a deliberately absent metric.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded, leading with the two-mode framing before details. Length is justified by the surface area, though the closing sentence about absent statutory annual leave is a nice-to-know caveat rather than an invocation-critical fact.

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 formatting need not be described, and the description covers both invocation modes, edge cases, and data caveats. Required-parameter count is zero, so the optional-mode switching is fully explained.

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 above that by explaining what each metric represents, that `sort=fewest` inverts, and that `sort`/`metric` are ignored when `countries` is given, adding meaning beyond the enum labels.

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 dual-mode verb+resource: side-by-side comparison of weekly hours, annual hours, and paid parental leave for named countries, or a ranked list without them. An agent can distinguish this from near siblings like compare_public_holidays or employment_rules from the description alone.

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 splits the two call modes: pass `countries` for a side-by-side, omit it to rank the 41-country spine by a named metric with `sort` inverting direction. It also states defaults implicitly (metric weeklyHours) and the exclusion behavior (a country missing a metric is dropped, not scored zero), leaving little 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?

Beyond the annotations, it discloses crucial behavioral traits: absent data is omitted rather than null, every figure carries a source id, `tools` names the per-section detail tool, and `sources` lists only included material. It also states output size, date-based additions, and concrete absence examples. There is no contradiction with the read-only/idempotent 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?

It is front-loaded with a useful summary, but then becomes an extremely dense run-on enumeration of sections, fields, and date-specific additions. Much of that return-value detail is already available through the output schema, so the description is longer than necessary and harder to scan.

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

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

Given the tool's breadth, the description is complete: it covers what is returned, how absences work, optional income effects, provenance, and the post-2026 additions. With an output schema present, all remaining gaps are fully addressed.

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 parameters are already documented in the schema. The description reinforces that `income` unlocks total-cost figures but adds little syntax or format meaning beyond what the schema provides.

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 precise resource and scope: the three-to-six headline figures each hub owns for one country, returned in a single call. It enumerates every topic section covered, making it unmistakable as an aggregate overview tool distinct from single-topic 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?

It gives a clear use case — agents that would otherwise call a dozen tools to answer broad questions like 'tell me about moving to Portugal' — and implies that per-section detail should be fetched through the MCP tools named in the `tools` field. It does not explicitly name when to prefer specific comparison siblings, so it stops short of full 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 cover read-only/idempotent/closed-world, and the description adds substantial behavior on top: provenance (GOV.UK per-country table, authority page + check date, `confidence: "secondary"`), the critical absent-vs-zero rule, that mph limits sort by km/h equivalent, and that every response carries a disclaimer. This is more disclosure than the annotations could carry alone.

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 what a visitor gets, but the entire definition is a single dense paragraph of roughly 180 words packed with semicolons and parentheticals, which is hard to scan for mode selection. Everything is arguably load-bearing, yet the wall-of-text form hurts retrieval and reading.

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 shape needn't be re-explained; the description instead covers scope (41 countries), data provenance, staleness caveat, and the absent-vs-zero edge case. 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: `speedUnit` is the unit signed locally and never converted, `bacNote` holds novice/professional limits while 0 is a genuine zero-tolerance rule, `idpRequired` reflects a UK-photocard GOV.UK table and is absent where silent, and ranking/sort semantics for mph values. It stops short of 5 only because some schema-documented params (e.g. `limit`) get no extra color.

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 (driving rules) and enumerates exactly what it returns: side of road, urban/rural/motorway speed limits, BAC limit, required equipment, IDP — for a named set of 41 countries. This is unmistakably distinct from siblings like travel_advice or legal_profile.

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?

Spells out the three invocation modes clearly: `country` for one entry, `countries` for a side-by-side, and neither for a ranked list with `metric`, `sort`, and optional `drivesOn`/`idpRequired` filters. It never names an alternative sibling tool or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare read-only/idempotent, but the description adds substantial extra context: hand-curated provenance with authority page and check date, the `confidence: "secondary"` marker for unfetchable official pages, the ABSENT-never-zero convention, federal-floor handling, and the mandatory not-legal-advice preamble in every response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded and almost every clause carries decision-relevant information. It is a single long paragraph, which slightly hurts scannability, but there is little genuine filler.

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

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

For a 5-param, output-schema-backed reference tool, the description covers selection modes, defaults, absence semantics, provenance and confidence, and disclaimers. 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 already 100%, so baseline is 3, but the description adds real meaning the schema does not: singular vs plural country semantics, that annual leave days are never converted from their `basis`, that `noticeNote` rises with tenure, and how `excluded` is populated for countries with no figure.

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 (statutory employment floors across 41 countries) and enumerates the exact figures returned: annual leave with `basis`, employer/employee notice weeks, probation ceiling, weekly-hours ceiling. This clearly separates it from siblings like compare_working_time, compare_public_holidays and compare_contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the three invocation modes precisely — `country` for one entry, `countries` for a side-by-side, neither for a metric ranking with `sort` and `excluded` — plus the default metric. It also notes the scope limit ('Statutory floors only — contracts and collective agreements usually give more'), which effectively excludes contract-level questions, though it does not name a sibling to redirect to.

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

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

Adds substantial behavior beyond annotations: flat-rate application, basis measured vs modelled, employee-side rates returned but never applied, NO_DATA instead of 0% for uncovered countries, New Zealand's real 0%, caveats about ceilings/excluded schemes, and a not-payroll/legal-advice disclaimer. This is rich, non-contradictory 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?

Dense but front-loaded single paragraph; every sentence carries operational information (formula, defaults, coverage, caveats) with no filler. It could be split for readability but nothing is 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?

Given the 6 optional parameters, output schema, and rich annotations, the description completes the picture: it explains the default wage logic, ranking behavior, coverage limits, NO_DATA semantics, and the contextual figures returned. Nothing an agent needs to call or interpret the tool 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 defines all six parameters including defaults and enum values. The description largely restates defaults (gross optional, midpoint fallback) and mentions `basis` (an output field) rather than adding new syntax or constraints, 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 resource (employer cost of a hire) and the exact formula (gross wage plus employer social security at the OECD rate), and distinguishes the figure from employee-side rates and tax wedge. However, it does not name or route against any sibling tool such as compare_total_cost, so sibling differentiation is implicit rather than explicit.

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 clear context (employer-of-record fee quoting) and parameter-conditioned behavior: pass gross for your own figure, omit country to rank, omit gross to use the pay-range midpoint. But it never states when to prefer this tool over a sibling like compare_tax_burden or employment_rules, nor any when-not condition beyond coverage 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 read-only, idempotent, non-destructive behavior, but the description adds meaningful context: the estimation formula (usPrice × pppIndex^elasticity), the Balassa-Samuelson rationale for non-tradables, and the critical caveat that these are 'model estimates, not price quotes.' It does not cover data recency or accuracy limitations, but the core behavioral traits are well disclosed.

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 the purpose and efficiently packs the formula, return summary, and caveat into a compact paragraph. It is dense but has no filler; the return summary is somewhat redundant given the output schema, but it still aids quick comprehension.

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, a rich input schema, and an output schema, the description appropriately focuses on methodology and the 'model estimate' caveat. It is nearly complete for correct invocation, though it omits any when-to-use guidance relative to 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 parameter meaning is already fully documented. The description adds no parameter-specific details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Estimates') and resource ('local prices for a 32-item everyday basket') in two countries, making the scope clear. It distinguishes itself from generic cost tools by naming the basket and the Pint & Property Index, but it does not explicitly contrast with siblings like compare_food_cost or compare_total_cost.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance or alternatives are provided. The description explains the model and output but never says when an agent should choose this tool over siblings such as compare_food_cost or calculate_ppp.

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