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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive), and the description adds real value beyond them by disclosing that data comes from 'live DVLA records' (freshness) and by listing the returned fields, which matters since there is no output schema. It omits how failures behave (invalid/unknown plate) and any authentication expectations even though the body accepts credential 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 sentences, front-loaded with the action and resource, then the return payload, then the trigger. The long field list is not padding — with no output schema it is the only specification of what comes back, so every item 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?

Because there is no output schema, the description correctly takes on the return-value burden and does so thoroughly. The remaining gap is behavioral edge cases (plate not found, malformed plate) and the credential fields in the nested body, which go unexplained anywhere.

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 there is a single parameter, so the schema already defines vrm and supplies the CV23 KWR example the description repeats. The description adds nothing about the credential/agentCredential/agent_trust_credential body fields, which are untyped and undocumented in both places. Baseline 3 fits.

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 (look up a UK vehicle registration against DVLA) and enumerates exactly what comes back: tax status/due date, MOT status/expiry, make, colour, fuel type, engine size, CO2, emissions, year. That level of specificity lets an agent tell this apart from the many overlapping vehicle_* and road_legal_check siblings without opening a 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?

Gives a clear trigger: 'use this whenever somebody asks whether a vehicle is taxed, has a valid MOT, or wants its details from a registration'. However, it names no alternatives and no exclusions, so an agent still has to guess whether vehicle_check_road_legal, vehicle_check_clean_air or vehicle_check_fleet fits a given request better.

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