Look up detailed information for any NHTSA complaint by entering its ODI number to identify vehicle defects, recalls, and safety issues.
Get a specific complaint by its ODI number. ODI numbers are in complaint search results (e.g. 11184030).
| Name | Required | Description | Default |
|---|---|---|---|
| odi_number | Yes | ODI complaint number (e.g. 11184030) |
Changes observed during successful MCP inspections.
v2026.4.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds only that ODI numbers are in search results—this is parameter sourcing, not behavior. It doesn't disclose response format, error handling, or any side effects beyond 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?
Two sentences with no filler. The purpose is front-loaded, and the second sentence clarifies parameter sourcing with an example. Every word 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?
For a simple single-parameter detail fetch with annotations covering safety, the description is nearly complete. It lacks an explicit note on the return value, but 'Get a specific complaint' implies the complaint details. Minor gap for error conditions, but acceptable.
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 includes an example. The description adds context that ODI numbers are found in search results, which helps the agent locate the parameter value, going beyond the schema description.
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 gets a specific complaint by ODI number, using a specific verb and resource. It doesn't explicitly contrast with sibling tools like nhtsa_complaints, but the 'specific' qualifier implies distinction.
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 notes that ODI numbers come from complaint search results, which implies usage when you already have an ODI number. However, it doesn't explicitly state when to prefer this over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.