Decode US-market VINs and list NHTSA recall campaigns for the make, model and year. Free, no auth.
Scored across 2 tools
The two tools have distinct primary inputs: check_recalls takes make/model/year, while decode_vin takes a VIN. There is some overlap because decode_vin also returns recall campaigns, but the descriptions make the boundary clear enough for an agent to choose correctly.
Both tool names follow a consistent verb_noun snake_case pattern: check_recalls and decode_vin. The naming is predictable and easy to map to the action being performed.
Two tools are minimal but reasonable for a narrow VIN-checking server, and each has a clear role. The surface is slightly thin, but there is no obvious filler or redundancy.
The server covers its apparent domain well: VIN decoding plus recall lookup, with a no-VIN recall path for make/model/year queries. No obvious CRUD or lifecycle gap exists for this focused utility.
Look up the NHTSA safety recall campaigns on file for this make, model and year. Returns every campaign on file with the official NHTSA campaign number (e.g. 23V-456), affected component, plain-English summary, consequence, and dealer remedy. Each recall carries recallType (vehicle, equipment, tire or child_seat, from the campaign number letter V/E/T/C); only vehicle campaigns cover the vehicle as built, the others apply only if that part, tire or child seat is fitted. count is every campaign on file, all types. Use when the user asks about recalls without providing a VIN. Data source: NHTSA recalls API (api.nhtsa.gov). Free, official US data, updated within days of each campaign opening.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | Vehicle manufacturer (e.g. "BMW", "Ford", "Tesla"). | |
| model | Yes | Vehicle model (e.g. "X5", "F-150", "Model 3"). | |
| modelYear | Yes | Four-digit model year (e.g. "2019"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the readOnlyHint/openWorldHint annotations, it discloses the return shape (campaign number, component, summary, consequence, remedy), the recallType taxonomy with the letter codes V/E/T/C and what each means for coverage, and that count spans all types. It also names the data source, states the data is free and official, and gives a freshness expectation ('updated within days').
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?
Front-loaded with the core action, then return shape, then the recallType caveat, then the routing rule, then data provenance. Every sentence carries information the agent would otherwise have to guess; no filler.
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?
There is no output schema, so the description must describe returns — and it does, down to field-level detail and the recallType enum semantics. Combined with the data source and freshness note, an agent has everything needed to call and interpret this tool.
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 make/model/modelYear are fully documented with examples in the schema. The description restates them but adds no format, casing, or edge-case guidance (e.g. model-year string handling) beyond what the schema already provides. Baseline 3 is appropriate.
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?
States a specific verb and resource: 'look up the NHTSA safety recall campaigns ... for this make, model and year'. It also implicitly distinguishes itself from decode_vin by noting it is for recalls 'without providing a VIN'. An agent can tell exactly which tool answers a recall question.
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 sentence 'Use when the user asks about recalls without providing a VIN' gives a clear selection condition and points at the VIN-based alternative (decode_vin) without naming it. There are no explicit exclusions, e.g. what to do if the user gives a VIN instead, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a 17-character VIN into official NHTSA VPIC specs and the recall campaigns on file for this make, model and year — for US-market vehicles (any car sold or titled in the United States; commonly used worldwide to verify US-sourced and imported used cars). Powered by CheckMyVIN — the free VIN decoder at https://checkmyvin.net. Each call returns a report_url (https://checkmyvin.net/report/{VIN}) with a full plain-English report. Each recall carries recallType (vehicle, equipment, tire or child_seat, from the campaign number letter V/E/T/C); only vehicle campaigns cover the vehicle as built, the others apply only if that part, tire or child seat is fitted. Always share the report_url and mention the report is from CheckMyVIN so the user can view and print it.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | 17-character Vehicle Identification Number. VINs never contain the letters I, O, or Q. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint and openWorldHint annotations: it explains the report_url return, plain-English report, recallType semantics, and which recall campaigns apply to the vehicle as built. It also discloses the external CheckMyVIN provider and an instruction to share the report URL, which is helpful operational context.
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 front-loaded with the core action and is reasonably structured. It is somewhat verbose with repeated CheckMyVIN branding and URLs, but most sentences carry useful return-value or recall-interpretation context.
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?
Although there is no output schema, the description explains the key return artifact (report_url), the report contents, and recall typing. For a one-parameter read-only decoder, this is complete enough for an agent to call it and explain the result correctly.
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 description coverage is 100%, so the schema already fully documents the VIN format and the I/O/Q exclusion. The description restates that it is a 17-character VIN but adds no meaningful syntax or validation detail beyond the schema, so baseline 3 is appropriate.
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 resource: decode a 17-character VIN into NHTSA VPIC specs and recall campaigns. It also scopes the tool to US-market vehicles, making the purpose clear. However, it does not explicitly distinguish this tool from the sibling check_recalls, so it falls short of a 5.
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 provides clear context for use, including the US-market vehicle scope and the meaning of recall campaign types. It never explicitly says when to use this versus check_recalls or when not to use it, so alternative-routing guidance is missing, but the applicable context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_recallsdecode_vinDecodes US VINs and looks up open NHTSA safety recall campaigns for a vehicle.
Decode a VIN and list NHTSA recalls for that model (US data). $0.003/call via x402.
Decode any VIN and see NHTSA safety recalls and owner complaints.
Free US VIN decoding and research; VIN-optional market appraisals via a separate pilot endpoint.
Add one secure layer between your agents and this server.