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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. Beyond those, the description usefully discloses that it aggregates multiple independent registries and that some results are only returned 'when available' – a caveat that tells the agent to expect partial responses. It omits cost, rate limits, and not-found 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?

A single front-loaded clause with the trigger scenario first and the returned data categories after. Every word carries information and nothing is repeated.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description covers the scenario and the data categories, leaving only edge cases such as unknown plates or jurisdiction limits 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?

The single parameter is fully documented in the schema ('Danish number plate or VIN' at 100% coverage), so the schema carries the parameter burden. The description adds no format, normalization, or example detail beyond that, 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 enumerates exactly what it returns: recalls, owner tax, insurer, inspection (syn) history, liens, and valuations. An agent knows precisely what data comes back. It does not differentiate itself from the sibling 'vehicle_lookup', 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?

'Before buying a used car' gives a clear situational context for use, which is more than most descriptions offer. However, it names no alternatives and no when-not conditions, so an agent has no explicit routing rule between this and 'vehicle_lookup'.

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