Skip to main content
Glama

VIN decoder

wenmar_vin
Read-only

Decode vehicle identification numbers into year, make, model, trim, generation, engine (with horsepower, valve train and fuel injection), drivetrain, brakes, battery and charging, safety equipment, lights and keyless ignition, the manufacturer's notes, every NHTSA attribute with its source, and the matching catalog entry. year_conclusive=false means the VIN leaves the model year open: check the vehicle's label. 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. action=overview takes vin (and optionally year) and gives everything held for the model year the VIN decodes to in one answer: the decode in brief, a count of the recall campaigns that may apply to that year, make and model with the three newest, and links. A block with no data is null. action=fuel, specs, fluids or tires takes vin (and optionally year) and gives that data for the model year the VIN decodes to: fuel consumption ratings from EPA and Natural Resources Canada (optional country, us or ca), specifications from EPA's files, fluids (the engine oil grade EPA records, and records a person read from the maker's own documents, each with its source and the day it was checked), or the original-equipment tire fitments. When the decode settles the engine, fuel, specs and fluids hold only what is for that engine and engine_settled is true; tires are never narrowed.

Input Schema

NameRequiredDescriptionDefault
vinNoA 17-character VIN. Spaces and dashes are ignored.
vinsNo
yearNoModel year to use instead of the one worked out from the VIN.
actionYes
countryNoFor action=fuel: us for EPA's ratings, ca for Natural Resources Canada's. Leave out for both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "decode",
      -  "batch"
      -]New value: +[
      +  "decode",
      +  "batch",
      +  "overview",
      +  "fuel",
      +  "specs",
      +  "fluids",
      +  "tires"
      +]
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "For action=fuel: us for EPA's ratings, ca for Natural Resources Canada's. Leave out for both.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the readOnlyHint by disclosing non-obvious behavior: a bad check digit returns valid=false with a warning rather than an error, year_conclusive=false means the model year is open, empty blocks are null, and engine_settled narrows fuel/specs/fluids but never tires. Batch order and the 50-item cap are also stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Nearly every sentence carries real information, but it is delivered as one dense paragraph with run-on clauses rather than per-action structure, making it harder to scan. Front-loading the decode output list first is reasonable, yet the action semantics buried mid-paragraph would read better separated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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-value burden and does: it names the decoded fields, the NHTSA attribute set with sources, the overview bundle contents, and the null convention. Nothing an agent needs to invoke or interpret a call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 60%, and the description compensates: `year` is an override for the decoded year, `vins` is capped at 50 with in-order results, `country` accepts us or ca and defaults to both. It also binds each parameter to its action, which the schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (decode VINs) and enumerates the action modes (decode, batch, overview, fuel, specs, fluids, tires) with what each returns. An agent can distinguish this from the sibling recall/bulletin tools because it names NHTSA attributes, catalog entry, EPA/NC data and tire fitments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear per-action routing: use batch for up to 50 VINs, overview for the year-level bundle including recall counts, and the per-domain actions for narrow data. It does not explicitly say when to prefer a sibling such as wenmar_recalls over action=overview, which is the one likely point of confusion.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources