reference-data

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

With no annotations, the description fully discloses behavioral traits: it's a paid tool ($0.05), does not guess cross-period conversions, and returns honest statuses for edge cases (no floor, period mismatch). This is above average for a tool without 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 three sentences, front-loaded with core purpose, covering behavior and edge cases without superfluous text. Every sentence adds value.

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

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

Despite no output schema, the description enumerates return fields (verdict, margin, floor, legal instrument) and covers edge cases (missing floor, period mismatch). The tool's complexity is moderate and the description is sufficient for an agent to use effectively.

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 adds minor context (e.g., api_key bypasses x402) but does not significantly enhance understanding beyond the schema's own 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 clearly states the tool checks if a salary meets the country's statutory minimum wage, with a specific verb 'check' and resource 'minimum wage'. It distinguishes from sibling tools (e.g., compute_income_tax, compute_vat) which handle different compliance calculations.

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 context about period matching and honest handling of missing floors, but does not explicitly state when to use this tool over siblings or specify prerequisites/exclusions.

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

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

No annotations provided, but the description fully discloses it is a paid tool ($0.05), handles inflation-indexed tax units, and explains how payment works via api_key or x402.

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?

Description is front-loaded with cost and action, but contains some additional details that, while valuable, could be slightly tightened. Still well-structured and informative.

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 3 parameters and no output schema, the description explains return values (per-bracket workings, effective rate, marginal rate), scope limitations, and country handling, making it comprehensive for the tool's complexity.

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 for each parameter. The description adds clarifying context, such as country being ISO code and taxable_income being in local currency with specific period basis, going beyond 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 specifies the verb 'compute' and the resource 'income tax' on taxable income. It distinguishes from siblings like compute_vat by detailing the tax type and 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?

Explicitly states the tool computes statutory income tax only on taxable income, not net take-home pay, and that reliefs and social contributions are the caller's responsibility. It also guides on payment (x402) and api_key usage.

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?

Without annotations, the description carries the full burden. It discloses the cost ($0.02), the behavior of modes, and the fallback for missing api_key. It does not cover error cases or rate limits, but these are less critical for a simple computation.

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 concise (two sentences) and packs essential information. The cost note upfront is slightly abrupt but effective. Could be slightly more structured, 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 no output schema, the description reasonably explains the output (net, tax, gross) and includes composite rate details. It does not detail error handling, but for a VAT tool this is sufficient.

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

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

Schema coverage is 100%, but the description adds significant value: explaining mode options beyond the enum, giving a concrete example of composite rates, and clarifying the api_key parameter's role in payment. This exceeds the baseline of 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?

The description clearly states that the tool computes VAT breakdown (net, tax, gross) for an amount using the country's statutory rate, and mentions composite rates. It distinguishes itself from sibling tools like compute_income_tax by focusing on VAT. The 'PAID ($0.02)' note adds clarity about 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?

It explains when to use 'add' vs 'extract' modes and what to do if no api_key is provided. It does not explicitly state when not to use this tool, but the context is clear enough for an agent to decide.

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?

Discloses paid cost, weekend handling (including Egypt's Fri-Sat), holiday return by name, next working day after range, and range limit. No annotations exist so description bears full burden and does so well.

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

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

Three sentences with no fluff. Purpose, details, payment all 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?

No output schema but description explains return values (holiday names, next working day). Covers inputs, behavior, constraints, and payment. Complete for this 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%, baseline 3. Description adds meaning by explaining purpose of api_key and mentioning optional subdivision. Adds value beyond 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?

Clearly states it counts working days in a date range considering weekends and public holidays, with a specific verb and resource. Distinguishes from sibling tools like get_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?

Mentions paid nature, max range, and api_key handling but does not explicitly state when to use vs alternatives or when not to use.

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?

With no annotations, the description carries the disclosure burden. It transparently states the $0.005 cost, the x402 payment path, and key return attributes (official source, effective date, last-confirmed date, staleness flag). It does not describe error cases or pagination, which are secondary for a single-value retrieval.

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, packed with essential information: cost, purpose, examples, return attributes, and auth. Zero filler, well 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 simple current-value lookup with no output schema, the description sufficiently explains what the response contains and how to access paid data. It could mention the historical alternative or list all series, but sibling tool names imply these. Overall adequate and complete for the tool's simplicity.

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

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

Schema coverage is 100%, so parameters are already well documented. The description adds example series IDs and mentions api_key as an alternative to x402, but does not add deep semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns the 'current value' of a reference series, with concrete examples (policy-rate, vat, minimum-wage). It distinguishes itself from siblings like get_series_history and list_series by emphasizing 'current' and the specific series format.

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 indicates this is for fetching current values, and mentions the payment/auth flow. However, it does not explicitly say when to use get_series_history or other alternatives, relying on the 'current' qualifier and sibling names to convey the distinction.

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 burden of behavioral disclosure. It openly states the payment requirement, the cost, and the x402 payment mechanism. It also notes that omitting api_key will result in the response explaining how to pay, which is useful. It does not describe the return format, but this is a minor gap.

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

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

The description is highly concise: two sentences with no fluff. The first sentence covers purpose and filters, the second covers payment and authentication. Cost is front-loaded, making it immediately actionable.

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?

Despite lacking an output schema, the description covers the essential context: what data is returned (historical values), how to filter (from/to), and the payment/auth requirement. It does not explicitly list required parameters, but the schema handles that. Minor gap is the lack of return shape details, but the tool appears straightforward.

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 some value by explaining that api_key is optional and its purpose in the payment flow, but it does not provide additional semantics for country, series, from, or to beyond what the schema already states.

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

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

The description clearly states the tool provides historical values of a reference series with effective date ranges. It implicitly distinguishes from siblings like get_series or get_snapshot by emphasizing 'history' and 'effective date ranges', though it lacks an explicit verb like 'retrieve'.

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 usage is implied: use when you need historical series data. It provides context about optional from/to filters and api_key handling, but does not explicitly mention alternatives or specify when not to use this tool relative to sibling tools.

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?

Discloses paid cost ($0.02) and payment mechanism (api_key or x402), but does not mention rate limits, response size, or failure modes. No annotations provided, so the description carries the burden but is incomplete.

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 purpose, zero waste. Every word adds value.

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

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

No output schema, so description should hint at return structure. It misses potential large response size or pagination. Covers cost and auth, but not output format.

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

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

Adds meaning beyond schema: explains that api_key is optional and if missing, response explains payment via x402. Schema coverage is 100% but description enriches the parameter's role.

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 it provides a 'snapshot of every series for every country', which is a specific verb-resource pair. It distinguishes from sibling tools like get_series or list_series that are more focused.

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

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

Implies usage for broad overview, but no explicit when-to-use vs alternatives. The paid nature and payment method are noted, but sibling tools like compute_tax or get_public_holidays suggest different use cases.

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 provided. Description discloses it's a catalog (read-only list) but lacks details on permissions, rate limits, or side effects. The 'FREE' note adds minor 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?

Two concise sentences; each adds value. First enumerates contents, second gives usage guidance. No fluff.

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 zero parameters and no output schema, the description fully explains what the tool returns and its purpose. Sibling tools provide complementary operations, making this 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?

No parameters, so description cannot add parameter info. Schema coverage is 100%, baseline 4 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?

Description clearly states it catalogs all euroref reference-data series with specific contents. Distinguished from sibling 'get_series' by being the discovery tool, explicit 'Call this first'.

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 to call this first to discover data, implying sequential use. No explicit when-not but context 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 provided, the description fully discloses behavioral traits: it is a paid tool ($0.05), uses calendar intersection with per-day trail, cites sources, and refuses free guesses. It also explains calendar types and special rules, adding transparency beyond what would be expected.

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 detailed and front-loaded with cost and purpose. While it contains many specifics, each sentence adds value for a complex tool. It could be slightly more concise but is well-structured for an AI agent.

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

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

Given the complexity (6 parameters, no output schema, no annotations), the description is thorough. It explains refusal logic, calendar intersection, and trail output. However, without an output schema, the return format could be more explicitly described, but the mention of 'per-day trail' provides adequate context.

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%, meaning all parameters have descriptions. The description adds meaning by explaining how parameters like business_days vs market+instrument_class work together, and clarifies that government bonds never inherit equity cycles, which goes 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 computes settlement/value dates based on business days and calendar intersection, with specific mention of a per-day trail. It distinguishes itself from sibling tools like count_working_days and get_public_holidays by focusing on settlement date calculation.

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 guidance on when to use the tool (for settlement date computation) and when not (refuses guesses, no cited cycle, etc.). It implies alternatives through refusal conditions but does not name sibling tools directly. The usage context is clear enough.

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