lookup_vehicle

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It describes the returned data but does not mention side effects (it appears read-only), rate limits, error conditions, or authorization requirements. This is insufficient for a tool with no annotations.

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?

The description is a single sentence that starts with the purpose but then lists many fields in a dense, unstructured manner. While complete, it could be more readable with bullets or shorter sentences. The essential information is present but not optimally organized.

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?

Given the simple tool (one parameter, no output schema, no annotations), the description provides a comprehensive list of return fields. However, it lacks details on error cases (e.g., missing or invalid registration), performance expectations, or what happens if data is unavailable. This is adequate but not thorough.

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 100% for the single parameter 'registration'. The description adds format guidance with examples ('e.g., AB12 CDE or AB12CDE'), which helps the agent format input correctly. This extra detail raises the score above baseline.

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 clearly states the tool's action: 'Look up enriched data for a UK vehicle by registration mark.' It lists specific fields returned, making the purpose unmistakable. Sibling tools are all postcode-related, so this tool is well-differentiated.

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?

The description implies usage for UK vehicle lookups by registration mark. It does not explicitly state when not to use it or provide alternatives, but the context of siblings (postcode tools) and the single parameter make usage straightforward. An exclusion for non-UK vehicles is implied but not stated.

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