Every NHTSA recall campaign on file for one model year, with severity, park-outside and do-not-drive advisories and the reported completion rate. IMPORTANT: recalls apply to a build range, not to a model year, so this cannot establish whether one specific vehicle is affected — only a VIN check at nhtsa.gov/recalls can.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vehicle id, e.g. 2021_kia_telluride. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses the output content (severity, park-outside and do-not-drive advisories, completion rate) and an important limitation about build ranges. This is especially valuable with no output schema present.
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 two sentences with no filler: the core behavior and output elements are front-loaded, and the crucial caveat is separated and emphasized with IMPORTANT. Every clause 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 single-parameter read-only tool, everything needed for correct invocation is present: what the id represents, what the result includes, and the key interpretation caveat. The absence of an output schema is compensated by listing the returned information.
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 schema already documents the required id with an example, but the description adds meaning by framing the parameter as a model-year-level vehicle identifier and explaining why it cannot be treated as a VIN. That context helps an agent supply the correct id and interpret results.
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 action and resource: returning every NHTSA recall campaign for a model-year vehicle with severity, advisories, and completion rate. It also clarifies the scope by explicitly warning that it is not a per-VIN check, which distinguishes it from sibling tools like decode_vin.
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 makes the intended use clear (model-year-level recall campaigns) and gives an explicit when-not: it cannot determine whether one specific vehicle is affected. It names the alternative path (VIN check at nhtsa.gov/recalls), so an agent can route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
