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

There are no annotations, so the description carries the burden of behavioral disclosure. It does a strong job: explains the output includes reworded definitions compiled from open/public sources with source and license, notes unknown codes return not_found, and warns that severity is not guaranteed. It also discloses cost of $0.006 USDC per call; the main omissions are authentication and rate limits, which are acceptable for this lightweight lookup style.

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 not short, but it is visibly organized around the core lookup purpose, parameter semantics, when-to-use, caveats, and cost. Although it is a bit longer than strictly necessary, each sentence does convey a distinct piece of actionable information. Front-loading 'Look up a vehicle fault code' keeps the primary purpose immediately visible.

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 parameter schema and the absence of an output schema, the description provides enough context to invoke the tool correctly: it lists the key code, covers make-specific behavior, mentions unknown-code handling, and warns about source provenance and severity. It does not spell out the exact response shape, but the row-based wording with source/issue/location is enough for fundamental use. Minor omissions such as response format or error cases are secondary.

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%, so the baseline is 3, but the description adds genuine semantic value beyond the schema. The 'code' parameter is reinforced with the 'exactly as reported' framing, and the optional 'make' parameter gains important context: the same code can have different meanings across brands and that the generic SAE meaning is the default. This is more than merely restating the schema field descriptions.

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 a specific verb and scope: 'Look up a vehicle fault code (OBD-II diagnostic trouble code)' with concrete examples like P0301, B1318 and U0100. It clearly tells the agent this tool returns definitions and identifies the resource, and distinguishes it from sibling vehicle tools by focusing on DTC lookup. The behavior of never guessing a meaning further clarifies what this tool uniquely does.

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 gives explicit when-to-use guidance: 'Use this when a scan tool reported a code...' and explains when to pass the optional 'make' parameter versus the generic SAE meaning. It does not explicitly compare against siblings like vehicle_recalls or vin_decode, but the context 'when a scan tool reported a code' makes the use case clear enough for an agent to select this tool appropriately.

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