reference-data

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

With no annotations, the description carries the full burden, and it does so thoroughly: it discloses the $0.05 paid cost, honest refusal statuses, that cross-period conversion is never guessed, and the exact receipt behavior. Even the distinction from the certified extract endpoint is made explicit.

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

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

The description is dense but front-loaded: cost and purpose appear first, followed by return values, edge-case behavior, payment path, and receipt caveats. Every sentence adds distinct value, and the structure makes it easy to scan.

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

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

For a paid tool with no output schema and no annotations, this is unusually complete: it covers required inputs, payment/auth, return fields, edge cases, receipt conditions, and how to verify the receipt. An agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains that the period must match the statutory floor's period, that cross-period conversion is never guessed, and that receipts only appear on paid successes. This aids parameter selection beyond the field descriptions.

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

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

The description states a specific purpose: return a compliance verdict on whether a salary is at, above, or below the statutory minimum wage, with the margin, floor, and legal instrument. This clearly distinguishes it from computing taxes, employment costs, or public holidays.

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 clear context for when to use the tool: checking salary compliance against a country's minimum wage. It also explains the api_key/x402 payment path. It does not explicitly name sibling alternatives, but the purpose is specific enough that no exclusions are needed.

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 no annotations, the description carries the full burden and does so thoroughly. It discloses the $0.10 paid nature, the refund/unknown handling ('explicit refused list... unknown, not zero'), the receipt behavior, the distinction from certified extracts, the 'not legal advice' caveat, and verification via verify_answer_receipt.

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 front-loaded with the most important facts: cost, scope, output, and exclusions. It is long, but each sentence carries necessary operational or legal context for a paid tool; minor redundancy exists around receipt behavior.

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

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

For a complex tool with 12 parameters, no output schema, and no annotations, the description covers cost, payment flow, output contents, exclusions, receipt limitations, and verification. It could be more complete with examples or explicit country-specific behavior, but it is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds some context around api_key ('otherwise the response explains how to pay via x402') and receipt semantics, but most parameter meaning is already well-covered in the input 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: it 'prices every statutory contribution on both the employee and employer sides for a gross salary, returning line-by-line amounts.' It also explicitly distinguishes itself from income tax computation, so an agent can differentiate it from compute_income_tax and 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?

The description explicitly says what the tool does not do ('Does NOT compute income tax') and names compute_payroll as the alternative for gross-to-net take-home. It also gives payment guidance for api_key vs x402, but it does not contrast against compute_income_tax directly, and compute_payroll is not present in the sibling list.

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

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

No annotations exist, so the description fully carries behavioral disclosure. It reveals the $0.05 fee, x402 payment fallback, receipt behavior (optional, at no extra cost, not legal advice), and the scope_note in the response. It also discloses that reliefs/allowances are not applied. This is thorough for a computation 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?

The description is dense but every sentence carries information: purpose, caveats, payment, receipt, verification. It is longer than average but appropriately so given the tool's complexity. Information is front-loaded (purpose and caveats before payment details). Not a model of brevity, but not wasteful.

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

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

Covers the main computation, scope exclusions, payment, receipt, and verification route. With no output schema, it mentions per-bracket workings, effective and marginal rates, and the scope_note, which gives a good sense of the response. It does not explicitly describe error cases or exact response structure, but for a paid computation tool this is adequate.

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?

Even though schema coverage is 100%, the description adds crucial meaning beyond the schema: taxable_income is clarified as local currency and period basis (annual vs monthly for specific countries), and the receipt boolean's behavior is explained in detail (what triggers it, what it is not). This materially improves parameter understanding.

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?

Clearly states it computes statutory income tax on a taxable-income figure using marginal brackets, with per-bracket workings, effective and marginal rates. Differentiates from net take-home pay and mentions inflation-indexed units, distinguishing it from sibling tax tools 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 warns it is tax on taxable income, not net pay, and that reliefs/allowances and social-security are caller's concern. Also contrasts with the certified extract SKU, giving clear when-not-to-use guidance and a specific alternative. No ambiguity about scope.

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 no annotations provided, the description carries the full burden and delivers: paid cost ($0.05), free refusal conditions, mechanism-only series refusal, jurisdiction limitations, legal disclaimer, and receipt semantics. This is unusually thorough for behavioral disclosure.

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

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

Packed with necessary operational detail—pricing, formulas, edge cases, auth, receipts—and logically ordered. It is long but every sentence earns its place; minor tightening of the receipt paragraph could improve 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?

Covers pricing, authentication, refusals, receipts, and legal caveats comprehensively. With no output schema, it doesn't explicitly describe the success response shape, though the formula makes the primary output predictable. It also assumes familiarity with 'series' from sibling tools, which is acceptable given the tool ecosystem.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond it: the actual/365 day-count convention, inclusive/exclusive date semantics, the relation between days and from/to, api_key usage bypassing x402, and receipt behavior including the Ed25519 answer receipt. This goes well beyond the parameter descriptions in the schema.

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

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

States a specific verb and resource: 'compute statutory interest' on a principal at a statutory-interest series rate, with the exact formula (principal × (rate/100) × (days/365)). The subject matter clearly distinguishes it from sibling compute_* tools like compute_vat and compute_income_tax, and the receipt disambiguation prevents confusion with certified extracts.

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 usage instructions: choose days or from/to, notes that conflicting both is refused free, and explains the api_key vs x402 payment paths. It doesn't explicitly state when to prefer this over sibling compute tools, but the domain is self-evident and the constraints are clearly laid out.

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 no annotations, the description carries the full burden and does well: it discloses the $0.02 fee, payment flow via x402, receipt behavior, and what the receipt is not (certified extract, legal advice). It lacks explicit error-condition or rate-limit details, but the critical behavioral traits are 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?

The description is dense but every sentence adds value: cost, purpose, mode, api_key, receipt, verification, and legal disclaimers. It is slightly long due to the receipt caveats, but the structure is logical and front-loaded with the most critical info (PAID, VAT breakdown).

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 tool with no output schema, the description covers the essential invocation details: cost, payment, auth, mode behavior, receipt handling, and verification path. The return values (net, tax, gross) are stated, and edge-case caveats like composite rates are included. Nothing needed to call and understand the tool is missing.

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

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

The schema already describes all parameters (100% coverage), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining mode=add/extract behavior, the composite rate example, and clarifying the receipt flag's implications. This pushes 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?

The description clearly states the tool computes a VAT breakdown (net, tax, gross) using the country's statutory rate, with specific mention of composite rates. It distinguishes itself from siblings like compute_income_tax and compute_employment_cost through the explicit VAT focus and mode handling.

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 clear context on how to use the tool, including mode semantics (add vs extract), payment requirements, and optional receipt. It does not explicitly state when not to use it versus alternative tax tools, but the scope is unambiguous enough that an agent would not confuse it with 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?

No annotations are provided, so the description carries the full burden. It discloses the cost ($0.02), payment methods (api_key or x402), range limit (366 days), receipt behavior (included on paid success, not on unpaid 402), legal disclaimer, verification method, and handling of unknown subdivision (free refusal with list). This is comprehensive and leaves no critical behavioral surprises.

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

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

The description is long but packed with necessary details. It front-loads the core purpose and cost, then proceeds to range, payment, receipt, verification, and subdivision. Every sentence earns its place, though it could be tightened by moving the legal disclaimer to a secondary note. It remains well-structured and scannable.

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 there is no output schema, the description explicitly states what is returned (holidays hit by name and the next working day after the range). It covers payment flow, edge cases (unknown subdivision, unpaid refusal), and verification. The tool has multiple parameters and a paid model, and the description addresses all relevant aspects 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%, but the description adds substantial meaning beyond the schema. It explains that api_key is optional and how payment works without it, clarifies receipt behavior and its relationship to verification, and details subdivision usage including the fallback to get_public_holidays for region lists and the free refusal for unknown codes. These enrich the schema definitions meaningfully.

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: 'Working days in a date range for a country,' and details what it does (weekends, statutory holidays, Egypt's Fri–Sat handling). It also distinguishes itself from related SKUs by clarifying it is not a series certified extract and referencing verify_answer_receipt and get_public_holidays for complementary functionality. This makes the tool's purpose unmistakable.

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

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

The description provides clear context for when to use the tool (counting working days) and references related tools for specific needs (get_public_holidays for region listings, verify_answer_receipt for verification). However, it does not explicitly state exclusions or conditions for choosing this tool over alternatives, such as 'use get_public_holidays when you only need the list of holidays.' The payment and receipt guidance is useful but not about tool selection.

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

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

With no annotations, the description carries full responsibility and excels: it discloses derivation logic for reverify_by and next_effective_known, conditionality on effective_to, handling of 'status unknown', negative behaviors (never parses notes, does not invent dates), and error semantics (402 gate bug). This goes far beyond a typical description.

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 information-dense and every clause is useful, but it is written as a single run-on paragraph, making it harder to scan. It front-loads the main action and cost signal, but would benefit from bullet points or clearer sentence breaks.

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

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

With no output schema, the description explains key derived fields and error codes, but does not give a high-level statement of the return structure (e.g., a list of calendar entries). It is adequate for an informed agent, but a bit more would make it fully complete.

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

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

Schema coverage is 100% and both parameter descriptions already include detailed semantics (options, free error codes). The tool description only restates that country and series are optional and adds no new meaning beyond the schema, 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 identifies a specific endpoint ('GET /v1/calendar') and scope (this brand's continent), and differentiates from get_changes by stating 'Past changes stay on get_changes.' It is not a tautology and clearly indicates the tool retrieves a calendar, though it does not explicitly name all sibling 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 provides explicit cost/free guidance ('FREE, unmetered'), optional parameters, and a direct when-not reference to get_changes for past changes. It also warns about 402 being a gate bug. However, it does not fully enumerate use cases against all siblings, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the sorting order (newest first), the default window (last 30 days), the fields returned (last_confirmed, stale), the freshness summary contents, and that it is free/unmetered. Nothing contradicts the annotations because there are none.

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 contains valuable routing and alternative instructions. It is slightly wordy with promotional flourishes like 'Freshness is checkable or it is marketing' and redundant pricing details, but overall it is organized and each major sentence serves a purpose.

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

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

For a read-only feed tool with one optional parameter and no output schema, the description is complete: it explains the default behavior, return contents, freshness summary, usage timing, and alternative tools. An agent has enough to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents 'since' with format and default. The description only restates 'Args: since? (YYYY-MM-DD)' and adds usage context rather than new parameter-specific semantics, so 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 clearly states the tool's function: it returns changed series since a given date plus a dataset-wide freshness summary. It explicitly distinguishes itself from siblings by saying 'Do not re-pay get_series to discover a diff' and by naming alternatives like register_alert 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?

The description gives explicit when-to-use guidance: 'After any paid series or answer call, call this before you assume the cached value is still the law.' It also provides exclusions and alternatives: do not use get_series for diffs, use register_alert for push, and use the certified endpoint for a filing freeze.

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 no annotations, the description carries full burden. It discloses that the tool is free, official, includes movable holidays, cites government sources, and handles sub-national calendars with merging and tagging. This provides adequate transparency about the tool's 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?

The description is well-structured with the core purpose front-loaded. It is concise but includes necessary detail about subdivisions. The word 'FREE.' could be considered extraneous, but overall it is efficient.

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

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

Given the tool's simplicity and full schema coverage, the description is complete. It explains the main function and the subdivision option. Without an output schema, it could benefit from mentioning return format, but the description of merged/tagged calendar suffices.

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

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

The input schema covers 100% of parameters with descriptions. The description adds value by explaining the 'subdivisions' field and that passing 'subdivision' returns a merged, tagged calendar, which enhances meaning beyond the schema.

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

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

The description clearly states the tool retrieves official public holiday calendars for supported countries, including movable holidays and government source citation. It distinguishes itself from sibling tools (e.g., count_working_days, settlement_date) by focusing solely on holiday data.

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 when to use the tool (retrieve public holidays) and provides context for sub-national calendars via the subdivision parameter. However, it does not explicitly state when not to use it or compare it to alternatives, though siblings are distinct.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool is PAID ($0.005), that responses include source citation, effective date, last-confirmed date, and staleness flag, and that a later gazette could silently retire the value. It also explains the api_key/x402 payment behavior. This is rich behavioral context beyond the schema.

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

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

The description is compact and front-loaded with the most critical fact (PAID). Every sentence adds information: cost, examples, response contents, payment path, and follow-up actions. It is slightly dense with parentheticals, but each earns its place.

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

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

For a paid, read-only lookup tool with no output schema, the description covers cost, response fields, payment, and follow-up actions. It doesn't describe error cases or rate limits, but the essential operational context is present. The sibling list includes get_series_history, so the agent can infer the difference between current and historical values.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds examples for series and mentions api_key's role (bypasses x402; metered for invoicing), which adds some value. However, it doesn't add much beyond the schema for country or series format, so 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 ('get'), a resource ('reference series'), and concrete examples (policy-rate, vat, minimum-wage). It also distinguishes itself from siblings by naming get_changes and register_alert as follow-ups, and the sibling list includes get_series_history and list_series, so the scope is clear.

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 explicitly says when to use this tool: to get the current value of a reference series, and it tells the agent what to do after a 200 (bind get_changes or register_alert). It also explains the payment path (api_key vs x402), which is essential usage context. It doesn't explicitly name alternatives for 'current value vs history', but the follow-up guidance is strong.

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 no annotations, the description carries the behavioral disclosure burden and does so well: it states the tool is paid, api_key is optional with an x402 fallback, and a 200 response should lead to binding a monitoring tool to avoid silent retirement. It omits output format, error handling, and pagination, but the provided cost, payment flow, and data-retirement caveat add real context.

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

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

The three sentences are dense and non-redundant: purpose/filtering, payment fallback, and post-success monitoring. The pricing parentheticals add bulk but are decision-relevant, and the paid indicator is front-loaded.

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

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

For a 5-parameter read tool with no output schema, the description covers purpose, optional filters, payment, api_key behavior, and recommended follow-up actions. It does not describe the exact response shape or pagination, but an agent has enough information to invoke it correctly and decide next steps after a 200.

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

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

The schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds conditional api_key behavior ('Pass api_key if you have one; otherwise the response explains how to pay via x402') and groups from/to as optional date filters, which is genuinely useful beyond the schema.

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

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

The description identifies the tool's output as 'Historical values of a reference series with effective date ranges' and mentions optional from/to filtering, making the resource and scope clear. It lacks an explicit verb such as 'retrieves' or 'lists' and does not contrast with current-value siblings like get_series or get_snapshot, so it stops short of the top score.

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

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

It gives clear follow-up guidance: after a 200, bind get_changes or register_alert so a later gazette cannot silently retire the value. However, it does not explicitly state when to choose this tool over get_series or get_snapshot for current values, nor does it exclude alternatives for non-historical needs.

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 no annotations provided, the description carries the full burden. It discloses the cost (PAID $0.02), payment options (api_key or x402 explanation), and the behavioral consequence of not binding follow-ups ('a later gazette does not silently retire the value'). This is substantial transparency beyond what a generic schema would convey, though it doesn't detail return format or safety guarantees.

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 cost and purpose, and every sentence adds value: cost, what it does, payment method, and follow-up binding. It is compact but dense, and the 'this series' reference creates slight ambiguity, but overall it is well-structured and not overly verbose.

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 tool with one optional parameter and no output schema, the description covers purpose, cost, payment, and post-call actions. The only gap is ambiguity around 'this series' – the snapshot returns multiple series, yet the follow-up binding refers to a singular series, which could confuse an agent. Otherwise it is quite complete.

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

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

The schema describes api_key simply as 'API key' (100% coverage), but the description adds meaningful semantics: it clarifies that api_key is optional and explains the fallback behavior when omitted ('otherwise the response explains how to pay via x402'). This goes beyond the schema, so a 4.

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

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

The description clearly states the tool returns 'Snapshot of every series for every country in one call' – a specific verb, resource, and scope. It doesn't explicitly contrast with siblings like get_series or list_series, but the phrase 'every series for every country' makes the bulk nature evident, so a 4 is appropriate.

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 provides follow-up guidance ('After a 200, bind get_changes ... or register_alert') and cost context, but does not explicitly say when to use this over alternatives like get_series or list_series. The guidance is implicit rather than explicit exclusions, so a 3.

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 no annotations, the description must disclose behavior. It states the tool is FREE and describes the output contents (countries, series IDs, etc.), which is helpful. However, it does not mention any side effects, pagination, or limits. The description also spends significant space on unrelated paid-tool receipt behavior, which does not clarify this tool's own behavioral profile.

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 excessively long and front-loads the core purpose but then diverges into unrelated details about paid answer tools, receipts, certified extracts, and other free tools. This is not concise and mixes multiple concerns, making it harder for an agent to quickly extract the essential information about this specific tool.

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

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

For a zero-parameter discovery tool with no output schema, the description adequately specifies what the agent can expect: a catalog with countries, series IDs, descriptions, freshness metadata, and URLs. It also notes the tool is free. The extraneous information does not leave gaps for calling this tool, though it could have omitted the unrelated receipt details to improve focus.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters. It adds no parameter semantics, but none are needed.

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

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

The description clearly states the tool is a free catalog of all euroref reference-data series, listing supported countries, series IDs, descriptions, freshness metadata, and URLs. It also instructs to call this first for discovery, effectively distinguishing it from siblings like get_series which fetch specific data.

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 explicitly says 'Call this first to discover what data exists,' providing clear usage guidance. It also hints at alternatives by mentioning certified extracts are not MCP tools and verify_answer_receipt for receipts, though it does not systematically contrast with each sibling. This is sufficient for a discovery 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?

With no annotations, the description carries the full burden and does so well: it discloses pricing (free trial, $0.10 later, refunded on send failure), HMAC-SHA256 signing, the difference between series.changed and source.changed, that unknown source URLs are refused, and that api_key is not metered. This level of disclosure is thorough for a webhook registration 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?

The description is long but densely packed with essential information. It uses bullets for the two watch types and front-loads the core purpose. Every sentence contributes to usage clarity; the structure helps parsing despite the length.

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

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

Given the tool's complexity (pricing, security, two modes, constraints), the description covers the essentials: required and optional params, limits, event types, and its relationship to polling. No output schema is present, but the description does not need to explain return values since it's a registration call. Missing details like webhook payload structure are minor given the scope.

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% with descriptions already present. The description adds significant semantic value beyond the schema: it explains the meaning of series vs sources, gives examples, clarifies that source URLs must be exact and fingerprinted, and states max limits. This is more than the baseline 3 for full coverage.

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

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

The description states a specific purpose: binding a webhook to receive notifications when served values or source document bytes change, preventing silent staleness. It also differentiates itself from sibling tools like get_changes by explicitly being a push alternative (retention, not polling).

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?

Clear usage guidance is provided: it says 'Prefer this over polling get_changes if you are a long-running agent,' and explains the two watch types (series vs sources) with distinct semantic triggers. It also notes constraints (max 20 each, required url). It doesn't explicitly list when NOT to use it, but the alternative guidance is sufficient.

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

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

With no annotations present, the description carries the full burden, and it delivers: it discloses the $0.05 fee, free-refusal policy, receipt behavior, verification path, and the legal disclaimer that receipts are not legal advice. It also explains what each response contains ('a per-day trail showing every skipped day and why' and 'the basis and any known divergence').

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

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

The description is long and dense, but nearly every sentence earns its place given the tool's complexity. Core purpose and cost are front-loaded, with refusal conditions, calendar semantics, and receipt details following logically. A small amount of redundancy with the schema's receipt parameter keeps it from a perfect score.

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

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

For a paid, refusal-prone tool with no output schema, the description is remarkably complete: it covers pricing, input modes, calendar semantics, citation behavior, refusal grounds, receipt handling, and verification. An agent has enough context to decide whether to call it, how to call it, and what to expect back.

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 100%, the description adds meaning the schema cannot convey: business_days and market+instrument_class are alternative modes, calendars are national statutory calendars with researched weekend rules, 'eu.t2' is the euro cash leg, and trade_date day 0 is 'never counted, never rolled.' This goes far beyond the baseline and materially improves correct invocation.

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

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

The description opens with a specific outcome — 'Settlement/value date: the date n business days after a trade date' — and immediately distinguishes this from calendar-only tools by emphasizing the INTERSECTION of calendars and the per-day trail. It also clarifies what the tool is not ('NOT CSD or exchange calendars'), which separates it from siblings like get_public_holidays and count_working_days.

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 tells the caller how to configure the two input modes: 'Supply business_days for a cycle you are trading under, or market + instrument_class to have a settlement cycle applied.' It also states concrete refusal conditions ('We refuse FREE rather than guess'), directs users to a free companion endpoint, and points to verify_answer_receipt for receipt verification.

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 no annotations available, the description carries the full behavioral burden, and it delivers. It discloses cost ('FREE'), network behavior ('may GET signature.public_key'), a security constraint ('Never send a private key'), a semantic guarantee ('A valid signature shows this service issued that exact receipt'), and a limitation (does not produce a certified extract). This is far beyond what a bare schema would 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?

The description is front-loaded with 'FREE' and the core verb, then branches into usage details. It is longer than the high-calibration example but every sentence earns its place. The only mild bloat is the parenthetical '($0.25, not an MCP tool)' and the aside about legal advice, which could be trimmed without losing essential 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?

For a tool with no output schema and no annotations, the description is remarkably complete. It covers purpose, parameter relationships, offline/online modes, security, cost, and non-goals. The only minor omission is the exact return type (e.g., boolean or object), but the phrase 'A valid signature shows...' effectively defines the success result. The description leaves no critical gap for an agent to call the tool correctly.

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

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

Even though the schema already documents all four parameters at 100% coverage, the description adds conditional logic that the schema lacks: when signature_value is needed (receipt lacks a nested signature), when public_key_pem is required (offline verification), how public_key_url is used (only when public_key_pem is omitted), and the override rule for signature_value. It also clarifies the canonical-JSON rule and prohibits private-key PEMs—meaningful semantics beyond the raw JSON 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 opens with an imperative verb and a specific resource: 'Verify an answer receipt (kind answer_receipt) with the Ed25519 public key only.' It immediately distinguishes this from the other tools, which deal with wages, taxes, holidays, and series snapshots, and it scopes the operation to verification rather than issuance or extraction.

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

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

The description gives explicit when-to-use guidance: it explains the offline path, the optional online fetch, and the exact conditions for passing signature_value. It also names what this tool is not for (turning a receipt into a certified extract at $0.25) and warns against private keys. No alternative MCP tool is needed—this is a dedicated verifier—and the exclusion prevents misuse.

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