Free VIN decoder and vehicle catalog from NHTSA vPIC data. Read-only, no key.
Scored across 2 tools
wenmar_vehicles performs attribute-based catalog lookups (years, makes, models, engines, search), while wenmar_vin handles VIN decoding and batch decoding. Their purposes are clearly distinct with no overlap in triggering intent.
Both tools follow a consistent prefix_noun pattern (wenmar_vehicles, wenmar_vin). The only minor variation is plural vs. singular noun, but the convention is still predictable and readable.
Two tools is slightly below the typical 3-15 range, but each is a multi-action tool that compactly covers the domain. The surface is well-scoped rather than bloated or trivially thin.
For a read-only vehicle data service, the tools cover the full lookup lifecycle: year/make/model/submodel/engine navigation, free-text search, entry retrieval by id, and VIN decode (single and batch). No obvious operation is missing.
Look up vehicles by year, make, model, submodel and engine. Actions: years; makes (optional year); models (make, optional year); submodels (make, model, year); engines (make, model, year, optional submodel); search (query, such as "2019 civic si" or "chevy 1500"); entry (id, such as "2019_honda_civic_si"). make and model take a name, an alias or an id. term narrows a list to names starting with it. scope is light (cars, MPVs and trucks; the default), all, or a vPIC vehicle type id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| make | No | ||
| term | No | ||
| year | No | ||
| limit | No | ||
| model | No | ||
| query | No | ||
| scope | No | ||
| action | Yes | ||
| submodel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds per-action input semantics but says nothing about result shape, pagination, `limit` behavior, or rate limits, which are the behavioral details an agent would still need.
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?
A single dense paragraph that front-loads the resource and then walks the actions in dependency order; the semicolon-separated action list is readable and nearly every clause carries information. Slightly compressed, but no filler sentences.
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 7-action, 10-parameter dispatcher with no output schema, the description covers action selection and almost all parameter semantics, which is enough to call the tool correctly. The unexplained `limit` and the absence of any sibling-boundary note are the remaining gaps.
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?
With 0% schema description coverage across 10 parameters, the description carries the full burden and largely delivers: it maps parameters per action, explains `make`/`model` accept a name, alias, or id, defines `term` as a prefix filter, enumerates `scope` values with the default, and gives concrete `query` and `id` examples. It leaves `limit` unexplained, so it is strong but not complete.
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 vehicles by year, make, model, submodel and engine') and enumerates the seven actions, which tells an agent exactly what the tool is for. It does not, however, distinguish itself from the sibling wenmar_vin, leaving the agent to infer the boundary between catalog lookup and VIN decoding.
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?
Each action is paired with the parameters it requires or accepts (e.g. engines needs make/model/year, optional submodel), which effectively guides action selection. What's missing is explicit routing guidance versus wenmar_vin and any statement of when a given action is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode vehicle identification numbers into year, make, model, trim, engine, drivetrain, safety equipment and the matching catalog entry. action=decode takes vin (and optionally year to override the model year). action=batch takes vins, at most 50, and returns one result per VIN in order. A wrong check digit is not an error: the result has valid=false and a warning.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | A 17-character VIN. Spaces and dashes are ignored. | |
| vins | No | ||
| year | No | Model year to use instead of the one worked out from the VIN. | |
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: batch ordering guarantees, the 50-VIN ceiling, and the non-obvious fact that a bad check digit yields valid=false plus a warning rather than an error.
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?
Four sentences, all front-loaded: purpose first, then per-action parameter rules, then the error-semantics edge case. No sentence is redundant with another and none pads.
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?
With no output schema, the description carries the return-shape burden and does so by listing decoded attributes and the valid=false warning contract. The only gap is the absence of any statement about how this relates to the sibling wenmar_vehicles 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 coverage is only 50% (vins and action are undescribed in the schema), yet the description compensates by explaining what vins holds, the 50-item cap, and the decode/batch split. The year override is also clarified as a model-year substitute, adding meaning beyond the schema's phrasing.
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?
Names a specific verb (Decode) and resource (vehicle identification numbers) and enumerates the decoded fields, so the agent knows exactly what comes back. It does not, however, distinguish itself from the sibling wenmar_vehicles tool, leaving that comparison to inference.
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?
Explicitly separates action=decode (single VIN, optional year override) from action=batch (up to 50 VINs, ordered results), which tells the agent which mode to pick for a given input. There is no guidance on when to reach for this tool instead of wenmar_vehicles.
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.
wenmar_vehicleswenmar_vinDecode any VIN and check open NHTSA safety recalls. Free official US government data, no auth.
NHTSA MCP — wraps the NHTSA vPIC (Vehicle Product Information Catalog) API (free, no auth)
Decodes US VINs and looks up open NHTSA safety recall campaigns for a vehicle.
US vehicle recalls, complaints, EPA figures, VIN decode and trouble codes, with sources.
Add one secure layer between your agents and this server.
