Everyday agent tools

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the description correctly spends its words on traits annotations cannot express: the ECB rate source, the 90-day lookback limit, and a pay-per-call cost model with a free daily allowance. The allowance itself is unquantified and the failure behavior past the limit isn't described, keeping it short of a 5.

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

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

Two dense sentences, zero filler, with the core capability and its date/rate scope front-loaded ahead of the pricing caveat.

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

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

With an output schema present the description need not explain return values, and annotations cover the safety profile. It supplies rate source, date window, and pricing; only the mechanics of exhausting the daily allowance (payment flow, error behavior) are left unstated.

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

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

Schema coverage is 100%, so the schema already documents from/to/date/amount including defaults (latest, 1). The description only adds that the currency universe is ~30 ECB-quoted currencies and that the rate is the ECB reference rate — useful framing but no syntax or format detail beyond the schema.

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

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

States a specific verb (convert) and resource (currencies) plus scope: ~30 currencies, ECB reference rate, today or any date in the last 90 days. No sibling tool performs currency conversion, so an agent can route to it unambiguously from the description alone.

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

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

Gives clear operating context: valid dates are today through the last 90 days, and cost is free within a daily allowance then $0.001 USDC per call. It doesn't name an alternative for out-of-window dates, but no sibling offers that capability, so the gap is minor.

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, open-world, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it discloses the cost/paywall model (free within daily allowance, then $0.002 USDC via x402) and critically clarifies that the result is 'straight-line', not driving distance.

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, no filler. The core purpose and units are front-loaded, with the pricing note following. Every clause 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?

With rich annotations, a present output schema, and 100% schema coverage, the description need only cover purpose and any behavioral caveats. It does so, including the straight-line caveat and cost model, though it omits anything about invalid/malformed postcode handling.

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

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

Schema coverage is 100%, so the baseline is 3; the schema labels both params merely 'Postcode'. The description adds real meaning by constraining them to UK postcodes and indicating both endpoints are postcodes rather than any location 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?

The description states a precise computation (straight-line distance and compass bearing) over a specific resource (two UK postcodes) and even names the output units (km and miles). No sibling tool computes distance, so differentiation is trivially satisfied, and an agent knows exactly what it will get.

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: it computes distance between two postcodes, so an agent can infer when to reach for it. There are no explicit when/when-not conditions, no mention of invalid input handling, and no named alternatives to route against.

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 readOnly/idempotent/non-destructive, so the safety profile is free. The description adds genuinely useful context beyond that: the data source is official bank holidays per nation, and there is a metered cost model (free within the daily allowance, then $0.001 USDC per call via x402) that an agent must know before invoking.

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

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

Three tightly packed clauses lead with the operations, then the data source, then the pricing. No filler, and the most important capability description 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?

With an output schema present and rich annotations, the description need not explain return values. It covers scope, data authority and cost, but leaves ambiguous what happens when add and until are both supplied and which nation defaults when omitted.

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 date, add, until and nation are already documented in the schema. The description restates the add/subtract and count semantics but adds no format, default (e.g. which nation applies if omitted), or precedence rules beyond the schema. Baseline 3 when the schema does the heavy lifting.

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

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

States three concrete operations on a specific resource (UK business days) using precise verbs: test a date, add/subtract N days, count days between dates. It is clearly a UK-specific calculator, though it never names the closest sibling (time__business-days) to disambiguate which one an agent should pick.

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 three described operations implicitly map to the parameter combinations, so an agent can infer that leaving add/until unset yields the is-a-business-day check. However there is no explicit when-to-use guidance, no exclusions, and no routing against siblings like time__business-days or uk-bank-holidays__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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context the annotations cannot convey: a free daily allowance followed by $0.001 USDC per call via x402, which is critical for an agent deciding whether to invoke the tool repeatedly.

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 capability list is front-loaded as three semicolon-separated clauses, followed by the pricing sentence. It is dense but each clause carries distinct information; only the mode-switch ambiguity from cramming three behaviors into one tool costs it a point.

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 all three operating modes plus the payment model. The remaining gap is the lack of routing guidance against overlapping sibling tools.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema by showing that 'add' switches the tool into a forward-date computation mode rather than merely accepting an offset. That mode-switching semantics is not evident from the bare schema field 'Business days to add'.

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

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

The description names three concrete operations (holiday/business-day check, add N business days, next business day) with specific verbs and resources, so an agent knows exactly what the tool does. It does not, however, distinguish itself from close siblings like time__business-days or calculators__uk-business-days, which apparently overlap on business-day 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?

There is no when-to-use guidance and no mention of alternatives, even though several siblings (time__business-days, uk-business-days, holidays__year) clearly overlap. The only implicit signal is that passing 'add' shifts into business-day arithmetic, which the agent must infer.

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, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds genuinely useful context beyond that: the billing behavior ('free within daily allowance, then $0.0005 USDC per call via x402'), which tells the agent a paid-auth path may be involved. It does not describe the exact enumeration payload, but the output schema covers that.

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 short sentences with no filler, and the scope statement is front-loaded ahead of the pricing note. It is appropriately sized for a trivial lookup tool, though the first sentence reads more like an assertion than a directive.

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, read-only enumeration tool with a full output schema and complete safety/idempotency annotations, the description supplies the remaining relevant context: coverage scope and cost model. Nothing essential to calling it correctly is missing, though a hint about how the result connects to holidays__check/year would round it out.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The schema is trivially complete and no parameter semantics 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 states that the tool covers 'every country and regional provider supported', making it clear this enumerates the supported countries/regions for the holidays API. Combined with the title 'World Public Holidays: Supported countries' the purpose is unambiguous and distinguishable from siblings like holidays__check or holidays__year. It lacks an explicit verb ('list/retrieve'), which keeps it just 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?

No when-to-use guidance is given. The description does not say to call this first to discover valid country codes, nor does it name alternatives such as holidays__check or holidays__year. The only inferable usage signal is the pricing note, which is commercial rather than procedural.

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 readOnly, idempotent, openWorld, and non-destructive traits. The description usefully adds cost behavior — free within the daily allowance, then $0.001 USDC per call via x402 — which is genuine context beyond the annotations.

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

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

Two tight sentences with zero waste; the core purpose is front-loaded before the pricing detail.

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

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

An output schema exists, so return values need no explanation, and the description covers purpose, params, and cost. The only gap is the absence of guidance on choosing among the similar holiday siblings.

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

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

Schema description coverage is 100%, so the schema already documents both country and year. The description adds only a minor clarification that country can be a region provider (Germany/Bavaria) and nothing about year format, so baseline 3 applies.

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

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

States a specific verb+resource: 'Official public holidays for a country ... in a year', with a concrete example (Germany/Bavaria). It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like holidays__check or holidays__countries.

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

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

No when-to-use guidance, no exclusions, and no routing to the many alternatives (holidays__check, holidays__countries, uk-bank-holidays__*). The pricing note implies a general context but gives no selection criteria.

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 and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the weekend/holiday skipping rule and the pricing model (free within the daily allowance, then $0.001 USDC per call via x402), which an agent needs for cost-aware decisions.

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, no filler, with the core capability front-loaded and the pricing caveat correctly demoted to second position.

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 annotations cover the safety profile. The definition is nearly complete; only the interaction between 'to' and 'days' (mutually exclusive modes) is left to the schema.

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

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

Schema description coverage is 100% and each parameter is already labeled with its mode ('count mode', 'add mode; negative goes back'), so the schema carries the load. The description's mention of the two modes aligns with but does not meaningfully extend the schema's own parameter documentation.

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 pair ('Count business days between two dates, or add business days to a date') and names the exact exclusions (weekends, public holidays). The '(any country)' framing in the title implicitly distinguishes it from the uk-business-days sibling, though the description body never names that alternative.

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 maps the two operating modes to their parameters: 'count mode' uses a date range and 'add mode' adds days, which gives the agent implicit routing guidance. However, it never states when to prefer the UK-specific sibling or what prerequisites the country code implies.

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 and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: it reports ambiguous times (clocks back) and non-existent times (clocks forward) rather than silently returning a value, and discloses the pricing model (free within daily allowance, then $0.001 USDC via x402). It does not state what happens on an invalid zone string.

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 compact sentences with zero filler: the conversion and DST semantics come first, the cost model second. Every clause carries information an agent would otherwise have to guess.

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

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

An output schema exists, so return-value shape need not be explained, and the description covers the two hardest aspects of the operation (DST ambiguity/non-existence) plus the payment gate. It is close to complete; only error behavior for malformed zones is unaddressed, which is minor.

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

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

Schema description coverage is 100%, so all three parameters (time, from, to) are already documented in the schema, including the required local-time format and the IANA-zone constraint. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (convert) and resource (wall-clock time between two IANA zones), plus the distinctive DST-handling behavior. An agent can distinguish this from siblings like time__now (current instant) and time__zone-info (zone metadata) without opening any schema.

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

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

The 'wall-clock time ... no offset' framing implies you use this when you already hold a local time and need the equivalent in another zone, which is a reasonable implied context. However, it names no alternatives or exclusions (e.g., vs time__now or time__business-days), so the agent must infer when this tool is the right pick.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description earns credit by disclosing the cost model — free within a daily allowance, then $0.001 USDC per call via x402 — which is real behavioral context an agent needs before calling repeatedly. It stops short of noting the default zone or that results are live/non-cacheable.

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 tight sentences: the returned fields are front-loaded and the pricing caveat follows. No filler, no repetition of the title.

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, though the field list is harmless. The pricing disclosure is a useful addition. What is missing for a tool in a cluster of near-identical time siblings is any routing guidance, which slightly under-completes the definition.

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?

Only one parameter exists and schema coverage is 100%, with the IANA format and UTC default already documented in the schema. The description's 'for a zone' adds no syntax or default detail beyond that, so the baseline 3 is appropriate.

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

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

The description names a specific resource (current local time plus UTC, offset, abbreviation, DST flag, weekday, ISO week) scoped to a zone, so an agent can tell it retrieves the current moment. It does not explicitly distinguish itself from the very similar sibling time__zone-info, which is the main gap.

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

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

There is no statement of when to use this tool versus time__zone-info, time__convert, or time__business-days. The only conditional language concerns pricing ('free within the daily allowance'), not usage context or prerequisites, leaving selection to inference from the name alone.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: a per-call cost of $0.001 USDC settled via x402, plus the framing that this is the cheapest paid endpoint. That is real context beyond the annotations, though it says nothing about failure/auth behavior of the payment flow.

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 short clauses, no filler, no repetition. Cost and payment mechanism are stated in the same breath as the purpose. Nothing could be cut without losing information.

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

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

With zero params and an output schema present, the description need not explain return values, and it does note the payload shape anyway. It covers cost, payment rail, and intended use, which is what an agent needs to decide whether to call a paid endpoint. Minor gap: no note on what happens on payment failure.

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 takes zero parameters, so there is nothing for the description to disambiguate, and the schema is trivially complete at 100% coverage. The baseline for a 0-param tool is 4; the description adds no parameter-level information because none is 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 reads as a noun phrase about the return payload ('Server UTC time and a request id') rather than stating what the tool does with a verb, though 'cheapest paid endpoint... test an x402 payment' does hint at its role. It differentiates itself from free siblings like time__now only indirectly, by flagging the paid test nature. Purpose is inferable but not stated cleanly.

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 names the intended use: 'use it to test an x402 payment end to end.' That is a clear trigger condition tied to payment verification rather than a time lookup. It offers no exclusions or explicit redirection to free alternatives for ordinary time queries, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context in the pricing model (free within daily allowance, then $0.001 USDC via x402), which an agent cannot see in the structured fields. Paywalled-external-call behavior is disclosed.

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

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

Two sentences with no filler; the functional payload (what is returned and for what input) is front-loaded and the cost caveat trails it. Every clause 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?

An output schema exists, so return-value explanation is not required, and annotations carry the safety profile. The description still communicates scope and cost, leaving only the when-to-use routing gap that drops it below a 5.

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 (zone, at) are documented in the schema itself, so the baseline is 3. The description's phrases 'for an IANA zone' and 'at a moment' echo the schema but add no syntax, format, or default details beyond it.

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

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

The description specifies the exact outputs (offset, abbreviation, DST at a moment, next clock change) for an IANA zone, which clearly distinguishes it from a bare time lookup. It lacks a leading verb and never names a sibling such as time__convert or time__now to sharpen the distinction, so it stops short of a 5.

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

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

There is no guidance on when to choose this over time__convert, time__now, or time__signed. The pricing/allowance sentence is a cost caveat, not usage direction, so the agent is left to infer selection from the sibling list alone.

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

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

The annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false) already establish the safety and behavioral profile. The description adds pricing/rate-limit information (daily allowance, per-call cost via x402), which is useful context beyond annotations. However, it does not disclose what 'by division' means for the output structure, whether results are cached, or performance characteristics.

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 short sentences. The first states the tool's scope, the second provides pricing/access information. Both are front-loaded and no words are wasted.

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

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

For a zero-parameter retrieval tool with an output schema and rich annotations, the description covers what the tool returns and its cost model. It could briefly mention the relationship to division-specific siblings or whether it aggregates them, but with the output schema handling return structure, the description is largely complete.

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

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

The tool takes zero parameters, so there are no parameters to describe. The baseline for zero parameters is 4, and the description doesn't introduce any misleading parameter expectations.

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: 'Every published UK bank holiday by division.' This clearly indicates it returns the full list of UK bank holidays and implies it covers all divisions, distinguishing it from the division-specific siblings like uk-bank-holidays__england-and-wales. However, it doesn't explicitly state how it relates to 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?

Usage is implied by the name and description—use this when you want all UK bank holidays. There is no explicit when-to-use guidance or naming of alternatives like the division-specific tools or holidays__year. The pricing note ('Free within the daily allowance, then $0.001 USDC per call via x402') provides cost context but not selection criteria.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context not present in the annotations: the pricing model (free within a daily allowance, then $0.001 USDC per call via x402), which matters for call budgeting.

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 short sentences, front-loaded with the scope and followed by the cost caveat. Every clause earns its place; no filler.

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

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

With zero parameters and an output schema present, the description does not need to explain return values, and it covers scope plus pricing. The only omission is the temporal coverage of the returned holidays (e.g. current year vs all years), which is a minor gap given the output schema likely clarifies 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless definition.

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

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

The description names a specific resource (bank holidays) and scopes it to England and Wales, which cleanly distinguishes it from the sibling regional tools (all, scotland, northern-ireland). It lacks an explicit verb such as 'returns' or 'lists', but the resource+region is 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?

There is no guidance on when to pick this tool over uk-bank-holidays__all or the other regional variants, nor any mention of what time range is covered. The agent must infer the England/Wales scope from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: the cost model (free within the daily allowance, then $0.001 USDC per call via x402), which affects invocation strategy.

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 short sentences, zero filler, with the resource scope front-loaded ahead of the pricing note. Every sentence carries information the agent needs.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is sufficient to call the tool correctly; only the missing sibling-differentiation guidance (NI vs. UK-wide vs. other nations) keeps it from being 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies.

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

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

The description names a specific resource (bank holidays) and a specific scope (Northern Ireland), which implicitly distinguishes it from the England-and-Wales, Scotland, and 'all' siblings. It lacks an explicit verb like 'returns' or 'lists', but the data-fetch intent is unambiguous for a zero-parameter tool.

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

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

There is no when-to-use guidance at all, despite three near-identical siblings (uk-bank-holidays__all, england-and-wales, scotland) that an agent must choose between. Nothing states whether this returns only NI-specific holidays or NI-observed UK-wide ones, which is exactly the disambiguation needed here.

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 safety profile is covered. The description adds genuinely useful non-schema behavior: free within a daily allowance and then $0.001 USDC per call via x402, which is a real cost/rate constraint 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?

Two short sentences, region stated first and pricing second; no filler and every sentence carries information. Well front-loaded for an agent scanning for scope.

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 zero params, an existing output schema and full annotation coverage, the description supplies what is needed to call it: scope plus cost. It omits any mention of the date range covered, which is a minor gap rather than a blocking one.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level detail is required or missing.

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 resource and its regional scope ('Bank holidays in Scotland'), which cleanly distinguishes it from the England-and-Wales and Northern Ireland siblings. The verb is only implicit (list/return), so it is clear but not maximally 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?

No when-to-use guidance at all: it never says whether to pick this over uk-bank-holidays__all or holidays__check, nor how the regional scopes relate. The agent must infer selection from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuine extra context: a pricing/rate-limit model (free within daily allowance, then $0.001 USDC per call via x402), which the agent otherwise could not know.

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 short sentences with the core conversion front-loaded and the cost model second. Both sentences earn their place; no filler or redundancy.

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

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

With an output schema present and full parameter documentation, the description need not explain return values. It covers purpose, rate-selection modes, and cost, leaving only alternative-tool routing unaddressed.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including the 'from' direction and rate/country options. The description restates the direction choices but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific operation (net↔gross VAT calculation) and the two rate-selection modes (given rate vs country standard rate). An agent can distinguish it from vat__rates and vat__validate-format by function, though it does not name those siblings explicitly.

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

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

Implies usage (compute a VAT-inclusive/exclusive amount) and notes the two input modes, but gives no explicit when-to-use-vs-alternative guidance or routing to vat__rates for rate lookup. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-structured behavior: free within a daily allowance, then $0.001 USDC per call via x402, plus that results carry a checked-date. That is real cost/rate-limit context beyond the annotations.

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

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

Two sentences, front-loaded with what is returned and the scope, followed by the cost model. No filler or redundancy; every clause carries information.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description adds scope, freshness and pricing, leaving nothing an agent needs in order 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 single parameter's omit-for-all semantics are already spelled out in the schema ('ISO code (omit for all)'). The description's 'one country or all of EU27 + UK' restates that without adding format or syntax detail, so baseline 3 applies.

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

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

States a specific resource (standard, reduced and super-reduced VAT rates) with clear scope (one country or all of EU27 + UK) and even the freshness metadata (date checked). An agent can tell this is a rates-lookup rather than a calculator, though it never names vat__calculate or vat__validate-format explicitly.

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

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

Usage is implied: fetch rates for a country or all of EU27+UK. There is no explicit when-to-use vs when-not, nor any pointer to the sibling tools that handle calculation or format validation. The pricing sentence adds context but not routing guidance.

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

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description still adds behavior the annotations cannot express: the outcome is a format/checksum result rather than a registration confirmation, and the cost model is 'free within the daily allowance, then $0.001 USDC per call via x402.' That quota and pricing disclosure is genuinely useful for deciding whether and how often to call.

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 with no filler, and the capability plus scope statement is front-loaded ahead of the pricing note. Every clause carries information an agent needs.

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 one-parameter, read-only tool with an output schema, the description covers what is checked, what is explicitly not checked, the supported country scope, and the cost model. Little is missing, though it does not say what happens on an unsupported country prefix or what the failure result looks like.

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

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

There is a single required parameter and schema description coverage is 100%, so the schema already documents the 'VAT number with country prefix' requirement; the baseline here is 3. The description adds only the accepted country-prefix set (GB/XI and EU), which is a marginal supplement rather than new syntax or format 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?

The description names the specific resource and the exact verification it performs (country format plus check digit) and scopes it to UK (GB/XI) and EU VAT numbers, which separates it cleanly from vat__rates and vat__calculate. It stops short of a leading verb, but the scope statement is precise enough that an agent can identify the tool without reading 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 sentence 'Does not confirm registration' is an explicit when-not boundary that prevents the most likely misuse of a VAT-number tool. It does not, however, name the sibling tools or state when to prefer this over any of them, so the routing guidance is implied rather than explicit.

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