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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered elsewhere. The description adds real value by disclosing that the tool returns a verdict plus the missing prerequisites rather than raw fields, i.e. it composes the reasoning. It stops short of saying where the underlying data comes from (a separate data_sources tool exists), how fresh it is, or whether a negative verdict is ever ambiguous.

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, and the substantive scope (tax, MOT, what's missing) is front-loaded before the routing advice. Each clause carries information an agent needs.

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

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

For a read-only single-parameter check with no output schema, the description supplies enough: the question it answers and the components of the answer. The remaining gap is scope coverage — UK road legality also turns on insurance, which is not mentioned, so an agent cannot tell whether insurance is factored in or ignored.

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 meaningful input, and the schema documents vrm at 100% coverage with a concrete example ('CV23 KWR'). The description's phrase 'given a UK vehicle registration' merely restates that, adding no syntax or edge-case detail (e.g. spacing, case, non-UK plates). Baseline 3 for a fully covered single parameter.

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 ('decide whether it is legal to drive now') and enumerates the constituent checks it performs: tax status, MOT validity, and what is missing. It clearly distinguishes itself from vehicle_lookup. It does not, however, differentiate from the near-identically purposed sibling road_legal_check, which an agent will notice in the tool 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?

Gives explicit trigger phrasings ('is this car road legal / can I drive it / can I tax it') and explicitly names the alternative to avoid ('rather than calling vehicle_lookup and reasoning over the fields yourself'). That is both a when and a when-not, plus the rationale for preferring this tool.

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