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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is covered. The description adds real context beyond that: it is offline, it does not perform a vehicle lookup, and no account is needed — the last point being auth information the annotations do not 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?

Three short sentences with no filler; the derived output is front-loaded, followed by the boundary condition and the auth note. Nothing repeats the schema or annotations unnecessarily.

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-only lookup with an output schema, the description need not explain return format, and it correctly focuses on scope, offline behavior, and the sibling alternative. It is essentially complete, though it could note edge cases (non-UK or malformed plates) that the minLength 2/maxLength 16 schema hints at.

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?

There is only one parameter and schema coverage is 100%, with the schema already documenting that the plate accepts any spacing or case. The description clarifies what the plate value is used to derive (format/age identifier/issue window) but adds no input syntax or format constraint 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?

The description states precisely what the tool computes — the issue window (format, age identifier, first/last month) from the plate alone — rather than the generic 'decode a plate' of the title. It also explicitly carves out a sibling, saying it does not look the car up and to use free_check for that, so an agent can separate it from free_check/full_report without reading schemas.

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 names the alternative (free_check) and the condition that selects it (you want the car looked up), which is genuine routing guidance. It stops short of stating broader when-to-use context (e.g., what task the issue-date window serves) or other exclusions, so it is clear but not exhaustive.

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