Product safety & recalls

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 behavioral context: results come 'newest first' and the call is free within a daily allowance before costing $0.003 USDC via x402, which an agent needs to know before repeated calls.

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 the scope and sources front-loaded, followed by cost/sort details. Each clause carries information, though the pricing clause is somewhat dense for a selection-focused opening sentence.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies scope, aggregation sources, ordering and cost, leaving only minor gaps such as result-volume/pagination behavior, which the limit parameter and output schema largely address.

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 are documented with an example query and a default/max for limit. The description only restates 'product, brand or ingredient', which duplicates the q parameter's own description, adding no syntax or scope nuance 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 ('Check') and resource, and enumerates the aggregated sources (UK product recalls, MHRA, FSA, US CPSC) plus sort order. It implicitly positions itself as the cross-source counterpart to the domain-specific siblings, but never names them, so sibling differentiation is inferential rather than explicit.

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

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

The phrase 'in one call' implies this is the tool to use when you want broad coverage rather than the per-domain tools like uk-food or us-products, but no when/when-not condition or named alternative is given. Usage is implied, not stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description usefully adds the sort order ('newest first') and the pricing/paywall model ('free within the daily allowance, then $0.002 USDC per call via x402'), which are genuine behavioral traits not in the structured fields.

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

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

Two tight sentences, front-loaded with what the tool returns and followed by cost. Every clause earns its place with no redundancy relative to the title or schema.

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

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

With an output schema present, return values need not be described, and annotations cover the safety profile. The description completes the picture with coverage, ordering, and pricing; only explicit sibling-routing guidance is missing, which is a minor gap for this well-structured 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?

Schema description coverage is 100%, so the schema already documents q, body, limit, and since (including the aaib|maib|raib values and YYYY-MM-DD format). The description adds no parameter-level detail beyond that, so the baseline of 3 is appropriate.

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

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

States a specific resource — AAIB/MAIB/RAIB investigation reports and bulletins — and expands the acronyms with (air), (marine), (rail), so an agent immediately knows this returns UK transport-accident investigations. It is clear what the tool returns but does not explicitly differentiate itself from product-oriented siblings like uk-products or uk-medical beyond the agency names.

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 offers no when-to-use guidance or routing versus the many siblings (uk-products, us-products, uk-medical, search). The only guidance is cost-related (daily allowance, then x402 pricing), which informs billing, not 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely new behavior the annotations do not carry: default newest-first ordering and an explicit cost model (free within daily allowance, then per-call x402 payment). That pricing detail is real invocation-relevant 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 sentences, no filler. The resource scope is front-loaded and the cost/ordering facts follow. Every clause carries information an agent can use.

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

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

An output schema exists, so return values need not be explained, and the cost model plus ordering are covered. The remaining gap is sibling disambiguation against 'uk-food-alert', which is the most likely source of a wrong tool selection here.

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 all four parameters are documented in the schema itself, so the baseline is 3. The description contributes only the 'newest first' ordering hint, which implicitly relates to 'limit' and 'since' but adds no format or interaction 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?

The description names the specific source and resource set: FSA allergy alerts, product recall information notices, and food alerts for action, plus an ordering guarantee ('newest first'). That is a clear verb-plus-resource statement an agent can act on. It stops short of differentiating from the near-identical sibling 'uk-food-alert', which an agent would have to disambiguate by schema inspection.

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 second sentence is about billing (free daily allowance, then $0.001 USDC per call via x402), not about when to choose this tool over 'uk-food-alert', 'search', or 'uk-products'. There is no stated trigger, prerequisite, or exclusion. An agent gets no routing guidance at all.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety behavior is covered structurally. The description adds genuinely new behavioral context: that the call is free within a daily allowance and then costs $0.001 USDC via x402, which is a cost/rate consideration an agent cannot get from the annotations or schema.

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

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

Two sentences, tightly front-loaded: the payload contents come first, the pricing/allowance second. No filler, no restatement of the title, and 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?

With an output schema present, return-value documentation is not required, yet the description still summarizes the returned content; combined with the cost disclosure and the single well-documented id, an agent has enough to call this correctly. The missing piece is any explicit routing against the sibling list 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 description coverage is 100% and there is only one required parameter ('id'), whose schema description already specifies the FSA alert id format with an example. The description adds no further meaning about the id, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource: retrieving 'One FSA alert in full' for the UK/FSA source, and enumerates the payload (products, pack sizes, batch codes, allergens, risk, action taken, consumer advice), which distinguishes it from list-style siblings like product-recalls__uk-food. It stops short of explicitly naming the sibling it contrasts with, but the 'one ... in full' framing makes the detail-vs-list role 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?

Usage is implied rather than stated: an agent can infer it should call this when it already has an FSA alert id and needs full detail. There is no explicit when-to-use/when-not guidance, no mention of how to obtain the id (the schema implies uk-food), and no statement of the relationship to the other 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?

Annotations already declare readOnly, idempotent, and openWorld behavior, so the safety profile is covered. The description adds genuinely useful non-schema context: the x402 micropayment model and a free daily allowance, which affect invocation 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, purpose front-loaded and zero filler. The pricing sentence earns its place but could be seen as slightly secondary to the core description.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. Parameter coverage is complete via the schema; only explicit sibling routing is missing.

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

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

Schema coverage is 100%, so all four parameters are already documented with examples. The description's mention of 'medical specialisms affected' and the alert types mirrors the schema's alert_type examples rather than adding new syntax or format meaning.

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 source (MHRA), resource (drug and medical device alerts), and content types (recalls, field safety notices, device safety information). The 'medical/device' scope clearly separates it from the uk-food and uk-products 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 domain scope, but there is no explicit when-to-use, when-not-to-use, or routing to siblings like product-recalls__search or uk-products. The pricing note hints at cost considerations but gives no selection 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 declare read-only, idempotent, open-world, non-destructive semantics. The description adds genuinely new behavioral context not covered there: the free daily allowance and the $0.002 USDC per-call x402 pricing model, which materially affects invocation decisions. It also enumerates the record types returned (recall, withdrawal, marketplace takedown).

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

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

Purpose and scope are front-loaded in the first clause, with pricing isolated in a second short sentence. Examples are kept inside parentheses so they add specificity without bloating the sentence.

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

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

With an output schema present, return values need no explanation, and all five parameters are optional and fully documented in the schema. The description supplies source, coverage, and cost context; only explicit sibling routing is missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including allowed risk values and category slug examples. The description echoes the risk and category concepts but adds no syntax or format detail beyond the schema, making the baseline 3 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?

Names the authoritative source (OPSS), the resource (product safety alerts, reports and recalls), example categories, and the dimensions returned (risk level, category, measures taken). This makes it distinguishable from UK food (FSA) and UK medical (MHRA) siblings. However, it doesn't clarify how it differs from product-recalls__search, which appears to be a generic sibling.

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 implies a UK product-safety scope but states no when-to-use conditions, no prerequisites, and no explicit routing away from product-recalls__us-products or product-recalls__uk-food. An agent must infer the boundary from the source 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 the safe read-only, idempotent, non-destructive profile, so the description earns credit for adding non-structured context: the free daily allowance, the $0.002 USDC per-call pricing via x402, the default 90-day window, and the newest-first ordering. These are genuine behavioral facts not present in the annotations or schema.

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

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

Two tight sentences: the first front-loads what the tool returns and its search dimensions, the second covers cost. Every clause carries information and nothing is repeated.

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

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

With an output schema present, the description need not enumerate return values, and annotations cover safety. It supplies the default time window, sort order and cost model, leaving only the sibling-routing guidance as a minor gap.

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 six parameters. The description's mention of product name, manufacturer, UPC and hazard adds little syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (recalls) and resource (US CPSC consumer product recalls) plus the filter dimensions it accepts. The 'US CPSC' scoping clearly separates it from the uk-products and uk-* siblings.

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

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

It discloses the default behavior (last 90 days, newest first) and that results are searchable by name/manufacturer/UPC/hazard, which implies usage. However, it never explicitly says when to pick this tool over the sibling product-recalls__search or the UK variants, leaving the routing decision to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot express: the free daily allowance and the $0.001 USDC per-call x402 pricing after that. It does not mention pagination or result volume, but the cost model is the more decision-relevant fact.

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 no filler: purpose first, cost second. Nothing is padded, though the purpose sentence lacks an explicit verb and would benefit from one word ('List every local authority...') at no length cost.

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 fields, and it covers the two things an agent must know: what set is returned and what it costs. The only gap is that it never states this is an exhaustive, unfilterable listing versus a search endpoint, which would help against the uk-food-hygiene__search sibling.

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?

Zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly implies a full unfiltered listing rather than a query, which is consistent with the empty 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 resource and scope: 'Every local authority that runs a food hygiene scheme.' The resource is clearly a list of authorities in the food-hygiene domain, which distinguishes it from uk-geography__local-authority or uk-planning__local-authority by domain, though the description itself never names those siblings or uses an explicit verb like 'list'.

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 prerequisites, no mention of alternatives despite four sibling food-hygiene tools (business, ratings, search, regions) and several other 'local authority' tools in the namespace. The agent must infer usage entirely from the name.

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 new operational context not present in structured fields: the free daily allowance and the $0.002 USDC x402 charge per call, which is exactly the kind of rate/cost disclosure agents need 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?

Two short sentences with zero filler; the returned fields are front-loaded before the pricing note. Every clause carries information and nothing is redundant.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. Purpose plus pricing is nearly everything an agent needs; only a pointer to how the id is obtained (beyond the schema's hint) and error behavior for invalid ids are missing.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as an 'FHRS id from a search result'. The description only reinforces that the id selects one business, adding no format, range, or validation 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 the specific resource returned ('Rating, scores, inspection date and authority') and scopes it to 'one business', which together with the required id parameter makes the single-entity lookup intent unambiguous. It does not explicitly name the siblings it differs from (search, ratings, near), so it falls short of a 5.

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

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

Usage is only implied: a required 'id' sourced from a search result suggests this is the follow-up detail call, but the description never says when to use it versus uk-food-hygiene__search or __ratings, nor what happens for an unknown id. It adds a cost condition (free within daily allowance) but no 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: a free daily allowance followed by $0.001 USDC per call via x402, which tells the agent about cost and quota behaviour that the annotations do not express.

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

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

Two short sentences with no filler; the purpose is front-loaded and the pricing caveat follows. Every sentence carries information an agent needs, nothing is repeated from the schema or annotations.

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 annotations cover safety, so the description only needs to add cost/quota context, which it does. It stops short of telling the agent how to consume the codes (e.g. as the business-type filter on the search sibling), which is a minor but real gap for a reference-data endpoint.

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 schema descriptions have nothing to document and the baseline of 4 applies. The description correctly adds no parameter detail, though it also does not indicate what form the returned codes take for downstream calls.

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 (business type codes) and ties it to its domain (used in ratings), which separates it from siblings like score-descriptors and authorities. It never uses an explicit verb such as 'list' or 'returns', so the agent must infer it is a lookup endpoint, but the resource 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?

No when-to-use guidance is given: nothing says to call this before searching by business type, or how the codes relate to uk-food-hygiene__search or uk-food-hygiene__near. The only sentence beyond the purpose statement is pricing, which is not selection 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: the cost model (free within daily allowance, then $0.002 USDC via x402). It says nothing about result caps, pagination, or whether the point must be inside the UK.

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 the core capability front-loaded before the pricing note. No filler or restatement of the title. The billing sentence is relevant but could arguably have been deferred to documentation.

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 core purpose is stated. However, for a spatial-query tool an agent still lacks guidance on result limits, default radius behavior beyond the schema hint, and geographic coverage (UK-only), leaving noticeable gaps.

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 latitude, longitude and maxDistanceLimit. The description only implies that a distance parameter exists ('within a distance of a point') and adds no format details, units clarification beyond the schema's 'Miles (default 1)', or coordinate-order guidance. 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?

States a concrete verb+resource+scope: 'Rated food businesses within a distance of a point.' An agent can distinguish it from uk-food-hygiene__search or __business by the explicit spatial-radius framing. It stops short of explicitly naming the non-spatial sibling, so no sibling differentiation credit.

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, no naming of alternatives such as uk-food-hygiene__search for name-based lookups. The only conditional content is billing, which is not usage guidance for 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds genuinely new context in the form of the billing model (free within daily allowance, then per-call USDC), but says nothing about the shape, size, or stability of the returned enum list.

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 zero filler, and the substantive purpose statement is front-loaded ahead of the pricing note. 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?

For a zero-parameter static enum lookup with a full output schema and complete read-only annotations, the description covers what the agent needs to call it. The only gap is the unaddressed overlap with the score-descriptors sibling, which prevents 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to clarify. Baseline 4 applies since no parameter explanation is required or possible.

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 resource precisely ('Valid rating values and their meaning'), so an agent knows this is a static reference lookup rather than a search or detail tool. It does not, however, distinguish itself from the sibling uk-food-hygiene__score-descriptors, which sounds like an overlapping reference list.

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. The only operational note is pricing ('Free within the daily allowance, then $0.001 USDC per call'), which tells the agent about cost but not when this tool is the right choice versus score-descriptors or business.

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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds only the pricing model (free tier, then $0.001 USDC per call), which is useful but not behavioral about the data itself. It doesn't disclose whether this returns a fixed static list, how many regions, or format. With annotations covering safety, the description adds minimal behavioral context beyond pricing.

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 purpose then pricing. No wasted words. Could be improved by adding a sentence about what regions are or when to call it, but it's 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?

Output schema exists, so return values needn't be explained. But an enumeration/reference tool with no parameters should at least hint at what it provides (a list of regions/IDs) and that it's reference data for the food hygiene scheme. The description is functional but thin for a reference endpoint.

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?

Zero parameters, so schema-based baseline is 4 per the rubric, but the description doesn't compensate meaningfully. Actually, with 0 params, baseline is 4; however the description adds no param info because there are none. The description says nothing about what the tool returns for the 0-param call. Since there are no parameters to describe, parameter semantics is less relevant, and the description doesn't undercut it. Score 3 reflects that there's no parameter content to add 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 says 'Regions used by the ratings scheme,' which names a resource but with a vague verb and no differentiation from uk-geography__region or uk-planning__region, both of which also deal with regions. It communicates that it returns a list of regions but doesn't clarify it's a reference/enumeration endpoint for the UK Food Hygiene scheme.

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 guidance on when to use this tool versus alternatives. It doesn't explain that regions are likely reference data for filtering other uk-food-hygiene tools. The pricing note ('Free within the daily allowance...') is about cost, not usage context.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's real contribution is the x402 pay-per-call model with a free daily allowance — genuinely useful behavioral context an agent would not learn from the annotations. It does not clarify why a score-descriptor lookup is keyed to a specific establishment.

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, purpose front-loaded, no filler. The pricing sentence is compact and informative rather than wasted space.

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 low-complexity reference tool with an output schema and rich annotations, the definition covers purpose and cost. The remaining gap is the absence of any routing guidance relative to the many sibling uk-food-hygiene tools, plus no explanation of how establishmentId changes the answer.

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% for the single establishmentId parameter, so the baseline is 3. The phrase 'for a business' loosely hints that a specific establishment scopes the result, but no syntax, format, or behavioral meaning beyond the schema's 'FHRS id' is added.

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 concrete content it returns — the meaning of hygiene, structural and management scores — which is more specific than the title alone and distinguishes it from siblings like ratings or business that return scores rather than explain them. It lacks an explicit verb (e.g., 'explain'/'look up') and does not name an alternative tool, 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 statement of when to call this versus uk-food-hygiene__ratings or __business, no prerequisites, and no exclusion conditions. The only second-sentence content is the pricing model, which is cost guidance rather than usage 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the cost model (free within the daily allowance, then $0.002 USDC per call via x402), which is material, non-derivable context an agent needs before invoking repeatedly. It stops short of describing result caps or pagination.

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 padding, with the search scope front-loaded ahead of the pricing note. 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?

With an output schema present, return shape need not be explained, and both optional parameters are schema-documented. Pricing and read-only behavior are covered; only result-count/pagination limits and matching semantics 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 description coverage is 100%, so the baseline is 3. The description only restates the schema semantics ('by name and/or address or postcode') and adds the 'and/or' hint that both optional filters can be combined, which is marginal value 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 (find) and resource (rated food businesses) plus the search keys available (name and/or address or postcode). It clearly separates itself from the by-ID sibling (business) and the proximity sibling (near) by virtue of the query-style keys, though it never names those alternatives 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 by the query keys: an agent can infer this is the lookup path when it has a name or postcode rather than coordinates or an ID. However, no when-not-to-use or alternative routing (e.g. uk-food-hygiene__near for proximity, uk-food-hygiene__business for a known ID) is stated.

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