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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds substantial non-structured context: UK-only scope, a 5-credit cost, the three-valued constraint semantics (in_zone vs checked_false vs not_checked, with the explicit warning that unchecked means UNASSESSED), the ground-plane nature of plot coverage (not a density, not a developable area), and why covenants read not_available (partial title-to-parcel link). This is exactly the behavioral context annotations cannot carry.

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?

Front-loaded with what the tool returns, then layered warnings, all of which are substantive rather than filler. It is on the long side for a lookup tool, but every paragraph (constraint tri-state, plot-coverage caveat, covenant gap, credit cost, address workflow) prevents a concrete misuse, so the length is largely earned.

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 spelled out, yet the description still orients the agent on interpretation pitfalls (unchecked ≠ clear; plot coverage ≠ density; covenants not_available). Combined with the credit cost, UK-only scope and the UPRN workflow, an agent has everything required to call and correctly interpret this tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it names all four handles (parcel_id, inspire_id, title_number, uprn) and frames them as interchangeable 'whichever handle you have', and reiterates that the operation is keyed on a UPRN. It does not, however, distinguish the ID formats or explain that the parameters are optional/alternatives in the mutual-exclusion sense, leaving a little inference to the agent.

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 exact resource and enumerates what it returns (INSPIRE id, title number, OS id, area, land use, proprietor, units, plot utilisation, constraint flags), which lets an agent distinguish it from nearby tools like plot_utilisation or ownership_by_title. It also explicitly contrasts itself with land_assembly ('use land_assembly instead when you want the neighbours'). No ambiguity about what this tool fetches.

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

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

Gives explicit routing: use land_assembly for neighbours, and use address_autocomplete (free) then address_resolve to obtain a UPRN when you only have an address. It states the keying constraint directly ('Keyed on a UPRN, not an address'), which is exactly the when/when-not guidance an agent needs before invoking.

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