reference-data

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

Annotations already establish read-only, idempotent, closed-world behavior, but the description goes well beyond them: it enumerates the country statutory weekend rules, discloses that regional holidays are NOT applied, and names two concrete refusal modes (year_not_held with years_held, holiday_date_pending). That is exactly the behavioral context an agent cannot get from structured fields 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 the metering status and the core operation, then progressively narrows to edge cases, refusal modes, and exclusions. It is dense and multi-clause, but nearly every sentence carries a distinct rule an agent needs; only the parenthetical country-rule laundry list is slightly over-packed.

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-shape details are correctly omitted, and the description still covers the failure modes, the calendar-coverage boundary, and the exclusions an agent must know to call this safely. Little is left for the agent to discover at runtime.

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

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

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds semantics beyond the schema: the start date is day 0 and never counted, n=0 returns the date itself if it is a business day else the next one, and negative n walks backward. The only gap is that the +/-500 bound and country-code format are left entirely 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?

Precise verb+resource: add N business days to a start date, with the direction (negative n walks backward) stated up front. This cleanly separates it from siblings like business_days_between, count_working_days, and is_business_day, which count or test rather than advance a date.

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 explains the day-0 convention and the n=0 edge case, which implies the correct usage context, but it never explicitly names an alternative tool or states when to prefer this over business_days_between/count_working_days. Usage is inferable rather than routed.

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, the description adds substantial behavioral detail: it is free and unmetered, defines the counting semantics including negative ranges, explains that weekend days and public holidays are returned, lists specific statutory weekend rules, and documents error behaviors such as year_not_held and holiday_date_pending. These are all meaningful operational traits not covered by the readOnly/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?

The description is front-loaded with the core purpose and key constraint, and most sentences are dense with useful detail. It is somewhat long and includes several illustrative country examples that, while relevant, could be trimmed for brevity, but the structure remains clear and purposeful.

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

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

Given the tool's complexity and the existence of an output schema, the description is complete enough for correct invocation. It covers calculation semantics, return contents, calendar limitations, and explicit error conditions, leaving no significant ambiguity for an agent to resolve.

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?

Although schema coverage is already 100%, the description adds important semantic meaning: country selects a national public-holiday calendar and statutory weekend rule, from/to follow half-open interval semantics with potential negative counts, and regional holidays are excluded. This goes well beyond the schema's terse date and country-code 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 precise verb and resource: counting business days between two dates. It distinguishes itself from the sibling add_business_days by explaining the inverse relationship and the interval convention '(from, to]', and it clarifies the inclusive-counting variant, so an agent can identify the tool's exact purpose without opening the schema.

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

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

The description clearly explains when the tool is appropriate: counting business days between two dates while accounting for national holidays and statutory weekends. It also notes limitations such as regional holidays not being applied and errors for unsupported years, but it does not explicitly contrast with other date-related siblings like is_business_day or count_working_days.

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 (readOnly/idempotent/openWorld), it discloses pricing ($0.50), the x402 payment flow, shared rate limits (3 free calls per IP per day), free refusals on incomplete coverage (coverage_gap, no_charge), and receipt issuance/verification semantics. This is unusually rich behavioral disclosure for a paid tool.

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 price and action, but the remainder is a dense run-on mixing pricing, payment, rate limits, receipt semantics, and verification. The receipt explanation partially duplicates the schema's own description, adding some redundancy.

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

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

With an output schema present, return values need not be described, and the description covers payment, refusals, limits, and receipt behavior. It is close to complete for a complex paid tool, missing only explicit sibling routing.

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 the baseline is 3, but the description adds genuine semantics: omitting buyer_country for single-country maths, api_key bypassing x402, and the receipt flag's effect on paid successes. It goes beyond 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?

The description states a specific verb and resource ('Charge this sale') and enumerates the deliverable precisely: VAT applicability, place of supply under EU/UK/South Africa rules, net/VAT/gross, registration threshold, and rule cited. It distinguishes the answer receipt from the certified extract, though it does not explicitly differentiate itself from the sibling compute_vat.

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 concrete invocation conditions: 'Omit buyer_country for single-country rate maths', 'Pass api_key if you have one; otherwise the result is the x402 payment requirement', and the free-refusal behavior. However, it never routes the agent explicitly between charge_sale and the sibling compute_vat or charge_sale_certified.

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 price ($0.75), the free-refusal policy and its reasons, rate limiting (3 free/IP/day), auth paths (api_key bypasses x402), and exactly when a receipt is and is not included. This is unusually rich behavioral disclosure for a paid tool.

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 front-loads the price and the core deliverable, then the refusal policy, then auth. Efficient but dense, with the receipt/certified-extract distinction repeated in both description and schema, which costs a little polish.

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 paid, complex, high-stakes tool this covers cost, payment paths, refusal semantics, rate limits, and verification route, and an output schema exists so return values need no prose. Nothing an agent needs to invoke it correctly is absent.

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 8 parameters including net/gross, buyer_type defaults and api_key bypass. The description largely restates the receipt flag rather than adding new parameter semantics, so the baseline 3 applies.

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

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

The opening line states a concrete verb, resource and price: 'charge_sale dossier plus an Ed25519-signed certified extract of the governing VAT rate.' It explicitly differentiates from the answer-receipt SKU and the non-MCP /v1/certified series extract, so an agent can situate it against sibling charge_sale and the answer 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 gives strong operating context: use 'for a filing', refusal is free for coverage_gap/no_charge, 3 free calls per IP per day shared with answer tools, and api_key vs x402 fallback. What is missing is an explicit routing statement against the sibling charge_sale (when to pay $0.75 for certification vs the plain charge).

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 safety, and the description layers on pricing ($0.02), auth/payment flow, honest statuses when no enforceable floor exists, the refusal to guess cross-period conversions, receipt semantics, and a not-legal-advice disclaimer. This is substantial behavior beyond 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?

Purpose and output are front-loaded, and the payment/disclaimer content is relevant. However, the single dense paragraph with nested parentheticals about x402, certified extracts, and receipts is crowded enough to slightly impede 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?

An output schema exists so return values needn't be explained, yet the description still summarizes them; combined with payment, receipt, and edge-case handling, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds meaning for api_key (bypasses x402, metered) and receipt (no extra USDC, unpaid 402s excluded) and clarifies that period must match the floor's period. Some content duplicates the schema, keeping it from a 5.

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

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

States a specific verb+resource ('is a salary at, above or below the country's statutory minimum wage?') and names the exact outputs (verdict, margin, statutory floor, legal instrument). No sibling tool covers minimum-wage compliance, so it is clearly distinguishable.

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 payment paths (api_key for instant checkout vs x402), notes the evaluation country is free to try, and points to list_series for the country list. It lacks explicit when-not-to-use guidance versus siblings, but the context is clear.

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

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

Goes well beyond the annotations by disclosing cost ($0.02), that malformed requests are refused free, that missing countries are surfaced under a 'missing' key, that each row carries its own source/dates/labels, and the api_key vs x402 payment path. Annotations cover safety/idempotency, but this adds concrete pricing, error and auth behavior.

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 paid cost and the core one-series-many-countries scope, and each clause carries operational detail. It is a dense run-on paragraph and includes sibling pricing ('Register: $0 · Delivery after trial: $0.05') that is arguably outside this tool's remit.

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 paid, open-world read tool with an output schema, the description covers cost, payment/auth paths, error handling, the missing-countries behavior, and the recommended follow-up binding. Nothing an agent needs to invoke it correctly is absent.

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, and the description adds value by giving concrete series examples (vat, policy-rate, minimum-wage, corporate-tax) and restating the 10-country cap, plus explaining the api_key alternative path. It stops short of documenting any format beyond the schema.

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

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

States a specific verb (compare) and resource (one series across countries) with scope bounded to 'up to 10 countries of this brand in one call'. It is clearly distinguishable from siblings like get_series (single fetch) and get_series_history (time series) because it frames the multi-country, single-call dimension.

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 context for when it applies (one series, many countries) and names the correct follow-up tools (get_changes or register_alert) to use after a 200. It does not, however, explicitly contrast itself with get_series/get_snapshot, so the 'when not to use' side 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?

Goes well beyond the readOnly/idempotent/destructive annotations: discloses the $0.05 price, the nonzero 'refused list' semantics for unpriceable schemes, the Ed25519 receipt behavior, and the payment/auth mechanics. This is exactly the kind of mutation-adjacent, billing-relevant context an agent needs.

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

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

Front-loads the core purpose and the income-tax exclusion well, but the tail of the description is a dense run-on about receipts, certified extracts, and legal disclaimers that partly duplicates the schema's receipt field. It is informative rather than padded, but not maximally tight.

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 still covers the non-obvious complexities of a paid, open-world tool: pricing, payment fallbacks, refusal semantics, and receipt verification. Nothing essential to correct invocation appears 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 4 params are enum-constrained, so the schema carries most of the burden (baseline 3). The description adds real meaning for receipt (default false, paid-success only, not a certified extract) and api_key (bypasses x402), lifting it above baseline.

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

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

States a specific verb and resource with scope: 'prices every statutory contribution on both the employee and employer sides for a gross salary.' It further distinguishes itself from compute_income_tax by explicitly excluding income tax and naming an alternative, so an agent can route correctly 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 gives when to use (cost-to-employ pricing), when not to use (income tax), and the alternative ('use compute_payroll for gross-to-net take-home'). It also explains the payment path (api_key vs x402) and that the evaluation country is free to try via list_series.

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

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantial context beyond that: the paid model ($0.02, x402 fallback, api_key bypass), what the optional receipt does and does not certify, and a pointer to verify_answer_receipt. These are behavioral facts an agent cannot get 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?

Purpose and the taxable-vs-take-home caveat are front-loaded, and the pricing banner leads. It is appropriately dense for a paid tool, though the receipt/certified-extract distinction is repeated here and again in the schema, adding some redundancy.

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

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

With an output schema present, return values need not be described, and the description still covers payment, fallback auth, receipt scope, and the scope_note pointer. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, so this is the baseline case. The description reinforces the currency/period basis for taxable_income and explains the receipt and api_key semantics, but largely restates what the schema already documents in detail.

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

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

Names a specific verb-and-resource ('Statutory income tax on a TAXABLE-income figure') and scopes it precisely to the country's verified marginal bracket schedule with per-bracket workings, effective and marginal rate. This clearly separates it from siblings like compute_vat and compute_employment_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?

Explicitly states the boundary condition ('this is tax on taxable income, NOT net take-home pay — reliefs/allowances and social-security contributions are the caller's concern'), which is real when-to-use guidance. It also routes the free-trial user to list_series, but never names compute_employment_cost or compute_vat as the alternative for payroll/consumption taxes, so sibling disambiguation 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 only declare the safety profile (readOnly, idempotent, non-destructive). The description goes well beyond: price ($0.02), free-refusal semantics for disagreeing dates and mechanism-only series, the api_key vs x402 payment paths, and receipt behavior. This is exactly the extra 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?

The core formula is front-loaded, but the block is long and partly redundant — 'Not legal advice' appears twice and the receipt/certified-extract distinction is restated from the schema. Pricing, refusal, and payment details all compete in one dense paragraph.

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 paid, open-world computation with an output schema (return values need not be described), the description covers pricing, payment paths, refusal edge cases, receipt verification, and scope limits. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds the days-vs-from/to mutual-exclusion consequence (a free refusal rather than a wrong answer) and the meaning of the receipt flag. The api_key payment behavior is also explained beyond the terse schema string.

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 interest on a principal at a series rate) and pins down the exact method (Actual/365 simple, principal × rate/100 × days/365). An agent can distinguish this from compute_income_tax, compute_vat, and other compute_* siblings 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?

Clearly states how to invoke it — pass either days or from/to, with the conflict-refusal rule — and sets a scope boundary (jurisdiction-specific compounding and day-count statutes are not applied). It does not explicitly route the agent among siblings, but the mechanics and exclusions are well covered.

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-destructive, but the description adds substantial behavior beyond them: the $0.01 price, the x402 payment flow, that the receipt only appears on a paid success (not on 402 or free refusals), that it costs no extra USDC, that it is not a certified extract, and that it is not legal advice with a verification path via verify_answer_receipt. This is unusually complete disclosure for a paid tool.

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 price and the core purpose, then mode semantics, then payment, then the receipt caveat. Every sentence carries distinct information, though the payment/receipt discussion is dense and could be tightened slightly without losing meaning.

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. Given the tool's complexity (paid, dual-mode, optional receipt, verification), the description covers pricing, payment, free tier, receipt behavior, and the verification sibling, leaving no gap 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, and the schema already documents mode, amount, api_key, country, and receipt. The description adds real value beyond the schema: it explains the payment consequence of passing api_key, the free-trial country, and that receipt is free on paid success, which the schema's terse 'Default false' line does not convey.

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

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

States a specific verb and resource ('VAT breakdown for an amount') and immediately disambiguates scope: net/tax/gross from the country's statutory rate, including composite per-levy components (Ghana VAT + NHIL + GETFund). It also distinguishes itself from the non-MCP certified-extract SKU, so an agent can tell it apart from siblings like compute_income_tax and the certified endpoint.

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

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

Gives explicit mode semantics (add = amount is net, extract = backs VAT out of gross), states when to pass api_key vs rely on the x402 payment explanation, notes the evaluation country is free (routing to list_series), and names the alternative it is not (GET /v1/certified/{country}/{series}). Conditions for each branch are spelled out rather than implied.

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

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

With readOnlyHint/idempotentHint/destructiveHint already declaring the safety profile, the description goes well beyond them: exact price, free-refusal behavior on coverage gaps, per-IP rate limiting shared with other tools, x402 payment path, api_key metering for invoicing, and the Ed25519 receipt's limits (not a certified extract, not legal advice). This is the kind of behavioral context an agent needs and cannot get 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?

Front-loading the price and the core deliverable is good, but the description is dense and rambling, embedding a receipt disclaimer and a certified-extract SKU note (explicitly not an MCP tool) that do not help an agent select or invoke this tool. Several clauses could be cut without losing selection signal.

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 still covers cost, refusal semantics, rate limits, payment paths, and receipt behavior. The only real gap is the unaddressed boundary against closely related siblings, which the usage dimension already penalizes.

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 every parameter is already documented in the schema, which sets the baseline at 3. The description restates a few parameter effects (income tax on taxable_income, first working day from start_date, receipt default false) but adds little beyond the schema text, and it even mentions NG/KE PAYE while the country enum permits only 'ae'.

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 deliverable: cost a hire by returning a cited dossier with a wage-floor verdict, employer/employee contributions, employer cost, and optional income tax. It is clearly distinguishable from generic siblings like compute_employment_cost or check_minimum_wage, though it never explicitly says how it differs from them. Naming the covered country (AE) further narrows the scope.

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 context (paid at $0.50, free refusal on coverage_gap, shares the 3 free calls/IP/day, pass api_key or get an x402 requirement), which implies when the call is viable. However, it never states when to choose this over siblings like compute_employment_cost, hire_compare, or check_minimum_wage, leaving the main routing decision to inference.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantial behavior beyond them: pricing ($0.002), the unpaid-402 payment path via x402, the free evaluation country, the 366-day range cap, refusal behavior for bad subdivisions, and the fact that an answer receipt is not a certified extract nor legal advice. That is exactly the kind of side-effect and auth/cost disclosure 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-loads the core purpose and scope before cost/payment details, which is the right ordering for an agent deciding whether to call it. It is still dense and repeats the receipt/not-a-certified-extract language that already appears verbatim in the receipt parameter schema, which is minor 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 values need not be described, and the description covers cost, payment, limits, refusals, and disclaimers — leaving little an agent must discover at call time. The remaining gaps are the ambiguous 'evaluation country' (which of the nine enum values is free) and no routing versus business_days_between.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning beyond the schema's one-line 'API key' and 'API key' defaults by explaining what happens when api_key is absent (x402 payment instructions in the response) and clarifying receipt economics and the verify_answer_receipt follow-up. The unstated 'which country is the evaluation one' is the only material gap.

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 with scope: 'Working days in a date range for a country', plus concrete rules (weekends incl. Egypt's Fri–Sat, statutory holidays, holidays returned by name, next working day after range). However it never distinguishes itself from the very similar sibling business_days_between, leaving an agent to guess which of the two to call.

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 practical usage context (pass api_key if you have one; otherwise the response explains x402 payment; the evaluation country is free) and a hard constraint (range max 366 days). It offers no when-to-use/when-not guidance relative to add_business_days or business_days_between, so selection is largely 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?

Goes well beyond the readOnly/idempotent/openWorld annotations: exact price ($0.25), the free-refusal contract (coverage_gap, no_charge), shared rate limit, payment fallback behavior, and what the receipt flag does and does not produce. Notably it clarifies an answer receipt is not a certified extract and is not legal advice, plus how to verify it.

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

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

Front-loads the price and the product definition, then the payment and receipt mechanics, which is the right order. The prose is dense and parenthetical, with a slight tangent about the $0.10 certified SKU not being an MCP tool, but every clause carries information an agent needs for a paid call.

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 paid, open-world tool with an output schema, the description covers pricing, auth/payment paths, refusal semantics, rate limits, and receipt scope, so an agent can invoke it correctly. The remaining gap is sibling routing guidance against get_country_brief and charge_sale_certified.

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 the baseline is 3; the description still adds semantic value by explaining that all named series must be certifiable (a cross-parameter constraint the schema cannot express) and by restating the receipt's conditional, no-extra-cost behavior. It does not, however, add format details for series ids beyond the schema.

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

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

States a specific verb+resource bundle: 'the full cited country brief plus up to 3 Ed25519-signed certified extracts' with the default series named. It also differentiates from siblings implicitly (get_country_brief is the brief alone, the $0.10 certified extract SKU is explicitly called out as not an MCP tool), so an agent can tell what this buys versus adjacent 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?

Gives real operating conditions: pass api_key if you have one, otherwise expect the x402 payment requirement, and the 3 free calls per IP per day shared with the answer tools. It also states the all-or-nothing rule ('Named series must all be certifiable') and the refusal path. It stops short of explicitly saying when to prefer this over get_country_brief or charge_sale_certified, so it is clear context without alternatives 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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantial context beyond them: no metering/cost, 400/404 responses are free, and a 402 is flagged as a gate bug that should not be paid. It also exposes derivation rules (reverify_by from last_confirmed + update_cycle_days), the conditional emission of next_effective_known, and anti-hallucination guarantees (never parses notes, does not invent MPC/budget/wage-review dates).

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

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

Cost and endpoint are sensibly front-loaded, but the text then runs into a dense stream of caveats with undefined jargon (last_confirmed, update_cycle_days, stale, MPC) that assumes prior knowledge, harming readability. Several clauses are genuinely useful, but the run-on construction and internal shorthand 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?

With an output schema present, return values need not be re-explained, yet the description still covers derived fields, conditional omissions, error-code economics, and where historical data lives. The main omission is a plain statement of what the calendar contains for a first-time caller, but overall an agent has enough 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 coverage is 100% and the two parameters are fully documented in the schema (ISO 3166-1 alpha-2 format, series example policy-rate, omission semantics, free-on-mismatch behavior). The description reinforces the same facts but adds little syntax or format detail the schema lacks, so this lands at the 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 the concrete resource/endpoint (GET /v1/calendar) and scope (this brand's continent, optional country/series), and it names the sibling that owns past data (get_changes), so it is distinguishable from adjacent tools. It stops short of plainly saying 'returns upcoming compliance/effective-date events with reverify windows', leaving the actual subject matter to be inferred from field names like reverify_by and next_effective_known.

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 operating context: FREE and unmetered, omit country for all series on the continent, valid-but-unmatched country stays free, and past changes belong on get_changes. This routes the agent to the right tool for historical vs current data. It lacks an explicit 'use this when you need X' framing and does not contrast with the many compute_* 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 read-only, idempotent, open-world, and non-destructive traits, and the description still adds substantial behavioral context beyond them: return ordering (newest first), per-row fields (last_confirmed, stale), the 1/7/30/90-day freshness buckets, and pricing/metering ($0 free, alternatives at $0.05/$0.10). Nothing is left for the agent to infer about cost or shape.

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 key fact ('FREE unmetered') and well organized, but it carries some non-essential weight: the slogan 'Freshness is checkable or it is marketing' does no routing work, and pricing parentheticals add length. Still, most sentences earn their place by steering the agent away from paid alternatives.

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

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

An output schema exists, so return values needn't be fully enumerated, yet the description still describes the shape (per-series freshness fields plus a dataset summary). Combined with the alternatives and cost model, an agent has everything needed to select and invoke this correctly.

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

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

Schema coverage is 100% for the single `since` parameter, so the baseline is 3, but the description adds genuine semantic meaning beyond the schema's format note: it defines what `since` filters on (series whose current value *took effect* on or after that date) and restates the default window. The added value is real, though modest for a one-param 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+resource combination ('FREE unmetered change + freshness feed') and precisely what it returns: every series whose current value took effect on or after `since`, plus a dataset-wide freshness summary. It differentiates itself from siblings by naming get_series, register_alert, and the certified endpoint as distinct things to use instead.

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

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

Explicit trigger ('After any paid series or answer call, call this before you assume the cached value is still the law'), an explicit anti-pattern ('Do not re-pay get_series to discover a diff'), and named alternatives with conditions ('For a push bind, use register_alert', 'For a filing freeze ... GET /v1/certified/...'). When/when-not/alternatives are all covered.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses cost ($0.01 per call), the two auth paths (api_key from card checkout at /pricing, otherwise x402 payment instructions returned in the response), and the pricing of the downstream registration/delivery. That is exactly the behavioral context an agent needs before invoking a paid, open-world tool.

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 price and purpose, then contents, then auth, then follow-up actions — a logical ordering with no filler sentences. The parenthetical pricing clauses add density but each carries concrete 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 shape need not be explained; the description covers the remaining gaps an agent faces — payment/auth mechanics, aggregate vs per-series economics, and what to bind afterward. Nothing material for correct invocation 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 both params are already documented, but the description adds real meaning to api_key by explaining the fallback x402 flow and to country by implying the full bundle is fetched for that one jurisdiction. It stops short of adding format detail beyond ISO codes already in the enum.

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

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

States a specific verb and resource ('Country brief: every reference series we hold for one country ... in one call') and enumerates the contents (policy rate, VAT/GST, CPI, taxes, minimum wage, holidays). This clearly separates it from per-series siblings like get_series, get_series_history and list_series, which it explicitly compares against ('Cheaper than buying the series one by one').

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 selection criterion: use this aggregate call instead of purchasing series one by one, and routes to the correct follow-up tools after a successful call (get_changes for free polling, register_alert for HMAC push). It does not name a hard exclusion case (e.g. when a single-series tool is preferable), so it falls just 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; the description adds valuable behavior beyond that: weekend/holiday rolling with every skipped day listed, roll_unverified flagging when source is ambiguous, coverage_gap for unverified countries, and the after-200 get_changes/register_alert binding for freshness. This goes well past the annotation bar.

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?

Loads of valuable detail, but pricing ($0.003, $0.05 delivery), free-HTML pointer, and the change-binding sentence make it long and front-loads price before purpose. Efficient for the content it holds, but denser than needed for tool selection.

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

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

An output schema exists, so return-value explanation is unnecessary. The description covers semantics an agent needs: rolling behavior, verification flags, coverage gaps, and freshness path – complete for a read 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 coverage is 100% and describes every parameter including defaults and the 400-day cap. The description adds only the year_end re-anchoring rationale and clarifies window semantics implicitly, which is marginal against a fully-documented 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?

Specific verb+resource: returns recurring statutory tax deadlines (VAT/PAYE/CIT) as cited rules plus rolled due dates for a country. Clearly distinguishable from sibling compute_vat/compute_income_tax (which compute amounts) and get_public_holidays (which lists holidays) because it returns rules and dates.

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 when the paid series is warranted (rolling, citations, coverage gaps) and points to a free HTML alternative plus year_end re-anchoring. Doesn't explicitly exclude the siblings like compute_vat, but the use case is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld. The description adds real value beyond them: the pricing behavior ('FREE', 'Never metered') and the dual auth path. It does not mention pagination or error behavior, but with an output schema present the return shape is covered.

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: cost and return contents come first, then auth mechanics. Every phrase carries information, though the parenthetical '(free, card or metered)' packs three concepts into a fragment that reads slightly telegraphically.

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?

Complete for a zero-required-parameter, single-purpose read tool: it covers cost, return fields, plan/coverage semantics, and both authentication paths, while the output schema handles return structure. 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 description coverage is 100% and the schema already explains api_key is optional when sent as a header. The description reinforces this by stating the alternative header mechanism explicitly, adding marginal convenience rather than new semantics.

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 (get key balance) and enumerates exactly what is returned: plan, quota, used, remaining, reset date, coverage. No sibling tool overlaps this domain, and the name alone would be ambiguous without this detail.

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 says 'FREE' and 'Never metered', telling the agent this is a no-cost, non-billing call, and explains the two calling conventions (api_key param or X-API-Key header). It stops short of naming alternatives or when-not-to-call, but for a one-purpose utility tool there is little ambiguity.

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, openWorld), so the description's job is to add non-obvious context, which it does: 'FREE' signals no cost, results cite an official government source, and the national+regional merge behavior is spelled out. It stops short of describing caching or result limits.

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

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

Two sentences, front-loaded with the key 'FREE' qualifier and then the regional-calendar nuance. It is appropriately sized, though the German Laender example is verbose for a detail that does not apply to the supported enum.

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 points to the `subdivisions` field usefully. However, it foregrounds a German example ('DE-BY', German Laender) while the country enum contains only nine Middle East codes, so the region guidance is misleading rather than helpful for the actual supported set.

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 country enum and the subdivision parameter are already fully documented in the schema (including the 'DE-BY' example and the national/regional tagging). The description largely restates that, so the baseline of 3 applies; it adds only the pointer that the `subdivisions` output field enumerates valid regions.

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+resource ('Official public-holiday calendar for a supported country') and adds scope details about gazetted movable holidays and cited government sources. It is clear on its own, but it never distinguishes itself from the sibling get_public_holidays_worldwide, leaving the agent to infer which one to prefer.

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: passing `subdivision` vs omitting it is described, and the region-merge behavior is explained, but there is no explicit statement of when to choose this tool over get_public_holidays_worldwide or get_calendar. The agent must infer the selection criteria from the 'supported country' phrasing.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the call is free, unmetered, and never counts against allowance, plus the auth mechanics (pass api_key or send X-API-Key header). It doesn't describe response structure, but that is secondary.

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 highest-value qualifier ('FREE') and tightly written. The free-key URL is somewhat promotional but earns its place by telling the agent how to obtain access; the four sentences are efficient overall.

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. The description covers scope, cost, and authentication, leaving little an agent needs to invoke it correctly, though it provides no note on the national-vs-regional tagging behavior that the subdivision param implies.

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 api_key, country, and subdivision in detail. The description reinforces the api_key/header auth option but adds no syntax or meaning beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description states a specific verb+resource and explicitly differentiates from its sibling: 'Same as get_public_holidays, but for every country across all seven brands, not only Middle Eastern.' An agent can immediately tell what it returns and how it differs from get_public_holidays 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?

It clearly frames the selection condition against the sibling (worldwide vs Middle Eastern only) and adds a strong cost-based reason to prefer it ('Unmetered: never counts against the key's allowance'). It doesn't explicitly enumerate exclusions or other holiday-related siblings, but the routing context is clear.

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

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

Annotations only cover the read-only/idempotent safety profile; the description adds the details an agent actually needs: cost ($0.003), the two payment paths (api_key vs x402), the free-trial carve-out for AE, and exactly what fields each value returns (citation, effective date, last-confirmed, staleness). That is substantive behavioral context 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 most decision-relevant fact ('PAID ($0.003)') and dense with useful content per sentence. Several clauses (payment mechanics, chaining) are essential, though the parenthetical pricing on register_alert is close to noise.

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, yet the description still summarizes them helpfully. Pricing, payment paths, trial scope and follow-up chaining are all covered, leaving little an agent must guess before invoking.

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 a little meaning for api_key (card checkout at /pricing) but otherwise restates the series examples already present in the schema and adds nothing about country.

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: 'Current value of a reference series', with concrete examples (policy-rate, vat, minimum-wage). 'Current' implicitly separates it from get_series_history, but the description never names that sibling, so differentiation is inferred 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?

Gives real conditional guidance: pass api_key if you have one, otherwise pay via x402, and every AE series is free to try. It also routes the agent to follow-up tools (get_changes for polling, register_alert for HMAC push). It stops short of saying when to prefer this over get_series_history or list_series.

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, yet the description goes further and discloses pricing, the authentication paths (api_key vs x402), the free AE trial, and the warning that an unbound series value can be silently retired by a later gazette. This is exactly the kind of behavioral 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?

Three dense sentences, front-loaded with price and purpose, with no filler. The final sentence about binding get_changes/register_alert borders on upsell but is functionally relevant, so the sizing is defensible.

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 annotations cover the safety profile. The description fills the remaining gaps (payment, filtering, follow-up), leaving only the when-vs-sibling question unanswered.

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 documents from/to formats, series id, api_key, and the country enum. The description mostly restates the from/to date format and api_key role, adding only the 'AE is free' nuance, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Historical values of a reference series with effective date ranges, optionally filtered by from/to.' This is clearly distinct from get_snapshot/get_series by the 'historical' and 'effective date ranges' framing, though it never explicitly contrasts itself with those 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 strong operational context: paid at $0.003, pass api_key for instant checkout, otherwise follow the x402 flow, and AE series are free to try. It also routes the agent to follow-on tools (get_changes, register_alert) after a 200, but does not say when to prefer this over get_series or list_series.

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 openWorld, so the bar is lower. The description adds genuinely valuable behavior beyond that: it is a PAID call ($0.02), auth is optional via api_key with an x402 fallback, AE series are free to try, and a later gazette can silently retire values. That is substantive context the annotations cannot convey.

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

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

Front-loading 'PAID ($0.02)' is effective, but the body is dense with parenthetical pricing fragments ('Register: $0 · Delivery after trial: $0.05') that are about a different tool and compete with the core message. Appropriately sized overall, yet cluttered and not cleanly structured.

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 annotations carry the safety profile. The description covers payment, auth, trial behavior, and the recommended follow-up chain, leaving little an agent needs missing before invoking 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?

With one parameter at 100% schema coverage the baseline is 3, but the description goes further by clarifying api_key is optional ('if you have one') and describing what happens when it is absent (x402 payment explanation in the response). This adds real meaning beyond the bare 'API key' schema string.

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 with scope: 'Snapshot of every series for every country in one call.' The 'every series / every country in one call' phrasing implicitly separates it from single-series siblings like get_series and get_series_history, though those siblings are never named. Purpose is clear but sibling differentiation is left to inference.

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 explains what to do AFTER a 200 (bind get_changes or register_alert) and how to handle auth/payment, but never states when to choose get_snapshot over get_series, list_series, or get_series_history. Usage is implied through the chained workflow rather than an explicit 'use this when' condition.

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 the safe read-only/idempotent profile, and the description adds substantial behavioral context on top: cost tiers, the api_key-vs-x402 payment branch, free coverage_gap refusals, quota sharing with the answer tools, the optional Ed25519 receipt only on paid success, and the verification path. This is exactly the beyond-annotation detail an agent needs.

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

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

A single dense paragraph that leads with pricing rather than the tool's purpose, and repeats the receipt/certified-extract distinction that also appears verbatim in the schema. Every fact is relevant, but the ordering and duplication cost readability.

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

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

With an output schema present, the description needn't explain return values, and it still covers pricing, coverage limits, refusal semantics, payment flow, and receipt verification. 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, and the description goes further by stating gross is in each country's own currency with no conversion, listing the allowed country brands, and confirming 2-5 hires. Those currency and range clarifications are genuine meaning beyond the schema fields.

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 and enumerates the exact outputs (employer cost, employer/employee contributions, on-cost percent, wage-floor verdict) computed 'side by side and ranked' for 2-5 hires. This implicitly separates it from single-hire siblings like compute_employment_cost and cost_hire, but never names them, so the differentiation is inferred 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?

Gives clear operating context: 2-5 countries from a fixed list, pricing tiers ($0.75 for 2, $1.00 for 3-5), free refusal for unanswerable requests, and shared 3-free-calls-per-IP quota. It stops short of telling the agent when to prefer a sibling tool (e.g. compute_employment_cost for a single hire) or when not to call this at all.

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?

Well beyond the readOnly/idempotent annotations, it discloses price ($0.60), the free-refusal-on-coverage-gap behavior (coverage_gap, no_charge), shared 3-free-calls-per-IP-per-day quota, api_key vs x402 payment flow, receipt semantics, and explicit scope limits (not a certified extract, not legal advice). For a paid, open-world read this is exactly the behavioral context an agent needs.

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

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

Purpose is front-loaded in the first sentence and nearly every subsequent clause carries real information (pricing, refusal behavior, receipt caveats). It is dense and mixes payment/legal caveats into one block rather than structuring them, which slightly hurts scannability but no sentence is filler.

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

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

With 14 params, an output schema, and full annotations, the description fills the remaining gaps: cost, quota, refusal semantics, payment modes, and the receipt/legal-advice boundaries. An agent has everything needed to decide and call 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 high (86%), so the baseline is 3, but the description adds cross-parameter logic the schema does not: the due_date-vs-(invoice_date+terms_days) choice, the receipt flag's effect on paid success, and the api_key/x402 branching. That relational guidance justifies a bump above baseline.

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

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

States a specific verb and resource ('Check an invoice in one call') and enumerates the three sub-checks: VAT correctness, overdue/interest, tax-ID format. This clearly distinguishes it as a composite invoice check rather than any single sibling. It stops short of naming the siblings it bundles (compute_vat, validate_tax_id, compute_statutory_interest), so an agent must infer the differentiation.

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 one concrete calling rule ('Send due_date, or invoice_date with terms_days') and explains the free-refusal and payment paths. It never says when to prefer this bundled check over the individual compute_vat / validate_tax_id / compute_statutory_interest tools, so usage relative to alternatives is only implied.

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, open-world, non-destructive behavior. The description adds substantial behavioral context beyond that: paid price, free full refusals, coverage_gap no-charge policy, 3 free calls per IP per day shared with answer tools, api_key/x402 flow, and receipt semantics. No contradiction with annotations.

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

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

The description is dense and covers several concerns in one block, but it front-loads the paid nature and the core question before addressing inputs, refusal policy, and receipts. Most sentences carry necessary payment or coverage information, though the receipt/certified-extract disclaimers make it longer than ideal.

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 paid, refusal-prone tool with an output schema, the description covers what an agent needs: core purpose, required inputs, payment/refusal behavior, free-call sharing, api_key handling, and receipt verification. Return values are left to the output schema, which is appropriate.

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 by clarifying the due_date OR invoice_date+terms_days input alternative and by explaining that api_key bypasses x402 and that receipt adds an Ed25519 answer receipt on paid success. These additions go beyond what the schema alone 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 specific analytical question: whether an invoice is overdue, by how many days, and how much statutory late-payment interest is owed. It also names the calculation basis (Actual/365 simple, rate and workings cited) and scopes the statutory interest countries. This is enough to distinguish it from generic interest or date 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?

The description gives practical input guidance ('Send due_date, or invoice_date with terms_days') and scopes countries, but it does not explicitly say when to use this tool instead of siblings such as compute_statutory_interest or the certified extract endpoint. Usage is implied rather than contrasted.

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), yet the description adds substantial behavior: the 'FREE, unmetered' cost signal, the refusal semantics (year_not_held with years_held, holiday_date_pending), the guarantee that results are never inferred from weekends alone, and the explicit exclusion of sub-national holidays. This is well beyond what structured fields 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 cost signal and the core question, followed by returns and then edge-case behavior; every clause carries operational information. The dense weekend-rule parenthetical is long but earns its place by pre-empting surprising classifications.

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

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

For a two-parameter classification tool with an output schema and full annotations, the description covers purpose, return shape, error/refusal paths, cost, and scope exclusions. Nothing an agent needs to call it correctly or interpret a refusal 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 both parameters (date YYYY-MM-DD, ISO alpha-2 country) are fully documented in the schema itself. The description reinforces the scope of 'country' (national calendar, accepted across brands) 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?

'Is this date a business day in this country?' is a precise verb+resource, and the stated single-date classification scope implicitly separates it from the range-based siblings (business_days_between, count_working_days, add_business_days). The return summary (reason code, holiday names, adjacent business days) makes the operation unambiguous.

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

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

The description sets clear usage boundaries — it explicitly says regional/supranational holidays are not applied, that unheld years are refused, and which weekend regimes apply, which tells an agent when the answer is authoritative. It does not, however, name an alternative sibling (e.g. get_public_holidays_worldwide or count_working_days) or state when to prefer them, so it stops short of full when/when-not 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/non-destructive, so the bar is lower, yet the description adds real value by labeling the call 'FREE' and clarifying cost semantics. The receipt/Ed25519/certified-extract paragraphs are largely about other tools and don't describe this tool's own behavior.

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

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

Front-loaded purpose is good, but the tail is padding: 'get_changes is free. get_calendar is free. register_alert registration is free.' plus certified-extract and receipt explanations do not help an agent invoke list_series and crowd out the core message.

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 plus schema fully cover how to call it. The only shortfall is that relevant routing (vs get_series) is omitted while irrelevant receipt details are included.

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 both 'detail' and 'country' are fully documented in the schema. The description adds no syntax or format detail beyond it, making the baseline 3 correct.

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 ('Catalog of all mearef reference-data series') and enumerates the returned fields (countries, series ids, descriptions, freshness, URLs), which distinguishes it from get_series/get_series_history. 'Call this first to discover what data exists' further anchors its role.

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

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

Explicit 'Call this first' gives a clear sequencing rule, and it names verify_answer_receipt as the follow-on for receipts. However, it never states when to prefer get_series over this tool, and much of the routing text concerns paid answer/receipt mechanics rather than this catalog tool.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: exact price ($0.35), the no_charge refusal contract for partial coverage, the shared free-call quota, what the optional receipt does and does not represent, and the legal-advice disclaimer. An agent knows cost, failure mode, and side effects before calling.

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?

Pricing and purpose are front-loaded in the first sentence, and every later sentence carries load-bearing information (coverage, refusals, quota, receipt). The dense parenthetical style is heavier than ideal but wastes little.

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 described, and the annotations plus description together cover pricing, refusal behavior, rate limits, receipt provenance, and verification path. Nothing an agent needs in order to decide and invoke 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 high (86%), so the baseline is 3, and the description adds real meaning on top: the default 90-day window behavior, receipt semantics (Ed25519 answer receipt only on paid success, no charge), and api_key's bypass of x402 with metering. It stops short of explaining year_end or the tax enum beyond enumerating the three taxes.

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: upcoming VAT, PAYE and corporate-tax due dates in a date window, with holiday/weekend rolling and cited rules. The scope is clear and the verified-country list (AE, BH, OM, QA, SA) matches the country enum. It does not, however, differentiate itself from the near-twin sibling get_filing_deadlines, leaving ambiguity about which to choose.

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 operating context: default 90-day window, shared 3-free-calls-per-IP-per-day allowance, pass api_key or get an x402 payment requirement, and free refusal on coverage gaps. It also rules out confusion with the certified-extract SKU. It never says explicitly when to prefer this over get_filing_deadlines, so no true 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?

Beyond the annotations (openWorld, non-idempotent, non-destructive), the description discloses cost structure ($0 register, $0.05 delivery after trial, first 3 free, refunded on send failure), HMAC-SHA256 signing, hard limits (20 series + 20 sources), and refusal behavior (source_not_fingerprinted for unknown URLs). This is exactly the extra behavioral context an agent needs and cannot get from 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?

The purpose is front-loaded and the watch-type bullets are useful, but pricing is repeated ('REGISTERING IS FREE', '$0 · Delivery after trial: $0.05', 'First 3 deliveries are free'), and asides like 'not a FRED-macro subscription' and 'This is retention, not a new data product' are editorial noise. Several sentences do not earn their place.

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

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

An output schema exists, so return values need not be explained, and the description covers costs, limits, signing, and error behavior well. It omits lifecycle details an agent would want: idempotency of repeated registrations (annotations flag idempotent=false) and how to remove or update a subscription. Minor but real gaps for a subscription-creating 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?

With schema coverage at 100%, the baseline is 3, but the description adds genuine meaning: it explains that series watches fire on value/effective-date movement (and contrasts statutory watches vs a FRED-macro subscription), that sources watches fire on document BYTES change with old/new sha256, and that api_key funds deliveries without being metered by this call. That goes meaningfully beyond the schema 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?

The description states a specific verb+resource (bind a webhook / register an alert) and spells out two watch types (series → series.changed, sources → source.changed). It even differentiates from the sibling get_changes. The opening sentence ('so the next gazette does not silently stale a value you already paid for') is indirect and marketing-flavored, delaying the actual purpose, which keeps it 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 explicitly routes the agent: 'Prefer this over polling get_changes if you are a long-running agent,' naming the alternative and the condition that selects it. It also implies the monitoring use case via the two watch types, but gives no explicit when-not guidance (e.g. one-shot checks or short-lived agents), so it falls short of full when/when-not coverage.

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 adds substantial context beyond them: the $0.02 paid nature, the free-refusal policy, the statutory-vs-CSD calendar basis with stated divergence disclosure, and the optional Ed25519 receipt mechanics. This is exactly the kind of 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?

The core definition is front-loaded, which is good, but the body is an overstuffed block that folds pricing, receipt semantics, legal disclaimers, and verification instructions into one paragraph. The receipt explanation is largely duplicated in the schema description, and the wall-of-text form hurts scannability.

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 prose, and the description still covers pricing, refusal behavior, calendar provenance, the receipt option, and how to verify it. For a paid, citation-bearing computation tool this leaves no material gap for an agent.

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

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

Schema coverage is 100%, so the schema already documents every parameter; the description still adds meaning by explaining the market+instrument_class pairing, the 'eu.t2' pseudo-id for the euro cash leg, and the rule that government bonds never inherit an equity cycle. That is more than a restatement of the schema, though it does not add syntax detail for every field.

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

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

States a specific verb and resource: compute a settlement/value date n business days after a trade date on the intersection of named calendars, with a per-day audit trail. The scope is precise enough to separate it from generic siblings like add_business_days or is_business_day, since it layers cited settlement cycles on top of plain calendar arithmetic.

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

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

Gives explicit routing between the two input paths (business_days for a cycle you are trading under vs market + instrument_class for a cited cycle) and enumerates the refusal conditions (uncovered calendars, no cited cycle, cycle not in force, FX spot). It does not compare itself against sibling MCP tools, only a non-MCP companion endpoint, 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.