UK public services

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context: the cost model (free within the daily allowance, then $0.001 USDC per call via x402), which is decision-relevant for an agent and absent from structured fields. It doesn't describe pagination or error behavior, but the added cost disclosure is valuable.

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 returned fields before the pricing note. No filler. The content sentence is a dense list, but every element 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 an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers scope, returned fields, and pricing, leaving little an agent needs missing, though explicit sibling routing would complete 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?

Schema description coverage is 100% and the single 'code' parameter is already documented with concrete examples (RVV, G82052). The description only reinforces the 'one ODS code' scope without adding format or syntax 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?

The description gives a specific verb-less but concrete resource enumeration: name, status, address, phone/website, roles and relationships for one ODS code. An agent understands this is a single-entity lookup keyed by ODS code, distinct from the search sibling. It doesn't explicitly name which sibling to use instead, so it lands at 4 rather than 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?

The phrase 'for one ODS code' implies this is the single-entity retrieval path versus nhs-organisations__search, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is inferable but never 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 and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the enumeration is complete ('Every ODS role code') and there is a cost model (free within the daily allowance, then $0.0005 USDC per call via x402), which is material for an agent deciding whether to invoke.

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, the second front-loads the cost condition. Every clause earns its place with 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 an output schema present, return values need not be explained, and with zero parameters there is no schema gap to fill. Annotations cover safety, and the description covers scope and pricing; only minor omissions (e.g. whether the code list is versioned or how often it changes) keep it from 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, so the baseline is 4; there is nothing for the description to disambiguate. The reference to aliases that 'search accepts' adds a small amount of interpretive value about how the returned data is consumed, but no parameter semantics exist to document.

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 ('Every ODS role code with its name') and the added value (friendly aliases accepted by search), so an agent knows this is a static reference/enumeration lookup rather than a filtered query. It does not explicitly name sibling tools like nhs-organisations__search to differentiate, keeping it short of a 5.

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

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

Usage is only implied: the mention of 'the friendly aliases search accepts' hints this is the companion lookup for resolving role codes before calling search, but there is no explicit when-to-use or when-not-to-use statement and no named alternative. Pricing terms are given, but that 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 new behavioral context: a free daily allowance followed by a $0.001 USDC x402 charge per call, which is a real cost/threshold constraint an agent should 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?

Two tightly packed sentences with zero filler: capability and role list first, cost model second. 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 5 optional parameters, a 100% description coverage and an output schema handling return values, the description covers what an agent needs. It omits one thing worth stating — whether a call with no filters is valid or one filter is required — but that is 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 every parameter (name, role, limit, status, postcode) is already documented in the schema, including defaults and the role enumeration. The description largely restates that vocabulary rather than adding format or matching semantics, so the baseline 3 applies.

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

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

States a specific verb ('Find') and resource ('NHS organisations') and enumerates the searchable dimensions (name, postcode/district, role) plus the full set of role types. An agent can distinguish it from sibling nhs-organisations__organisation (single-record lookup) and nhs-organisations__roles 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?

Usage is implied by the enumerated search keys, but there is no explicit when-to-use statement and no routing to the sibling tools (organisation for detail lookup, roles for role listings). The only non-purpose sentence is about pricing, not 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: default 3 km radius, a hard 15 km cap, nearest-first ordering, and the pricing model (free within daily allowance, then $0.002 USDC per call via x402). Only the mechanics of the x402 payment flow are left unstated.

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

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

A single front-loaded sentence packs radius defaults and limits, ordering, optional phase filtering, and cost into one line with no wasted words.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety; the description covers scope, constraints, ordering and cost. Minor gaps remain around error behavior for invalid postcodes and how the paid tier is actually invoked.

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, but the description adds meaning beyond the schema by disclosing the 15 km maximum on radius_km and the nearest-first ordering, which is not captured anywhere in the parameter definitions.

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/list), resource (schools), and scope (within a radius of a postcode, nearest first), which cleanly separates it from siblings schools__search and schools__school. An agent can pick this tool 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 radius/ordering/phase phrasing implies the use case (proximity lookup filtered by phase), but there is no explicit statement of when to prefer this over schools__search or schools__school. Usage is inferable but not spelled out.

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

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

Annotations already cover read-only, idempotent and open-world behavior, so the bar is lower. The description adds real value beyond that by disclosing the pricing model: free within the daily allowance, then $0.001 USDC per call via x402, plus the breadth of the returned record.

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, front-loaded with the record's purpose followed by the field list and cost model. The field enumeration is long but each item is informative rather than padding.

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

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

An output schema exists, so return values needn't be explained, and the safety profile is fully covered by annotations. Adding the X402 pricing context makes the definition self-sufficient for correct invocation, with only sibling differentiation 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% with only one parameter ('urn' = Unique reference number), so the schema already carries the semantics. The description adds no format, example, or validation detail beyond it, matching the baseline 3.

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

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

States a specific resource ('Full register record for one establishment') keyed by URN, and enumerates the attributes returned (type, status, phase, ages, capacity, etc.). It is clearly a single-record lookup, though it never names the sibling tools (search, near) to sharpen the contrast.

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 'for one establishment' implies this is the single-URN detail lookup versus the plural siblings schools__search and schools__near, but that routing is left to inference. No explicit when-to-use/when-not guidance or prerequisites are given.

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 behavior beyond the structured fields: the default status filter (open only) and the commercial model (free within the daily allowance, then $0.001 USDC per call via x402). Rate-limit or pagination behavior is not addressed, so it stops 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 compact sentences, front-loaded with the search axes and default scope, and the pricing clause is deferred to the end where it belongs. No padding or repeated schema content.

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 shape need not be described. Filters, defaults and cost model are covered, which is what an agent needs before calling. Nothing is stated about result ordering or what happens when zero filters are supplied (a plausible call, since no parameters are required).

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 six parameters are already documented, including defaults ('open (default)', 'default 20, max 100') and the phase enum list. The description restates the main filter axes without adding format or syntax beyond the schema, which is the baseline-3 case.

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

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

Specific verb 'Find' plus resource 'schools' and an explicit enumeration of the filter axes (name, postcode/district, local authority name or code, phase) and the default status scope. It implicitly separates itself from schools__near (attribute search vs proximity), but it never names the sibling tools, so differentiation is inferred rather than stated.

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 establishes a usable context: attribute-based search with 'open schools by default'. It does not say when to prefer this over schools__near or schools__school, nor does it state any exclusions or prerequisites, so usage is implied rather than guided.

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.

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 operational context: free within a daily allowance, then $0.001 USDC per call via x402, which affects how an agent should budget calls. It stops short of 5 because nothing is said about caching/refresh cadence or how up-to-date the category set is.

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 functional purpose leads and the cost model follows. Every clause carries information an agent can act on.

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 single optional parameter is fully documented. The remaining gap is relational: the description never says how these categories connect to the crime/outcome tools that likely consume them.

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

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

Schema coverage is 100% and the schema already documents 'Month as YYYY-MM (default: latest)', so the description's 'for a month' adds no format detail beyond it. Baseline 3 is appropriate when the schema fully carries parameter 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 the resource clearly ('crime categories') and scopes it by month, so an agent can tell it apart from the crime-listing siblings. The verb is only implied (list/get), and there is no explicit contrast with tools like uk-police__crimes-at-location, 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?

No guidance on when to call this versus alternatives — e.g. whether it is a prerequisite lookup for the crime endpoints or a standalone reference. The only context given is billing, 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 readOnly, idempotent, open-world, and non-destructive. The description adds genuinely new behavioral context not present in structured fields: the metered pricing model (free within the daily allowance, then $0.002 USDC per call via x402), which is material for an agent deciding whether to invoke.

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. Purpose is front-loaded, and the pricing caveat follows immediately. Nothing is padded or 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 explained, and annotations cover the safety profile. Purpose, required identifier, and cost are all covered. The only missing element is explicit routing versus the location-based 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?

Schema description coverage is 100% and the single parameter is fully documented ('64-character persistent crime id from a crime result'). The description's 'by its persistent id' merely echoes the schema, so baseline 3 applies with no added parameter 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?

States a specific verb+resource with explicit scope: 'Full outcome history for one crime by its persistent id.' The 'one crime' scope implicitly distinguishes it from sibling uk-police__outcomes-at-location, but the sibling is never named, so the 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?

No guidance on when to use this versus alternatives like outcomes-at-location, crimes-at-location, or street-crime, nor any prerequisites. The pricing sentence describes cost, not routing, so an agent gets no help selecting this tool over a sibling.

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 real behavioral value beyond that: the cost model (free within a daily allowance, then $0.003 USDC via x402) and the anonymisation/point-snapping data caveat, both of which the agent cannot infer from structured fields.

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

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

Two tightly written sentences with the core purpose front-loaded and the pricing caveat second. No filler, 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 the return shape need not be explained, and 100% schema coverage handles the parameters. The description covers purpose, anonymisation semantics and cost, leaving only usage/alternative 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 lat, lng and date are fully documented in the schema and the description adds no parameter-level detail. The baseline of 3 applies when the schema does all 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?

The description gives a specific verb+resource (crimes returned around a point) and clarifies the location semantics as 'snapped to the nearest anonymised location', which separates it from siblings like crimes-no-location. It does not, however, name the nearby alternatives such as street-crime or outcomes-at-location to help disambiguate.

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 explicit when-to-use, when-not-to-use, or sibling routing guidance. The pricing sentence hints at cost considerations but never tells an agent which of the many uk-police crime tools to pick for a given query.

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 goes beyond them by disclosing the pricing/allowance model (free within daily allowance, then $0.002 USDC via x402), which is genuinely useful behavioral context for an agent.

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-loading what the tool returns before the billing note. Nothing is 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?

An output schema exists, so return values need not be explained, and the pricing disclosure is a bonus. The only gap is the absence of routing guidance against the similar crimes-at-location sibling, which an agent would otherwise have to infer.

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%, with each of the three parameters documented (date format, force id example, category example). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific resource and scope: 'Crimes a force could not map to a location, by category.' The 'no-location' framing cleanly separates it from the sibling uk-police__crimes-at-location, though it does not name that sibling 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?

The phrasing implies the use case (unmapped crimes for a given force/category), but there is no explicit when-to-use guidance, no mention of the contrasting uk-police__crimes-at-location tool, and no stated prerequisites such as needing a valid force id.

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 not present in structured fields: a free daily allowance acting as a rate limit and a $0.001 USDC x402 charge beyond it, which affects how an agent should budget 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 short sentences, front-loaded with what the tool returns before the pricing caveat. No filler or repetition, though the pricing sentence, while useful, competes with the more essential purpose statement for the same limited 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?

The tool is a single-parameter read with a full output schema and complete annotations, so return values and safety need no further explanation. Purpose and cost model are covered; the only gap is not telling the agent where a valid force id comes from.

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 format hint ('metropolitan', see forces) is already in the schema. The description adds no additional parameter meaning, 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?

Names a specific resource (a force) and enumerates what is returned: contact details, website and engagement methods. It is clear this is a single-entity lookup rather than the sibling list tool uk-police__forces, though the description never explicitly says 'single force by id' or names the sibling, so differentiation is only implied.

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 statement, no mention that a force id must first be obtained from uk-police__forces, and no exclusions relative to sibling tools like uk-police__force-officers or uk-police__neighbourhoods. The only usage hint ('see forces') lives in the schema, not the description.

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 a genuinely useful behavioral trait not in annotations — the free daily allowance followed by $0.001 USDC per call via x402 — which tells the agent about cost limits. It does not discuss rate limits or result breadth beyond 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 core content ('senior officers ... with biographies') is front-loaded. The pricing sentence is ancillary but earns its place as cost behavior.

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

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

An output schema exists, so return values need no explanation, and the one parameter is fully documented by the schema. For a simple read-only lookup, the definition is nearly complete; only the absence of when-to-use guidance keeps it from full marks.

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 'force' parameter is documented with an example and a pointer to the forces tool. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (senior officers of a force) and adds a distinguishing content trait (biographies), which separates it from siblings like uk-police__force and uk-police__forces. It lacks an explicit verb, but the resource being returned 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 guidance on when to use this rather than uk-police__force, uk-police__forces, or other police endpoints. The only context offered is pricing, not usage conditions or alternatives.

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 useful non-annotation context — the cost model ('free within the daily allowance, then $0.001 USDC per call via x402') — but says nothing about data freshness, caching, or result size.

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 pricing caveat. Every clause carries information and nothing is padded.

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 zero parameters plus full annotation coverage mean little is required. The description is adequate, though it could name the sibling alternative and note that this is a static reference list.

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 the baseline of 4 applies; there is no parameter semantics to explain and the description correctly does not invent any.

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 the resource precisely ('Every police force') and even names the payload field ('with its id'), so an agent knows this is a full listing of forces. It does not, however, contrast itself with the sibling uk-police__force, so an agent must infer from singular vs. plural naming that this is the bulk list and the other is a single-force lookup.

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 the obvious alternative, uk-police__force, for retrieving one force by id. The agent is left to infer the distinction purely from the tool 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, openWorld and non-destructive behavior, so the safety burden is covered. The description adds genuinely useful context the annotations cannot express: pricing tiers (free within the daily allowance, then $0.001 USDC per call via x402). It does not describe the response format, but an output schema exists to cover 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, zero waste, and the core answer (latest available month) is front-loaded ahead of the billing caveat. 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 lookup with an output schema and full annotation coverage, the description supplies what it returns and the cost model, which is sufficient to invoke it correctly. It stops just short of explaining how the returned month should be used downstream, which would have made it fully self-contained.

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 the per-dimension baseline of 4 applies. The description does not need to explain any input, and there is no parameter ambiguity it could resolve.

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 precisely what is returned: the latest month with crime data available. That is a clear resource with an implicit retrieval verb. It does not, however, differentiate itself from siblings like uk-police__crimes-at-location or uk-police__street-crime, nor explicitly frame itself as the date-range discovery helper for those tools.

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

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

Usage is only implied: an agent can infer this tool answers 'what month can I query?' before hitting the crime-data endpoints. There is no explicit when-to-use statement, no exclusion, and no named alternative sibling, which holds it to the minimum-viable level.

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 (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the description is not carrying that burden. It does add genuinely useful behavioral context beyond the annotations: the free daily allowance and the $0.002 USDC x402 charge per call after that, which an agent needs for cost-aware invocation.

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, both front-loaded and wasteful-free: the first gives the semantic contract, the second the cost contract. Nothing is redundant with the title 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?

For a one-parameter lookup with an output schema present and safety covered by annotations, the description supplies what is needed (what it resolves, and the cost model). It omits only edge-case behavior such as what happens when the point falls outside any neighbourhood or outside the UK.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'Point as "lat,lng"'. The description only echoes 'lat,lng point' without adding format constraints, ordering guarantees, or valid ranges, 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?

The description states a specific verb-and-resource outcome: resolving a lat,lng point to the force and neighbourhood that cover it. That is clearly distinct from siblings like uk-police__neighbourhoods (list) or uk-police__neighbourhood (by id), though it never names those siblings explicitly, 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 by the phrasing 'covers a lat,lng point' — there is no explicit statement of when to use this versus uk-police__neighbourhoods or uk-police__force, and no exclusions or prerequisites (e.g. coordinate bounds, UK-only) are given. The pricing sentence adds operational context but 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 the safe, idempotent, read-only, open-world profile, so the description is free to add something new — and it does, disclosing the metering model (free within the daily allowance, then $0.001 USDC per call via x402). That cost/rate disclosure is genuinely useful behavior an agent cannot infer from structured fields. It stops short of covering auth or failure modes.

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 zero filler, purpose front-loaded before the pricing note. Every clause carries information the agent would otherwise lack.

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

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

With an output schema present, the description needn't explain return values, and annotations cover the safety profile; purpose plus cost is nearly sufficient for a two-parameter lookup. The one remaining gap is disambiguation from the crowded uk-police__neighbourhood* sibling set.

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

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

Schema description coverage is 100%, and the schema already explains both parameters (force id, neighbourhood id within the force) and points at the forces/neighbourhoods lookups. The description adds no parameter meaning beyond this, 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?

Names a specific resource (neighbourhood) and enumerates the returned fields (contact details, description, centre), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from close siblings such as neighbourhood-team, neighbourhood-boundary, neighbourhood-priorities, or neighbourhoods, which all operate on the same resource.

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 over the other neighbourhood-* tools, and no prerequisites stated for supplying a force/neighbourhood id. The only extra information is billing, which is cost context rather than usage routing.

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

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

Annotations already cover the safety profile (read-only, idempotent, open-world, non-destructive), but the description adds useful behavioral context: the return format is a boundary polygon as lat/lng points, and pricing is free within a daily allowance then $0.002 USDC per call via x402. This goes beyond annotations, though it does not cover auth or broader rate-limit behavior.

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

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

Two tightly written sentences with zero waste. The primary purpose is front-loaded, and the pricing detail follows as supplementary context.

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

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

For a simple two-parameter, read-only tool with an output schema and rich annotations, the description covers purpose, return format, and pricing. It leaves out usage guidance and how to obtain the required ids, but the schema descriptions point to forces and neighbourhoods, so most calling needs are met.

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 both parameters (force and neighbourhood) are already documented in the input schema. The description adds no further syntax, format, or constraint details beyond what the schema provides, 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?

The description clearly states the returned resource: a boundary polygon of a neighbourhood as latitude/longitude points. It does not explicitly distinguish this tool from siblings such as uk-police__neighbourhood or uk-police__locate-neighbourhood, so it falls short of full sibling differentiation.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as first resolving a force and neighbourhood id. Usage is only implied by the returned resource, which is minimal 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the cost model (free within daily allowance, then $0.001 USDC via x402), which annotations do not provide, but it says nothing about result freshness or volume.

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 that are front-loaded with the purpose before the commercial terms. Nothing is redundant, though the pricing sentence occupies half of a very short 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?

An output schema exists so return values need not be described, annotations cover the safety profile, and the schema fully documents the two required parameters. The description contributes purpose and cost, leaving only marginal gaps such as pagination or update frequency.

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

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

With 100% schema description coverage, both parameters are already documented in the schema, including pointers to the forces and neighbourhoods lookup tools. The description adds no syntax or format detail beyond what the schema supplies, 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 concrete resource ('upcoming community events') and its scope ('run by a neighbourhood team'), which is enough for an agent to know what it retrieves. It does not explicitly contrast itself with nearby siblings such as neighbourhood-priorities or neighbourhood-team, but the resource is distinct enough to disambiguate.

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, no mention of prerequisites beyond the implied force/neighbourhood pair, and no routing to alternatives. The only contextual sentence concerns pricing, not 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 the safety profile is covered. The description adds genuinely useful behavioral context by disclosing the cost model (free within daily allowance, then $0.001 USDC per call via x402), which the agent cannot learn from structured fields.

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

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

Two tight sentences with zero padding: the resource definition is front-loaded and the pricing caveat follows. 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 values need no explanation, and both required params are covered by the schema. The remaining gap is routing guidance against the many uk-police neighbourhood siblings, but for a low-complexity two-param lookup the description is largely sufficient.

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

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

Schema description coverage is 100% and both parameters are documented in-schema with cross-references to the forces and neighbourhoods lookups. The description adds no additional meaning about force or neighbourhood ids, 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?

The description names a specific resource ('issues a neighbourhood team has committed to tackle, and what it did'), which distinguishes it conceptually from neighbourhood-events or neighbourhood-team. However, it never explicitly names a sibling or contrasts itself, relying on the agent to infer the boundary from the vague content phrasing.

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 use this tool versus uk-police__neighbourhood, neighbourhood-team, or neighbourhood-events, all of which operate on the same force/neighbourhood keys. Pricing information is provided, but that is cost context, not 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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: the call is free within the daily allowance and then costs $0.001 USDC per call via x402, which lets an agent reason about cost/rate behavior.

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

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

Two short sentences with the resource stated up front and the pricing note second; nothing is wasted. It is tight, though the terse noun-phrase style trades a little clarity for brevity.

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 the single parameter is fully documented in the schema. The description covers what the tool returns and its cost model; the only notable gap is the absence of any disambiguation from the neighbouring neighbourhood-* 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% with a single documented 'force' parameter, so the schema already carries the semantics. The description adds nothing beyond the schema about the parameter format or acceptable values, which is baseline-appropriate when the schema does the work.

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

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

The description clearly states the resource and scope: neighbourhood policing areas belonging to a given force. However, it does not distinguish itself from close siblings like uk-police__neighbourhood, uk-police__neighbourhood-boundary, uk-police__neighbourhood-team, or uk-police__locate-neighbourhood, so an agent must guess which variant returns the area 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 guidance on when to choose this tool versus the other neighbourhood-related siblings, nor any stated prerequisites beyond the required force id. The only contextual note is pricing, which is cost information 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 safety is covered. The description's only added trait is the pricing model (free within the daily allowance, then $0.001 USDC per call via x402), which is genuine non-annotation context, but it says nothing about auth, rate limits, 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 with the resource stated first and the cost note second; nothing is padded. The pricing sentence is operationally relevant rather than 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?

An output schema exists, so return structure need not be explained, and the two-string input is fully specified by the schema. The remaining gap is differentiation from neighbouring uk-police neighbourhood endpoints, which an agent cannot resolve from this description alone.

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?

Both required parameters have 100% schema description coverage, including pointers to the forces and neighbourhoods endpoints for valid ids, so the schema carries the load. The description adds no parameter meaning beyond that, which is the expected baseline here.

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

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

Names a concrete resource — the officers attached to a neighbourhood policing team — which distinguishes it from sibling endpoints like neighbourhood-priorities, neighbourhood-events, and neighbourhood-boundary. It is a noun phrase rather than a verb+resource, so it never explicitly says 'list the officers', but the intent 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 and no routing to alternatives. With siblings such as uk-police__neighbourhood, uk-police__neighbourhoods, and uk-police__locate-neighbourhood in the same namespace, the description should say which one to pick, but gives nothing.

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 safety is covered. The description adds genuinely new behavioral context the annotations lack: the free daily allowance and the $0.003 USDC per-call x402 pricing. It stops short of noting coverage limits (outcomes only exist for resolved cases) or result caps.

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, zero waste, with the purpose front-loaded before the pricing caveat. Every element 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-shape detail is not required, and annotations plus full schema coverage handle the rest. The description is essentially complete for calling the tool, though it omits any hint that outcomes only exist for a subset of crimes.

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 lat, lng, and the YYYY-MM date with its 'latest' default are all documented in the schema. The description's 'near a point' adds only the conceptual framing, not syntax or format detail, so the baseline 3 applies.

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

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

The description names a specific resource (case outcomes for crimes) and scopes it geographically ('near a point'), which is enough to distinguish it in spirit from crimes-at-location. However it never names the sibling that returns raw crimes rather than outcomes, so the differentiation is left to the agent's inference.

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

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

There is no explicit when-to-use guidance, no mention of when to prefer crimes-at-location, crime-outcomes, or street-crime instead, and no prerequisites or exclusions. The geographic phrasing implies a lat/lng lookup but does not state the selection condition.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine non-obvious context the annotations cannot express: a free daily allowance followed by $0.003 USDC per call via x402. It stops short of saying what happens when the allowance is exhausted (error vs. auto-charge).

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, zero waste, and the functional scope is front-loaded before the pricing note. Every sentence 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 an output schema present, return values need no explanation, and the params are documented in the schema. The description covers scope plus cost/rate-limit, which is the main thing a caller needs before invoking. Only minor gaps remain (allowance-exceeded behavior, explicit pointer to the ':near' alternative).

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 already carry descriptions (date format YYYY-MM with latest default; force id with example and 'see forces' pointer). The description's 'force and month' phrasing maps to the params but adds no syntax or lookup guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: 'Stop and search records for a force and month.' An agent can tell it retrieves stop-and-search data scoped by police force. It does not, however, name or contrast the sibling uk-police__stop-search-near, which is exactly the alternative an agent would confuse it with.

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, no when-not, and no mention of the near-location sibling as the alternative. The only implicit usage signal is the required 'force' parameter, leaving the agent to infer the routing decision from the schema 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 earns credit for adding context the annotations cannot: the fixed one-mile radius, and the billing model (free within daily allowance, then $0.003 USDC per call via x402), which materially affects call volume 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, zero waste, and the what/scope is front-loaded before the pricing caveat. Nothing is repeated from 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?

An output schema exists, so return values need no explanation, and the annotations plus the pricing/radius notes give the agent enough to call correctly. The only omitted piece is routing guidance versus the other UK police search tools, a minor gap for a tool this simple.

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 each of lat/lng/date is documented, including the YYYY-MM format and 'latest' default, so the schema does the heavy lifting. The description adds only the fixed one-mile radius, which is not a parameter anyway; 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 specific resource ('stop and search records') and a precise spatial scope ('within a mile of a point'), which an agent can contrast with the by-force sibling stop-search-force without opening the schema. It stops short of naming that alternative explicitly, so it is clear but not fully differentiated in-text.

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 geographic scope ('within a mile of a point'), and the cost sentence tells the agent when calls are free vs paid. However, there is no explicit when-to-use guidance relative to sibling stop-search-force or crimes-at-location, so the agent must infer the selection rule.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add beyond that. It does: it discloses the hard-coded one-mile radius and the x402 payment model with a specific price, neither of which is visible in the structured fields. Return format and pagination are covered by the output 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, zero padding, with the core scope statement front-loaded and the payment caveat second. 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?

For a three-parameter proximity query with a rich output schema and full annotation coverage, the description supplies the two non-obvious facts (radius cap, payment terms). It leaves the fixed-radius choice unexplained and doesn't address result limits, 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% for all three parameters (lat, lng, date as YYYY-MM), so the schema does the documentation work. The description only indirectly hints at the parameters via 'within a mile of a point' and 'for a month'; 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 (street-level crimes) with a fixed spatial scope (within a mile of a point) and temporal scope (a month). An agent can distinguish it from siblings like crimes-at-location or stop-search-near, though it never names a sibling to sharpen the contrast.

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?

Implied usage is clear from the scope statement, and the cost model ('free within the daily allowance, then $0.003 USDC per call') is a genuinely useful invocation signal. However, it gives no explicit when-to-use or when-to-prefer-an-alternative guidance versus the other uk-police crime tools.

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