UK property & area data

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, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context the annotations lack: the metered pricing model (daily free allowance, then $0.001 USDC via x402), 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 with no padding, and the resource identification leads. The awkward first clause slightly blurs the opening but 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 described, and the schema fully covers the single parameter. However, for a lookup-by-code tool there is no mention of invalid/missing code behavior, and the purpose statement is too imprecise to tell the agent what it will actually get back.

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

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

Schema coverage is 100% with a single 'area' parameter documented as 'Flood area code'. The description adds nothing beyond that (no format, prefix, or valid-code hints), so the baseline of 3 is appropriate.

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

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

The opening clause is garbled — it looks like a list of return fields (description, river or sea, polygon reference) rather than a statement of purpose — but 'for one flood area' implies a single-area lookup by code. It does not distinguish itself from siblings such as uk-flood__flood-areas-near or uk-flood__warnings, so an agent must infer the difference.

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 prerequisites, and no mention of the sibling flood tools. The only conditional information is billing ('free within the daily allowance, then $0.001 USDC per call'), which is a cost note, 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the cost model (free within a daily allowance, then $0.002 USDC per call via x402), which affects how an agent should batch or budget calls. It still says nothing about result shape or result-count limits.

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

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

Two compact sentences with zero filler, and the core spatial purpose is front-loaded before the commercial detail. Every sentence carries distinct 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 and annotations covering the safety profile, the description need not explain return values, and it does cover spatial scope plus an unusual x402 billing constraint. The remaining gap is sibling disambiguation against uk-flood__warnings-near and uk-flood__flood-area, which share the same domain.

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 lat, long and the dist radius (default 5 km) all documented in the schema itself, so the baseline is 3. The description adds no format details (e.g. decimal degrees, coordinate system) or interpretation of the radius beyond what the schema already provides.

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

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

States a specific verb and resource ('flood alert and warning areas') plus the spatial scope ('within a radius of a point'), so the agent knows it returns area polygons, not station readings. However, it never distinguishes itself from the very similar sibling uk-flood__warnings-near, which by name sounds like it retrieves overlapping data.

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

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

The description gives no when-to-use context, no prerequisites, and no guidance on choosing between this tool and siblings such as uk-flood__warnings-near, uk-flood__flood-area, or uk-flood__stations-near. The only routing information present is the pricing note, which is 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 behavioral context beyond the annotations: the free daily allowance and the $0.002 USDC x402 cost after that, which tells the agent this is a metered/paid endpoint and to avoid redundant 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 with zero filler; the purpose is front-loaded and the pricing caveat follows immediately. 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 and full parameter documentation, the description does not need to explain return values, and it covers cost behavior. The remaining gap is sibling disambiguation against uk-rivers__rainfall-near, which is the one thing an agent could plausibly get wrong here.

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

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

Schema description coverage is 100%, so lat, long and dist are already documented in the schema (including the default radius of 5 km). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific resource ('Rainfall stations') and scope ('near a point'), so an agent knows it returns nearby rain gauges. However, it does nothing to distinguish itself from the near-identical sibling uk-rivers__rainfall-near (nor from uk-flood__stations-near), leaving a real disambiguation gap for an agent picking between namespaces.

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 or when-not-to-use guidance, no mention of how it relates to the sibling 'stations-near' or 'uk-rivers__rainfall-near' tools, and no prerequisite context. The only 'guidance' is pricing, which is a cost note rather than selection advice.

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 value beyond them by disclosing the pricing model (free within the daily allowance, then $0.002 USDC per call via x402), which an agent needs 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 waste, front-loading what the tool returns before the cost note. 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 one-parameter read tool with a full output schema and complete annotations, the description covers purpose and cost. It is not quite complete on sibling differentiation, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100% for the single riverName parameter, including a format example. The description's phrase 'named river' mirrors the schema without adding syntax or edge-case detail, so the baseline of 3 applies.

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

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

States a specific verb+resource: monitoring stations on a named river. The 'by river' scoping implicitly separates it from location-based siblings like uk-flood__stations-near and uk-rivers__stations-near, though it never names them.

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 requirement of a river name implies when this tool applies, but there is no explicit when-to-use guidance or routing against the many sibling station tools (uk-flood__stations-near, uk-flood__station, uk-rivers__stations-near). Usage must be inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description does add genuinely new behavior — the metered pricing (free within daily allowance, then $0.002 USDC per call) and the 'currently in force' active-only filter — but says nothing about freshness or update cadence.

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 scope statement front-loaded and the cost note last; every sentence carries information. The only cost is the conflation of severe and non-severe warnings in the opening clause.

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

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

With an output schema present, return values need no explanation, and annotations cover the read-only profile. The description supplies scope and pricing, leaving only the sibling-differentiation gap relative to uk-flood__warnings.

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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No syntax or format detail is needed or missing.

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

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

It names the resource (flood warnings currently in force) but supplies no verb, leaving it ambiguous whether the tool lists, searches or fetches. The scope sentence is also muddled: the tool is named 'severe-warnings' yet claims to return both severe and ordinary flood warnings, which blurs its boundary against the sibling uk-flood__warnings.

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 is given on when to choose this over uk-flood__warnings or uk-flood__warnings-near, nor any precondition. The agent must infer the distinction from the name alone.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description does add genuine behavioral value with the pricing model (free within the daily allowance, then $0.001 USDC via x402), which is exactly the kind of context annotations cannot carry, but it says nothing about rate limits, auth, or failure behavior for an unknown reference.

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. The content summary is front-loaded and the pricing caveat is appended where it belongs, so an agent gets the essential information in the first clause.

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 description's field list plus pricing makes it callable as-is. The remaining gap is sibling disambiguation against uk-rivers__station and uk-flood__station-latest, which this crowded tool family would benefit 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 coverage is 100% and the schema itself supplies the format example ("1491TH"), so the description need not repeat it. The description adds no syntax, casing, or lookup guidance beyond the schema, making a 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?

States a concrete resource ("one monitoring station") and enumerates the returned content (location, river, typical range, measures), so the agent knows what it retrieves. However, it does not distinguish itself from close siblings like uk-rivers__station or uk-flood__station-latest, which an agent could easily 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?

Usage is only implied: call this when you already have a station reference and want detail. There is no explicit when-to-use, no pointer to uk-flood__river-stations or stations-near for discovering a reference, and no statement of when a sibling (station-latest for current readings) is preferable.

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

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the bar is low, and the description adds genuinely useful context beyond them: the maximum 4-week history window and the monetization model (free within the daily allowance, then $0.003 USDC per call via x402). It does not describe pagination or truncation behavior when the result set exceeds _limit.

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, zero filler, with the resource and lookback window front-loaded and the cost note trailing where it belongs.

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

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

An output schema exists, so return values need not be explained, and the description covers the resource, the time window, and cost. The remaining gap is result-set handling (pagination/truncation at _limit) for what is a time-series history 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?

Schema description coverage is 100%, so the baseline is 3. The description adds one real constraint not present in the schema – that `since` cannot go further back than 4 weeks – but says nothing about `_limit` behavior or station reference format beyond what the schema already documents.

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 ('Readings from a station') and scopes it with the since date-time and a 4-week lookback, which distinguishes it from uk-flood__station-latest and uk-flood__station. It stops short of naming those siblings explicitly, so an agent must infer the boundary between this and the latest-reading tool.

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

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

The 4-week lookback constraint and the pricing note imply when this tool is appropriate (historical series rather than current conditions), but there is no explicit when-to-use vs when-not, and no alternative sibling is named. Usage is inferable but not stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: the pricing model (free within daily allowance, then $0.002 USDC per call via x402). It does not describe response shape, but an output schema exists.

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 core purpose front-loaded before the cost note. 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 single-parameter read tool with full annotations and an output schema, the description covers purpose and cost adequately. It stops short of clarifying what 'every measure' returns or how it differs from the sibling station tool, but the structured fields carry the rest.

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 'station' parameter is documented with an example in the schema, so baseline 3 applies. The description adds no syntax, format or example detail beyond what the schema already provides.

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: latest readings from every measure at a station, which distinguishes it from history-oriented siblings like uk-flood__station-history. It does not explicitly name or contrast with the closest sibling (uk-flood__station), 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?

The word 'Latest' implies current-state retrieval as opposed to the historical variant, but no when-to-use guidance or explicit alternatives are given. The agent must infer the boundary against uk-flood__station and uk-flood__station-history.

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 usefully adds the pricing/allowance model, which no annotation provides and which an agent must know before calling. It stops short of covering result volume or the effect of a large dist.

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 the resource and location scope before the pricing caveat. 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?

An output schema exists, so return-value explanation is not required, and the description names the station categories returned plus the cost model. What is missing is any hint about the maximum usable radius or expected result counts for an open-world spatial query.

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% (lat, long, dist all documented with the km default), so the schema carries parameter meaning. The description adds nothing about coordinate format or a maximum radius, 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 resource (river level, flow, tidal and rainfall monitoring stations) and the spatial scope ('near a point'), which separates it from uk-flood__river-stations and uk-flood__rainfall-near. It does not explicitly name those siblings, so a reader must infer the distinction from the resource wording 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?

The only guidance is commercial: free within the daily allowance, then $0.002 USDC per call via x402. There is no statement of when to prefer this over uk-flood__rainfall-near, uk-flood__tide-gauges or uk-flood__river-stations, nor any note on radius or result-count limits.

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 a genuinely useful behavioral fact the annotations cannot convey: the pricing model (free within a daily allowance, then $0.001 USDC per call via x402). It does not discuss rate-limit ceilings or result freshness, but the cost disclosure is meaningful added context.

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

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

Two short sentences with zero waste. The scope statement is front-loaded ahead of the commercial detail, so the agent gets the 'what' first and the 'cost' second.

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 fields need not be explained, and the cost model is disclosed. The description stops short of noting coverage limits (England only, tidal gauges only) as an explicit exclusion, but for a zero-parameter listing tool this is close to complete.

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

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

The tool takes zero parameters, so there is no parameter surface for the description to explain. Baseline of 4 applies; nothing is misleading or missing.

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

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

Names a specific resource ('tidal level monitoring station') and bounds it geographically ('in England'), which implicitly separates it from the river-station siblings. It reads as a noun phrase rather than stating the verb (list/retrieve), but the operation 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 pick this over sibling tools such as uk-flood__river-stations, uk-flood__stations-near, or uk-flood__station. The agent must infer from the phrase 'tidal level' alone that this is the tidal-station listing.

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 open-world, so the safety profile is covered. The description adds genuinely new behavioral context: geographic coverage is England only, and it discloses the pricing model (free within daily allowance, then $0.002 USDC per call via x402), which matters for planning repeated calls.

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

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

Two short sentences, front-loaded with what the tool returns and followed by cost. Every clause carries information an agent can act on; nothing is 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 need no explanation, and the description supplies scope (England) and cost. The only gap is that it never positions itself against the severity- or location-filtered siblings, so routing among the uk-flood tools is left partly to guesswork.

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 schema baseline of 4 applies and there is nothing for the description to disambiguate. No parameter detail is needed or missing.

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

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

States a specific resource and scope: all flood alerts and warnings currently in force, in England. It does not explicitly contrast itself with close siblings such as uk-flood__severe-warnings or uk-flood__warnings-near, though 'every ... currently in force' implies an unfiltered full 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 and no exclusions. With siblings like uk-flood__severe-warnings (severity-filtered) and uk-flood__warnings-near (location-filtered), the description should say when this unfiltered national list is the right pick, but it leaves that to inference.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive hints, so the bar is lower. The description adds genuinely non-structured behavioral context: the cost model (free within a daily allowance, then $0.002 USDC per call via x402) and the 'in force' filter meaning only currently active alerts are returned, which is meaningful for an open-world read.

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

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

Two short sentences with the core capability front-loaded and zero padding. The pricing sentence consumes roughly half the description, which is justified for a paid x402 endpoint but is slightly disproportionate to the functional payload.

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 carry the safety profile. Coverage is close to complete for a 3-parameter geo query, though it omits geographic coverage limits (UK only) and how results distinguish alerts from warnings or rank by distance.

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, long, and dist with its default of 5 are fully documented in the schema itself. The description only restates the geospatial model ('radius of a point') without adding unit conventions, coordinate format, or radius bounds, so the baseline of 3 applies.

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

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

States a specific resource ('Flood alerts and warnings in force') and a spatial scope ('within a radius of a point'), which implicitly separates it from the unfiltered sibling uk-flood__warnings. It does not explicitly name a sibling or call out the severe-only variant, 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 when-to-use or when-not-to-use guidance is provided. An agent must infer from the phrase 'near a point' that this is the right tool when it has coordinates, and there is no direction on how it differs from uk-flood__warnings, uk-flood__severe-warnings, or uk-flood__flood-areas-near.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower; the description still adds real value by disclosing the cost model (free within the daily allowance, then $0.001 USDC per call via x402) and by flagging that split wards are marked in the result. It says nothing about rate limits or failure modes on invalid codes.

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 substantive scope statement is front-loaded and the pricing note follows. No filler or repetition of the title.

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

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

An output schema exists, so return values need not be described, and the description still summarises the payload (wards plus local authorities) and the commercial terms. The gap is the absence of any guidance on what the single required code must look like or what happens for an unknown constituency.

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

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

Only one parameter with 100% schema description coverage ('ONS constituency code'), so the schema fully documents it and the description adds no format, prefix or validity detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States the specific resource and scope precisely: the wards (with split-ward flags) and local authorities composing a 2024 Westminster constituency. This distinguishes it from the other uk-geography siblings (county, ward, local-authority, lsoa), though it never names an explicit verb or notes that it operates on a single ONS code.

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 indication of when to pick this over uk-geography__ward, local-authority or search, and no prerequisites such as needing a valid ONS code. The only contextual sentence concerns pricing, which is 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new context in the payment model (free within the daily allowance, then $0.001 USDC per call via x402), but says nothing about auth setup for x402, rate limits, or what happens with an invalid hierarchy code.

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 functional purpose front-loaded and the cost note second; nothing is padded. It could arguably be tightened further but 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?

With an output schema present, return-value detail is not required, and the description correctly identifies what the call yields for a one-parameter lookup. The remaining gap is the lack of any routing hint against the very similar geography siblings.

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

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

Schema description coverage is 100% for the single 'code' parameter ('ONS county/unitary code'), so the schema carries the burden. The description adds no syntax, format, or example beyond naming the resource, so it stays at 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 the resource precisely: the local authority districts contained in a county or unitary authority, which is a specific derived output rather than a tautology of the name. It does not, however, contrast itself with the nearby uk-geography__local-authority or uk-geography__region siblings, so the agent must infer the distinction.

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 only sentence beyond the purpose is a pricing note; there is no statement of when to prefer this over uk-geography__local-authority, uk-geography__search, or uk-geography__ward, and no prerequisite or valid-code 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 establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's real contribution is the billing/rate-limit disclosure (daily free allowance, then $0.001 USDC per call via x402), which is genuinely useful behavioral context an agent cannot get from annotations. It stops short of describing response shape, though the output schema covers that.

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

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

Two tight sentences with zero filler: the returned hierarchy is front-loaded and the cost 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?

Safety profile comes from annotations and return values from the output schema, so the description only needs to add scope and cost, which it does. The one gap is that the required ONS LAD code has no pointer to how an agent should obtain or validate it, despite a relevant uk-geography__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?

Schema description coverage is 100% and there is a single required string parameter documented as an 'ONS local authority district code', so the schema does the heavy lifting. The description adds domain color about what that code resolves to but no format, validation, or example details beyond the schema; 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 the payload it returns (county/unitary, region, country, wards, constituencies) for a given local authority district, which distinguishes it from uk-geography__county or uk-geography__region by making clear it resolves a district code into its containing hierarchy. It does not explicitly name those siblings, so an agent must infer the distinction.

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 or when-not-to-use guidance is given, and no alternative is named. The only conditional statement concerns billing ('free within the daily allowance, then $0.001 USDC per call'), which is pricing rather than invocation guidance; nothing tells the agent to first obtain a code via uk-geography__search.

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

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

The annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds a useful behavioral trait that the annotations do not: the pricing model, including the free daily allowance and $0.001 USDC per call via x402.

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

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

The description is two efficient sentences with no wasted words. It front-loads what the tool returns and follows with the cost model, both of which are relevant to calling the tool.

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

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

For a one-parameter lookup with a complete output schema and rich annotations, the description is nearly complete: it states the return relationship and pricing. Minor gaps remain around error behavior for unknown codes, but the output schema covers return values.

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

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

Schema description coverage is 100%, so the single parameter is fully documented in the schema as an ONS LSOA code. The description does not add syntax, format, or validation details beyond what the schema already provides, which matches the baseline for high-coverage schemas.

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 and version (2021 Lower Layer Super Output Area) and states what it returns (ward and local authority). It is clearly a lookup tool, but it does not explicitly distinguish itself from siblings such as msoa, ward, or local-authority.

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. It does not mention that the caller should have an LSOA code or when to prefer msoa, ward, or other geography lookups.

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the pricing model (free within the daily allowance, then $0.001 USDC per call via x402), which affects whether an agent should batch or cache 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 sentences with zero filler: the first front-loads what is returned, the second carries the cost model. Nothing could be removed 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile, leaving little for the description to carry. The main residual gap is not telling the agent how to obtain a valid MSOA code (e.g. via uk-geography__search).

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 the required 'code' field as an ONS MSOA code. The description's phrase 'for a 2021 Middle Layer Super Output Area' lightly reinforces the vintage of the code but adds no new syntax or format guidance.

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

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

Names the resource (2021 Middle Layer Super Output Area) and states the specific outputs (wards and local authority) for a given ONS MSOA code, so the agent can tell it is an upward hierarchy lookup. It does not explicitly distinguish itself from its closest sibling, uk-geography__lsoa, which is the same shape of tool at a different granularity.

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 versus uk-geography__lsoa, uk-geography__ward, or uk-geography__search, nor where the required MSOA code comes from. The only usage-adjacent note is pricing, which does not help 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 establish the safety profile (read-only, idempotent, open-world, non-destructive). The description adds a genuinely useful behavioral fact they don't carry: it is free within a daily allowance and then costs $0.001 USDC per call via x402, which is relevant to invocation decisions.

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

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

Two tight sentences with the purpose front-loaded ahead of the pricing note. Nothing is wasted, though the pricing clause is tangential to core function.

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 covering return values, full annotation coverage for safety, and complete parameter documentation, the description only needs to add purpose and any special behavior. It does both (purpose + pricing), leaving usage routing as the notable 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?

The single parameter has 100% schema description coverage ("ONS parish code"), so the schema does the documenting. The description adds nothing beyond it and only implies the input is a parish lookup; baseline 3 fits when the schema carries the load.

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 concrete return ("The ward(s) and local authority for a civil parish"), making it clear this is a reverse lookup from parish to its containing ward and local authority. It does not, however, distinguish itself from nearby siblings such as uk-geography__ward or uk-planning__parish, so the boundary between them is left to 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 statement of when to use this tool versus the many sibling geography lookups, no prerequisites, and no exclusions. The only guidance offered is billing, not usage context, so an agent gets no routing help.

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, non-destructive and openWorld, so the safety profile is covered. The description adds something the annotations do not: a pricing/allowance model ('free within the daily allowance, then $0.001 USDC per call via x402'), which is real operational context for a caller deciding whether to batch requests.

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 first, cost second; nothing is wasted and no sentence is redundant with 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?

With an output schema present, return-value detail is not required, and the single parameter is fully covered by the schema. It is close to complete for a read-only lookup; the only gap is that it doesn't clarify whether the response is a flat list of districts or nested children, but the output schema presumably settles that.

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 sole parameter is documented as 'ONS region code', so the schema carries the burden. The description only implies the code is a region code via the phrase 'in an English region'; it adds no format or enumeration detail beyond the schema.

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

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

The description names a specific resource ('the local authority districts in an English region'), which lets an agent distinguish it from neighbouring geography siblings like local-authority, county and ward. It is a noun phrase rather than a verb-led statement, so it never explicitly says what operation is performed, but the resource semantics are 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. The description does not state that the code argument should be an ONS region code (not a district or county code) nor point to any alternative tool such as uk-geography__local-authority when a district code is already known.

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/non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema context: the free daily allowance and the $0.001 USDC x402 pricing after that, which matters for an agent deciding whether to call it. It omits result limits and ranking 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 sentences, zero filler, purpose front-loaded ahead of the pricing note. Nothing here is redundant with the title.

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

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

An output schema exists, so return values need no explanation. Purpose, covered entity types, and cost are all present; for a simple two-parameter read-only search this is complete enough to call correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'ward (default)' enumeration for type. The description restates the same type list in prose and adds nothing about matching syntax or partial-name behavior beyond what the schema says.

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?

Clear verb+resource: 'Search ... names for their ONS codes', and it enumerates the six geography types covered. It implicitly complements the type-specific siblings (uk-geography__ward, uk-geography__county, etc.), but never names or contrasts them explicitly, so sibling differentiation is left to 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?

The description gives cost context (free allowance, then paid) but says nothing about when to use this search vs. the per-type lookup tools, nor about partial-match expectations. Usage is implied by 'search ... names' rather than stated as 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds real value beyond them by disclosing the cost model: free within a daily allowance, then $0.001 USDC per call via x402. It does not mention authentication or rate-limit specifics, but for a read-only lookup the cost disclosure is the meaningful additional trait.

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 returned fields front-loaded and the pricing note second. The first sentence is a fragment lacking an explicit verb, but no words are wasted.

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

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

An output schema exists, so the description need not explain return values, and annotations carry the safety profile. It still omits how to source a valid ward code and any routing to the sibling that resolves codes, which an agent would need to use this tool end-to-end. Adequate but with a clear 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% and there is a single required parameter ('code', documented as an ONS ward code), so the schema does the heavy lifting. The description adds nothing about the identifier format or where to obtain it, 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 names the resource (a ward) and enumerates exactly what is returned: local authority, county/unitary, region, country and Westminster constituency. That makes the tool's job clear even without a verb. It does not explicitly differentiate itself from siblings like uk-geography__local-authority or uk-geography__county, which are the same shape applied to other geography levels.

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 alternatives, nor on prerequisites such as needing a valid ONS ward code (which would come from uk-geography__search). The only directional information is commercial (pricing), not usage-oriented.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive behavior, so safety is covered. The description adds genuinely new behavioral context: the cost model ('free within the daily allowance, then $0.002 USDC per call via x402'), which an agent needs to reason about budget-limited invocation. It does not mention failure behavior for unmatched postcodes.

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: the returned data leads, and pricing follows. No wasted words, and nothing important is buried.

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 description adequately frames the lookup. The one gap is that all three parameters are optional yet the description/schema do not state that at least a postcode or a lat+lng pair must be supplied.

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 lat, lng and postcode, including the 'or give lat and lng' alternative. The description adds no format or constraint detail beyond what the schema provides, so it sits at the baseline of 3.

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

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

States a specific resource enumerating exactly what is returned (region, district, planning authority, ward, parish, built-up area plus ONS codes) for a postcode or point. This implicitly differentiates it from the per-area siblings (uk-planning__region, uk-planning__ward, uk-planning__parish), but no sibling is named explicitly, 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?

Usage is implied by 'for a postcode or point' – an agent can infer this is the point-to-all-admin-areas resolver – and the pricing sentence gives cost context for deciding to call it. However, there is no explicit when-to-use versus the individual uk-planning/uk-geography area tools, and no stated alternative or exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-schema context: the pricing model ('free within the daily allowance, then $0.002 USDC per call via x402'). That cost/rate-limit disclosure is real behavioral value.

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

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

Three short sentences, front-loaded with the core purpose before input modes and pricing. Nearly every clause earns its place, with only the pricing sentence being slightly tangential to the classification itself.

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

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

With an output schema present, return values need no explanation, and annotations carry the safety profile. The description covers purpose, input modes, and cost, leaving little an agent would need. It could be marginally stronger by hinting at when this constraint is relevant.

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 fully documents lat, lng, geometry, postcode, and include_ended. The description's 'postcode or lat/lng' merely restates the schema's own alternation, adding no syntax or format detail beyond it. 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 ('Agricultural land classification grade') and scope ('at a point'), which is clear enough to distinguish it from sibling planning tools that each cover a different designation/dataset. It does not explicitly name a sibling alternative, so it falls just short of a 5.

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

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

'By UK postcode or lat/lng' tells the agent the accepted input modes but gives no guidance on when to use this tool versus other planning-constraint siblings (green-belt, flood-zone, etc.). Usage is implied rather than stated.

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

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

Annotations already declare the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description is not burdened with that. It adds genuine context beyond annotations: the pricing model ('free within the daily allowance, then $0.002 USDC per call via x402'). This is a meaningful operational trait an 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 tightly written sentences with the purpose front-loaded, followed by input modes and cost. Every clause earns its place; only the verb is left slightly implicit.

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. The description supplies the resource scope, query modes, and pricing, which is sufficient for a point-query tool. It stops just short of explaining the include_ended/geometry behavioral nuances, but those are covered in the schema.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description only restates the input modes ('postcode or lat/lng'), which the schema already conveys via the postcode and lat/lng descriptions, adding no new syntax or format detail. 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 ('air quality management areas covering a point'), which clearly distinguishes it from sibling designation tools like uk-planning__green-belt or uk-planning__flood-zone. The verb is implicit ('covering a point') rather than explicit, and no sibling is named directly, 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?

'By UK postcode or lat/lng' communicates the two supported query modes, which is useful implied guidance. However, there is no explicit when-to-use, when-not-to-use, or comparison against alternative uk-planning tools, so it stays at 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral trait not in the structured fields: the pricing/rate-limit model (free within the daily allowance, then $0.002 USDC per call via x402). Return format is left to 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?

Three short, front-loaded sentences. The subject leads, followed by input options and then cost, with 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?

For a simple point-in-polygon lookup with an output schema and full annotation coverage, the description plus structured fields cover what an agent needs to invoke it. The only soft spot is the absence of any routing guidance relative to the large family of sibling constraint 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%, so all five parameters including geometry and include_ended are already documented in the schema. The description's restatement that postcode or lat/lng may be supplied adds nothing beyond what the schema states, and it never mentions geometry or include_ended, 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 the specific resource ('ancient woodland') and the query type ('covering a point'), which is enough to distinguish it by subject from designation siblings like green-belt or sssi. It does not name any sibling or explain how it relates to the broader uk-planning__designations tool, 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?

The description tells the agent which inputs are accepted ('By UK postcode or lat/lng') but gives no guidance on when to choose this tool over the many other uk-planning constraint tools, nor any when-not conditions. This is input syntax, 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 new behavioral context the annotations cannot carry: the free daily allowance and the $0.002 USDC x402 payment model, which directly affects how an agent should call it. It does not describe return payload shape, but an output schema exists, so that omission is acceptable.

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

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

Three tight sentences: what the dataset means, how to address it, what it costs. The domain clarification is front-loaded and no sentence is 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 rich annotations, a 100%-covered 5-parameter schema, and an output schema, the description's remaining burden is light, and it covers purpose, addressing, and cost. It could have noted behaviour when no Article 4 direction applies to the point, which is the main practical uncertainty for a spatial lookup.

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 five parameters (lat, lng, geometry, postcode, include_ended) are already documented in the schema. The description's 'By UK postcode or lat/lng' merely restates the two input modes and adds no format or constraint detail beyond the schema, so baseline 3 is correct.

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

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

The description names the specific dataset (Article 4 directions), the spatial scope ('covering a point'), and explains the domain meaning (permitted development rights removed, so more work needs planning permission). That is far more than the title restated. It stops short of 5 because it does not differentiate itself from potentially overlapping siblings such as uk-property__planning-constraints or uk-planning__designations.

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?

'By UK postcode or lat/lng' tells the agent how to address the query and the pricing line hints at cost-aware usage, but there is no explicit when-to-use statement, no exclusions, and no sibling alternative named. Usage is implied by the Article 4 definition rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description adds genuinely useful behavioural context: a free daily allowance followed by $0.002 USDC per call via x402. That cost/payment model is not derivable from annotations or schema. It does not mention rate ceilings or the boundary cap on geometry, 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?

Three short sentences, front-loaded with the resource and coverage semantics, then input modes, then cost. No filler and nothing 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?

With an output schema present the description need not describe return values, and annotations cover safety. Purpose, input modes and the payment model are all present, leaving only minor gaps such as geometry capping behaviour and the point-only scope.

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

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

Schema description coverage is 100%, so the schema already documents lat, lng, postcode, geometry and include_ended, making 3 the baseline. The description mirrors the postcode-or-lat/lng choice but adds nothing about the geometry or include_ended flags beyond what the schema states.

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

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

The description states a specific resource ('Registered historic battlefields') and its spatial semantics ('covering a point'), which uniquely separates it from the other uk-planning designation tools such as green-belt, sssi or scheduled-monument. An agent can tell exactly what this returns without opening the schema.

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

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

It tells the agent how to invoke the tool ('By UK postcode or lat/lng') and that pricing applies after a free allowance, but never states when to prefer this dataset over neighbouring designation tools or what prerequisites exist. Usage is implied by the resource name rather than explicitly 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 cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower. The description adds genuinely non-structured behavior: free within the daily allowance, then $0.002 USDC per call via x402, plus a capped-geometry caveat. It does not detail error or return behavior, but the pricing/quota context 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?

Three short sentences, front-loaded with the resource identity, then input modes, then pricing. No filler; every sentence 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 and annotations covering the safety profile, the description need not explain return values. It supplies input modes and cost behavior, leaving only explicit sibling 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 each of the 5 params is already documented. The description only restates the postcode-or-latlng input choice, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource: returns the ONS built-up area (town/city) containing a point. This is distinct from the many sibling constraint datasets (green-belt, flood-zone, etc.), but the description never explicitly contrasts itself with them, so an agent relies on the name 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?

It says how to supply the point ('by UK postcode or lat/lng') and discloses the pricing threshold, which is real usage context. However there is no explicit when-to-use-vs-alternatives guidance against the sibling designation tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the pricing model (free within the daily allowance, then $0.002 USDC per call via x402) and the meaning of the result. Return specifics are left to the output schema, which is reasonable.

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

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

Three tight sentences: what it returns, how to invoke it, and the cost model. The core purpose is front-loaded and 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?

With an output schema handling return values and annotations covering the safety profile, the description needs only to state purpose, inputs, and cost — all of which it does. Nothing an agent requires to call it correctly is missing.

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

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

Schema description coverage is 100%, so all five parameters (lat, lng, postcode, geometry, include_ended) are already documented in the schema. The description only reaffirms that a postcode or lat/lng pair is expected. Baseline 3 applies when the schema carries the 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 test ('whether a point is inside a conservation area') and parenthetically explains the domain consequence (extra planning controls on demolition, trees, alterations). This clearly distinguishes it from sibling designations such as green-belt, listed-building, or sssi 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?

It states the two accepted input methods ('By UK postcode or lat/lng'), which is useful invocation guidance, but gives no when-to-use/when-not conditions and names no alternative among the many uk-planning designation siblings. Usage is implied by the self-describing name rather than made explicit.

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

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

Annotations already cover readOnly, idempotent, open-world, and non-destructive traits, so the bar is lower. The description adds genuinely new operational context: a free daily allowance followed by $0.0005 USDC per call via x402, which is exactly the kind of cost/rate information annotations cannot 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 tight sentences with the resource scope front-loaded and the pricing caveat second. No filler; each clause carries information.

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

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

An output schema exists, so return values need not be described, and the description still previews the returned fields. Scope, filter, and cost model are covered; the only gap is explicit routing relative to the many per-dataset siblings.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'q' with an example. The description's 'optional text filter' restates this without adding format or matching semantics (e.g. substring vs exact), 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 (every planning.data.gov.uk dataset) and enumerates the fields returned (name, typology, entity count, licence), making clear it is a catalog/index tool. It distinguishes itself reasonably from the per-dataset siblings (e.g. uk-planning__ancient-woodland) by scope, but never explicitly frames itself as the discovery entry point 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?

The scope word 'Every ... dataset' implies this is the enumeration/discovery tool, and the mention of an 'optional text filter' hints at narrowing large result sets. However, there is no explicit when-to-use versus the per-dataset siblings or uk-planning__entity, and no exclusion 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 adds genuinely non-obvious operational context absent from annotations: a free-sample-per-day quota followed by $0.005 USDC per call via x402. It does not, however, discuss point-resolution behavior (lat/lng vs postcode) or rate specifics 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?

Purpose is front-loaded in the opening clause, with the designation list and the pricing caveat following. The 20-item enumeration is long but earns its place by defining coverage scope; still, it is dense and slightly unwieldy as a single run-on sentence.

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

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

For a wide aggregate tool with an output schema present, the description adequately covers scope (which designations), aggregation benefit, and cost model, so the agent needn't see return formats. Minor gaps remain around point-vs-postcode resolution and how sparse or verbose results may be, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents lat, lng, postcode, and include_ended. The description adds no parameter-level guidance (e.g., precedence between postcode and lat/lng, or that include_ended surfaces revoked designations). Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Every published planning and environmental designation at a point in one call') and enumerates the exact designation types covered. This cleanly distinguishes it from the ~25 single-designation siblings like conservation-area, listed-building, and flood-zone, which return one type each. An agent can tell this is the aggregate 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 phrase 'in one call' clearly signals the use case: fetch the full designation set for a point rather than making many individual calls. However, it never explicitly tells the agent when NOT to use it or names the single-type siblings as the alternative for narrower queries. Context is clear but exclusions are absent.

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 open-world, so the safety profile is covered. The description adds genuinely new context: the metered pricing model (free within daily allowance, then $0.001 USDC per call via x402) and a note that WKT is optional and capped.

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

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

Two tight sentences, front-loaded with the core retrieval semantics and followed by pricing. No wasted words and 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?

An output schema exists so return formatting need not be explained, and the description covers identity, the optional geometry flag, and the cost model. It is nearly complete, missing only explicit routing guidance against the dataset-specific siblings.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'capped' WKT note. The description restates the optional-WKT behavior without adding syntax or format detail, so the baseline 3 is appropriate.

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

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

States a specific verb (retrieve) and resource (one planning.data.gov.uk entity from any dataset) keyed by entity number, which is clear and distinguishable from the dataset-specific siblings. It stops short of explicitly contrasting itself with those siblings (e.g. spatial queries by area), so it falls just short of a 5.

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

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

The description implies you need an entity number but gives no explicit when-to-use, when-not-to-use, or alternative routing against the many dataset-specific uk-planning__* siblings. The only usage-adjacent content is pricing, which does not help an agent select the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new operational context: the free daily allowance and the per-call x402 payment mechanism, which an agent needs in order to anticipate cost.

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 subject and scope, then pricing. No padding, though the '(2/3)' shorthand and the 'WKT (capped)' detail sit slightly at odds with a description this terse.

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

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

With an output schema present, return values need no explanation, and annotations carry the safety profile. The description covers input modes and cost; it could still clarify what distinguishes Flood Zone 2/3 results or the meaning of the geometry cap, but nothing critical to invocation is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented. The description reinforces the two input modes ('By UK postcode or lat/lng') but adds no syntax or format detail beyond what the schema provides. 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 ('Planning flood zones (2/3) at a point') and clarifies the domain ('as published for planning decisions'), which usefully separates it from the uk-flood__* siblings that concern warnings and stations rather than planning zones. It stops short of naming an alternative directly, so the differentiation is inferential.

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

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

The description implies usage (point-based flood zone lookup for planning) and notes billing context ('Free within the daily allowance, then $0.002 USDC per call via x402'), but gives no explicit when-to-use vs when-not guidance and never points at a sibling such as uk-property__planning-constraints for bundled constraint checks.

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 non-destructive, so safety is covered. The description adds the pricing behavior (free within daily allowance, then $0.002 USDC via x402), which is genuinely useful operational context not in annotations, but says nothing about return format or the 'capped' WKT 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?

Three tight sentences: purpose, inputs, then pricing. Front-loaded and zero waste.

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 need no explaining, and annotations cover the safety profile. The description adequately covers purpose, input modes, and billing; the only minor gap is that geometry's 'capped' boundary behaviour is left entirely to the schema.

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

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

Schema coverage is 100% with descriptions for all five params, so the schema carries the semantics. The description only restates the postcode vs lat/lng choice, adding no syntax or format detail beyond the schema (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 precise query ('whether a point is in the green belt') with the resource clearly named. Among dozens of uk-planning__ constraint siblings, the name and description distinguish this as the green-belt designation specifically.

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

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

Implies usage by stating the input options (postcode or lat/lng) and the pricing model, but gives no guidance on when to prefer this over related designation tools like conservation-area or national-park, nor how it composes with the generic designations tool.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuinely new behavioral context not in structured fields: the pricing model (free within the daily allowance, then $0.002 USDC per call via x402), which is important operational information 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?

Three short, front-loaded sentences with no wasted words: resource first, input method second, cost third. Well-sized and easy to scan.

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

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

With an output schema present, the description need not explain return values, and annotations cover the safety profile. Purpose, location input, and cost are all covered, leaving only minor gaps around sibling routing and parameter specifics.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description only restates the postcode/lat-lng choice and says nothing about geometry or include_ended, adding no meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific resource ('Historic England Heritage at Risk entries') and scope ('covering a point'), which is clearly distinct from sibling planning datasets like listed-building or scheduled-monument. It lacks an explicit verb and does not name any sibling for differentiation, 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?

'By UK postcode or lat/lng' clarifies the accepted location inputs, which implies how to invoke it, but there is no when-to-use/when-not guidance or routing against the many sibling planning constraint tools. Usage is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context beyond annotations: the free daily allowance and the $0.002 USDC x402 pay-per-call pricing, which is exactly the kind of rate/cost behavior an agent should know before calling.

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

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

Three short sentences with no filler; the resource and scope lead, followed by input modes and pricing. Efficient and front-loaded, though the pricing detail could arguably be positioned after input guidance.

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 described, and annotations carry the safety profile. The description covers resource, input modes, and pricing, which is complete enough for correct invocation; only cross-tool routing context is absent.

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 five parameters are already documented in the schema, including the postcode-vs-lat/lng alternative. The description's "By UK postcode or lat/lng" largely restates that, adding no syntax or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific resource (Heritage coasts) and scope (covering a point), which is enough for an agent to know it returns heritage-coast designations intersecting a location. It does not explicitly differentiate itself from the many sibling designation tools (green-belt, sssi, etc.), but the resource name is inherently distinct.

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?

"By UK postcode or lat/lng" tells the agent which input mode to use, which is useful implied guidance. However, there is no when-to-use vs. when-not-to-use framing and no mention of how it relates to sibling designation lookups, leaving usage largely to inference.

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

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

Annotations already cover the read-only/idempotent safety profile, but the description adds real behavioral context: pricing ('free within the daily allowance, then $0.002 USDC per call via x402') and the fact that the geometry boundary is capped. These are traits an agent cannot get from the annotations or schema.

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

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

Three short sentences, front-loaded with the core purpose, then inputs, then cost. No filler and every sentence carries distinct information.

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

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

With an output schema present, return-value detail is unnecessary, and the description covers purpose, inputs and cost. It is essentially complete for a point-query geo tool; only the routing against sibling designation tools is left implicit.

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 five parameters are already documented and the baseline is 3. The description only restates the lat/lng vs postcode input choice and does not add syntax or format meaning beyond the schema.

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

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

States a specific verb and resource ('Listed building outlines covering a point') and names the returned content (listing grade, Historic England list entry). It is clearly distinguishable from similarly-shaped siblings like conservation-area or scheduled-monument, though it does not explicitly route the agent among them.

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 'By UK postcode or lat/lng' implies the point-based query pattern, so usage is implied but never spelled out. There is no explicit when-to-use/when-not, and alternatives such as the other uk-planning designation tools are not mentioned.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious operational context the annotations cannot convey: the point lookup is free within a daily allowance and then costs $0.002 USDC via x402, which materially affects how an agent should batch or ration calls. It stops short of describing boundary-capping behavior for the geometry flag.

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 filler: output identity first, accepted inputs second, cost model last. Every clause earns its place and nothing is buried.

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 narration, and the annotations carry the safety profile. What remains is a real gap: no hint of what distinguishes this tool from the parallel geography/planning siblings, which for a directory of 80+ near-duplicate tools is the one thing an agent most needs.

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 one of the 5 parameters is already documented in the schema, and the baseline is 3. The description restates the postcode-or-lat/lng choice that the schema already encodes, adding no new syntax, format or constraint detail beyond it.

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

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

States a specific verb/resource pair — 'the local authority district for a point' — plus the added payload ('with its ONS code'), so the agent knows exactly what comes back. However it never distinguishes itself from near-identical siblings such as uk-geography__local-authority or uk-planning__planning-authority, leaving the agent to guess which one to call.

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 'By UK postcode or lat/lng' does tell the agent which input modes are accepted, which is useful context. But there is no when-to-use guidance and no exclusion or routing against the many overlapping geographic siblings, so selection is left to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a pricing/allowance model ('Free within the daily allowance, then $0.002 USDC per call via x402'), which tells the agent about metering and cost. It stops short of discussing return shape, though an output schema exists.

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

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

Three short sentences, front-loaded with the core purpose, then inputs, then commercial terms. No sentence is wasted, though the phrasing is terse enough that it trades detail 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, the description need not explain return values, and the input schema plus annotations already cover parameters and safety. The only gap is the absence of sibling disambiguation among the many overlapping uk-planning designation 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%, so every parameter is already documented in the schema (lat, lng, postcode, geometry, include_ended). The description only restates the postcode/lat-lng alternative and adds nothing about the non-obvious flags like geometry or include_ended, so baseline 3 applies.

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

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

States a specific resource ('Local nature reserves') and scope ('covering a point'), so the agent knows this is a point-in-polygon lookup. It does not explicitly differentiate from near-identical siblings like national-nature-reserve or sssi, leaving the agent to infer the distinction from the name 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?

The description tells the agent the two accepted input modes ('By UK postcode or lat/lng'), which is implied usage guidance. It offers no when-to-use vs when-not guidance and no routing to alternative designation tools such as national-nature-reserve.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not carry: the pricing/commercial model ('free within the daily allowance, then $0.002 USDC per call via x402'), which matters for agent budgeting.

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

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

Three short sentences, front-loaded with the resource identity, then inputs, then cost. No filler, though the pricing clause is slightly tangential to selection and could have been placed after usage 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?

Output schema exists, so return values need no explanation. For a read-only point lookup, the combination of rich annotations, fully documented schema, clear input modes, and the disclosed pricing model leaves nothing an agent needs 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 each of the five parameters is documented in-schema (lat/lng WGS84, geometry WKT capped, postcode, include_ended). The description only restates the postcode-or-coordinates choice, adding no syntax or format 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 (National Landscapes / former AONBs) and the spatial operation ('covering a point'), which is a clear verb+resource pairing an agent can act on. It does not, however, distinguish itself from close siblings such as uk-planning__national-park, uk-planning__sssi, or uk-planning__green-belt, which share the same point-lookup shape.

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?

'By UK postcode or lat/lng' tells the agent what input modes are accepted, which implicitly defines the lookup context. There is no explicit when-to-use / when-not guidance and no routing to alternative designation tools, so usage is only implied.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new operational context not present in the structured fields: free within a daily allowance, then $0.002 USDC per call via x402, which matters for call budgeting. It stops short of describing pagination or the capped-boundary 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?

Three short, front-loaded sentences with no filler: the resource and spatial semantic come first, input modes second, cost last. Tight and easy to scan, though the pricing sentence is the only substantive addition.

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 description covers the resource, the point-in-polygon semantic, accepted inputs, and cost. The main gap is sibling disambiguation against local-nature-reserve and related designation tools, which an agent choosing among ~75 tools would benefit from.

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