Free VIN decoder, recalls, service bulletins, trouble codes and labour times. No key.
Scored across 7 tools
The vehicles vs vin tools duplicate five actions (overview, fuel, specs, fluids, tires) on the same underlying data, split only by id-vs-VIN input, which invites misselection when an agent holds a VIN but could also resolve an id. wenmar_codes/vehicle also re-surfaces bulletins and recalls that the dedicated bulletins/recalls tools return, blurring boundaries. Descriptions do help, but the purposeful overlap between the automotive tools keeps this from being cleanly distinct.
Every tool shares a wenmar_ prefix and a noun-with-action-parameter convention (action=vehicle/get/search/etc.), so the pattern is predictable despite lacking verb_noun verbs. Minor deviations only: wenmar_vin is singular while others are plural, and wenmar_labor is a mass noun.
Seven tools is well within a healthy range, and each maps to a distinct data domain (bulletins, codes, labor, recalls, vehicles, VIN, payroll). No tool feels redundant or artificially split, and the count is proportionate to the breadth of the data service.
The automotive domain is broadly covered: vehicle catalog, VIN decode, OBD codes, manufacturer bulletins, recalls, and labor times, with search/pagination throughout. As a read-only lookup service it lacks no obvious lifecycle operations, though there is no parts/procedure or pricing data (pricing is explicitly out of scope), leaving minor gaps that agents can work around.
Manufacturer communications NHTSA publishes: service bulletins, service campaigns, warranty extensions and over-the-air updates. Each has NHTSA's summary, the manufacturer's own document number, and document, the address NHTSA's copy of the document is expected at (not confirmed; null for old ones). The document itself is the manufacturer's and is not returned. A bulletin lists model years: it is not a recall and does not say a vehicle is affected. action=vehicle takes id, a vehicle id such as "2018_ford_f-150", and gives one page of that model year's bulletins, newest first, with counts by type, component, trouble code and topic. action=vin takes vin (and optionally year) and does the same for the model year the VIN decodes to. action=get takes nhtsa_id and gives one bulletin with every vehicle it lists. action=search lists all bulletins newest first, narrowed by make, model (needs make) and year. Every action but get takes type (service_bulletin, service_campaign, warranty_extension, over_the_air, emissions, other), component (an id from counts.components, such as brakes), code (a trouble code such as P0420), topic (maintenance), query (free text in the summary, such as a symptom), limit (at most 100, 25 when left out) and cursor (next_cursor of the page before). This tool needs the hosted service: a local data file does not hold bulletins.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A vehicle id, such as 2018_ford_f-150. | |
| vin | No | A 17-character VIN. Spaces and dashes are ignored. | |
| code | No | ||
| make | No | ||
| type | No | ||
| year | No | For vin: the model year to use. For search: only bulletins that list this model year. | |
| limit | No | ||
| model | No | ||
| query | No | ||
| topic | No | ||
| action | Yes | ||
| cursor | No | ||
| nhtsa_id | No | NHTSA's id number for the communication. | |
| component | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint and openWorldHint, so the description carries the rest and does well: pagination (cursor/next_cursor, limit default 25, max 100), ordering (newest first), counts-by-dimension in the response, and the nullable `document` field whose file is explicitly not returned. It stops short of stating auth requirements or rate limits, so it is strong but not fully complete.
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 content is dense and front-loaded (what the data is, then what it is not, then the actions), and most sentences carry non-redundant information. The single long paragraph, however, mixes the action catalog with the shared-parameter list, making it slightly harder to scan than a sectioned layout would be.
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 14-parameter, four-action tool with no output schema, the description covers everything an agent needs: each action's inputs, the shared filter set, pagination mechanics, response shape (one page, newest first, counts), and the null-document caveat. Nothing material is left unspecified.
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 only 29%, so the description must compensate, and it does — it explains nearly every one of the 14 parameters, including constraints absent from the schema such as limit's default of 25 and cap of 100, cursor being the prior page's next_cursor, model requiring make, and year's differing meaning for vin vs search.
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 precisely what the resource is (manufacturer communications: service bulletins, campaigns, warranty extensions, OTA updates) and explicitly differentiates it from recalls, a sibling tool: 'it is not a recall and does not say a vehicle is affected.' An agent can identify both the scope and the boundary with wenmar_recalls without opening any schema.
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 routed explicitly with its required inputs — action=vehicle takes id, action=vin takes vin (optional year), action=get takes nhtsa_id, action=search narrows by make/model/year — so the agent knows which mode to pick. It also supplies a when-not ('not a recall') and a stated prerequisite ('needs the hosted service').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic OBD-II trouble codes, described in Wenmar Open's own words: a title, what the code means, common causes, first checks, the components it concerns and related codes. Only codes every maker uses the same way are described (P0, P2, P3400 and up, B0, C0, U0, U3). Manufacturer-specific codes are not described. action=get takes code, such as "P0420", and gives its description. action=search lists the described codes by code, narrowed by query (text in the code, title or meaning) and system (powertrain, body, chassis, network, or an area such as powertrain/emissions); pass next_cursor back as cursor. action=vehicle takes id, a vehicle id such as "2018_ford_f-150", and code, any code, a manufacturer-specific one included: it gives the description (null when there is none), the bulletins of that model year whose NHTSA summary names the code, and the bulletins and recalls of that model year about the same components. A part of that answer is null where the data is not held. A description is general and is not a diagnosis; a bulletin or recall listed may apply to the model year and is not confirmed for one vehicle.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A vehicle id, such as 2018_ford_f-150. | |
| code | No | A trouble code, such as P0420. Either case. | |
| limit | No | ||
| query | No | ||
| action | Yes | ||
| cursor | No | ||
| system | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declaring the safety profile, the description adds real context: null semantics ('null when there is none', 'A part of that answer is null where the data is not held'), pagination (pass next_cursor back as cursor), and disclaimers that a description is not a diagnosis and bulletins are model-year, not vehicle-confirmed.
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 resource and coverage scope, then a per-action breakdown. It is dense and long but each clause carries information (examples, null behavior, caveats) with little 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?
For a 7-parameter, 3-action tool with no output schema, the description covers every action, example values, null behavior, and result caveats. Only the limit parameter is unexplained, which is a minor gap given the otherwise thorough coverage.
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 29%, so the description must compensate, and it largely does: code (example 'P0420'), query (text in code, title or meaning), system (powertrain/body/chassis/network or an area), cursor, id (example vehicle id), and action semantics are all explained. limit is left undocumented in both schema and 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?
Names a specific resource (OBD-II trouble codes in Wenmar Open's words), enumerates the scope of coverage (P0, P2, P3400+, B0, C0, U0, U3; manufacturer-specific excluded), and lists the three actions. An agent can tell exactly what this returns and how it differs from bulletin/recall siblings.
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?
Clearly routes between the three actions with their required inputs (get=code, search=query/system, vehicle=id+code). It does not explicitly say when to prefer this tool over wenmar_bulletins or wenmar_recalls even though it mentions their data, so there is no alternative/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wenmar's own estimates of the hours a repair job takes: written by people who do the work and later measured from repair orders, never from a labour guide. An estimate, not a quote. Rust, seized fasteners and added equipment change the time. action=jobs lists the jobs an estimate can be about; with job it gives one job: what it includes, what it excludes, and its typical hours by class of vehicle. action=vehicle takes id, a vehicle id such as "2018_ford_f-150" (an id that ends with an engine asks for that engine), and optionally job: for each job it gives hours (low, typical, high), basis (expert or observed) and scope, which says what the figure is for: engine, generation, model or class. A class figure is typical for vehicles of that class and was not worked out on this vehicle: say so. A job with no figure for the vehicle is not listed. action=vin takes vin (and optionally year, job) and does the same for the vehicle the VIN decodes to. No answer holds a price: multiply by the shop's own rate. Credit the data as attribution says: Labour estimates by Wenmar Pro, CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A vehicle id, such as 2018_ford_f-150. | |
| job | No | A job id, such as brake-pads-front. | |
| vin | No | A 17-character VIN. Spaces and dashes are ignored. | |
| year | No | For vin: the model year to use. | |
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and closed-world safety, so the description adds real behavioral context: estimates are not quotes, figures are expert or observed, class figures weren't computed on the specific vehicle, no price is included, and attribution/licence requirements apply. These reshape how results should be treated and credited, well beyond the 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?
Front-loads the essential nature of the data, but the single dense paragraph mixes value proposition, per-action mechanics, output semantics, and licensing. It is information-rich but could be split or trimmed; a few clauses restate schema content.
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 burden and does describe returned fields (hours low/typical/high, basis, scope, attribution). It is nearly complete for the three actions, though it doesn't cover edge cases like invalid VINs or empty results.
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 80%, so the schema documents the basic params, but the description adds meaningful semantics: the id ending in an engine selects that engine, vin accepts year and job, and it clarifies what `scope`/`basis` mean in results. The slightly redundant glosses (vehicle id example repeats the schema) keep it from a 5.
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 exactly what the tool returns — Wenmar's own labour hour estimates, explicitly not from a labour guide — which distinguishes it from typical lookup tools and from siblings like wenmar_bulletins or wenmar_codes. The three actions are each described concretely.
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?
Gives clear per-action context (action=jobs lists jobs, action=vehicle for a vehicle id, action=vin for a VIN) and warns that a job with no figure for the vehicle is not listed. It doesn't explicitly say when to prefer this tool over siblings such as wenmar_vin, leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out the deductions from one regular pay in Ontario by CRA's T4127 formulas (Option 1): federal and Ontario income tax, CPP, CPP2 and EI, the net pay, the employer's CPP, CPP2 and EI, and every T4127 factor used with what it means. Takes frequency (weekly, biweekly, semi-monthly or monthly) and gross, the gross pay for the period. federal_claim and provincial_claim are the TD1 claim amounts: left out, each is the basic personal amount (claim code 1), and 0 is claim code 0. pay_date (YYYY-MM-DD) chooses the tables; left out, it is today, and a day outside the tables held is an error that names their dates. ytd_cpp, ytd_cpp2, ytd_ei and ytd_pensionable are what was deducted and earned on earlier pays this calendar year. Money is a number or text such as "2400.00". Ontario only; not for a bonus, commission or retroactive pay. The answer is an estimate and the employer remains liable to CRA for what it deducts and remits: say so, and point to CRA's Payroll Deductions Online Calculator at pdoc_url.
| Name | Required | Description | Default |
|---|---|---|---|
| gross | Yes | Gross pay for one pay period, in dollars. | |
| ytd_ei | No | EI deducted earlier this year. | |
| ytd_cpp | No | CPP (base and first additional) deducted earlier this year. | |
| pay_date | No | YYYY-MM-DD. Left out: today. | |
| province | No | Ontario only for now. Left out: ON. | |
| ytd_cpp2 | No | CPP2 deducted earlier this year. | |
| frequency | Yes | ||
| federal_claim | No | Federal TD1 claim amount. Left out: claim code 1. | |
| ytd_pensionable | No | Pensionable earnings earlier this year. | |
| provincial_claim | No | Ontario TD1ON claim amount. Left out: claim code 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=false) already establish that this is a safe, closed-domain read, so the description adds genuinely new behavior: a pay_date outside the held tables is an error that names the covered dates, the result is an estimate, and the employer remains liable. It also discloses the shape of the response by listing every value returned.
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 purpose and outputs before diving into parameter semantics, and each sentence carries information. It is dense and long-winded for a single paragraph, but the length is largely justified by 10 parameters and the absence of an output schema.
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 steps in to enumerate the return contents, and it covers defaults, error behavior, scope limits, and the liability disclaimer. An agent has everything it needs to call this correctly and to relay the result honestly.
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 already 90%, but the description adds meaning the schema lacks: federal_claim/provincial_claim are TD1 claim amounts where '0 is claim code 0', ytd_cpp/cpp2/ei/pensionable are 'what was deducted and earned on earlier pays this calendar year', and money may be a number or text like "2400.00". The frequency enum is repeated rather than explained, so this is slightly short of a 5.
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?
Opens with a specific verb+resource ('Works out the deductions from one regular pay in Ontario') and enumerates exactly what is computed (federal/Ontario tax, CPP, CPP2, EI, net pay, employer contributions, T4127 factors). An agent immediately knows this is a payroll calculation tool rather than a lookup, and it is trivially distinguishable from the unrelated wenmar siblings.
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?
States explicit scope and exclusions: 'Ontario only; not for a bonus, commission or retroactive pay', and routes the agent to CRA's Payroll Deductions Online Calculator at pdoc_url. It also defines the error condition for pay_date outside the held tables, so an agent can pre-empt a failed call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall campaigns from NHTSA (United States) and Transport Canada that may apply to a vehicle. A campaign lists a year, a make and a model, so every answer has may_apply: true. It may apply; confirm by VIN with the manufacturer, or at the addresses in lookup. This is never a lookup by VIN. action=vehicle takes id, a vehicle id such as "2018_ford_f-150". action=vin takes vin (and optionally year): it decodes the VIN and lists the recalls of its model year. action=campaign takes source (nhtsa or tc) and campaign, such as "19V888000", and gives that campaign with every vehicle it lists. action=search lists campaigns newest first, narrowed by any of make, model (needs make), year, component and query (free text); limit is at most 100 and 25 when left out; cursor is next_cursor of the page before. action=recent takes since, a day such as "2026-09-01", and lists the campaigns reported on or after it, newest first, each with the vehicles it lists; it also takes make, limit and cursor. country is us or ca on every action but campaign; left out, both.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A vehicle id, such as 2018_ford_f-150. | |
| vin | No | A 17-character VIN. Spaces and dashes are ignored. | |
| make | No | ||
| year | No | For vin: the model year to use. For search: only campaigns that list this model year. | |
| limit | No | ||
| model | No | ||
| query | No | ||
| since | No | For recent: a day, such as 2026-09-01. Campaigns reported on or after it are listed. | |
| action | Yes | ||
| cursor | No | ||
| source | No | ||
| country | No | ||
| campaign | No | The publisher's campaign number. | |
| component | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety (readOnlyHint) and world scope, so the description carries the interpretive burden and does it well: every answer has may_apply: true, results must be confirmed with the manufacturer, and pagination behavior (limit max 100, default 25, cursor = next_cursor) is disclosed. That is meaningful context an agent cannot derive from the structured fields. The only wrinkle is that the cited addresses in `lookup` are not a documented action or parameter.
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?
It is long but proportionate to a 14-parameter, 5-action tool, and the core framing (what a campaign is, that it is never a VIN lookup) is front-loaded before the action-by-action detail. There is mild redundancy in the may_apply caveat and the density of the single paragraph makes the action list slightly hard to scan.
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 and 14 parameters, the description nearly closes the gap by covering every action and most parameters plus return shape hints (campaign with every vehicle it lists, next_cursor). It loses a point for referencing a `lookup` destination that exists nowhere in the schema, leaving the agent unsure where those confirmation addresses come from.
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 only 36%, so the description must compensate, and it does: it documents make, model (and that model needs make), year, component, query as free text, limit bounds and default, cursor semantics, since's date format, the source and country enums, and gives concrete examples for id and campaign. Conditional parameter constraints are called out rather than left to inference.
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 opening sentence names the specific resource (recall campaigns from NHTSA and Transport Canada) and the description then enumerates the five action modes, so an agent knows exactly what the tool returns. Sibling differentiation is only implicit — it never names wenmar_vin or wenmar_bulletins as the place to go for adjacent questions, so it falls just 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 spells out the scenario each action serves (vehicle id, VIN decode, campaign number, filtered search, recent feed) with required companion parameters, which is strong intra-tool routing. It also states a when-not ('This is never a lookup by VIN'), though it never says when to prefer a sibling tool such as wenmar_vin for VIN work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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"); overview (id: everything held for that model year in one answer, with a count of the recall campaigns that may apply and the three newest; a block with no data is null); model_years (make, model: every model year of one model, newest first, each with its vehicle id and the number of recall campaigns that may apply); safety (id: NHTSA's crash test ratings for that model year, one entry for each vehicle NHTSA rated, by body style and drive, each with its stars; an entry with no stars is a vehicle NHTSA lists and has not tested); fuel (id, optional country us or ca: fuel consumption ratings from EPA and Natural Resources Canada, each saying in confidence how far it was matched: model, engine or submodel); specs (id: transmission, drive, recommended fuel and more from EPA's files, one entry per EPA rating); fluids (id: the engine oil grade EPA records for each engine, and records a person read from the maker's own documents, each with its source and the day it was checked; an empty list means nobody has recorded it); tires (id: every original-equipment tire size on record with the trims it covers; none is picked). 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. action=complaints takes id and gives what owners reported to NHTSA about that model year as counts by component, with the median mileage owners gave: these are owners' reports, not verified, and a count is not a rate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| make | No | ||
| term | No | ||
| year | No | ||
| limit | No | ||
| model | No | ||
| query | No | ||
| scope | No | ||
| action | Yes | ||
| country | No | For action=fuel: us or ca. Leave out for both. | |
| submodel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description instead adds valuable data-semantics context: a block with no data is null, an entry with no stars means NHTSA lists but has not tested the vehicle, fuel entries carry a `confidence` level, an empty fluids list means nobody recorded it, and complaints are unverified owner reports where a count is not a rate. It omits operational traits like pagination or rate limits, and the `limit` parameter is never explained.
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 purpose is front-loaded and almost every clause carries new information, so there is little dead weight. But the body is one mega-paragraph of semicolon-separated action clauses, which is dense and hard to scan; a per-action list would have been far more usable.
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 15-action, 11-parameter tool with no output schema, the description is unusually complete, covering each action's inputs plus return-shape caveats (null blocks, untested-star entries, confidence levels). It lacks only sibling routing and any mention of `limit`, which is minor relative to the complexity covered.
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 schema description coverage at only 9%, the description does the heavy lifting: it maps each action to its parameters, states that `make`/`model` accept a name, alias or id, explains `term` as a prefix filter, defines `scope` values (light/all/vPIC type id), and gives `query` and `id` examples. The `limit` parameter receives no explanation, which is the only material gap.
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 opens with a specific verb+resource ('Look up vehicles by year, make, model, submodel and engine') and then enumerates 15 concrete actions, so an agent knows exactly what the tool covers. However, it never distinguishes this catalog from siblings like wenmar_recalls or wenmar_vin, even though the overview/model_years actions surface recall counts and a complaints action overlaps recall territory, leaving sibling boundaries implicit.
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?
Usage is only implied: each action's required and optional parameters are listed inline (e.g. models needs `make`, optional `year`), which effectively tells the agent how to call each branch. But there is no explicit when/when-not guidance and no routing to alternatives such as wenmar_vin for VIN lookups or wenmar_recalls for full recall data.
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, 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.
| 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 | ||
| country | No | For action=fuel: us for EPA's ratings, ca for Natural Resources Canada's. Leave out for both. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
wenmar_payroll_deductionswenmar_bulletinswenmar_codeswenmar_laborwenmar_recallswenmar_vehicles2 fields changedInput schema / properties / action / enumPrevious value: -[
- "years",
- "makes",
- "models",
- "submodels",
- "engines",
- "search",
- "entry"
-]New value: +[
+ "years",
+ "makes",
+ "models",
+ "submodels",
+ "engines",
+ "search",
+ "entry",
+ "overview",
+ "model_years",
+ "safety",
+ "complaints",
+ "fuel",
+ "specs",
+ "fluids",
+ "tires"
+]Input schema / properties / countryAdded value: +{
+ "description": "For action=fuel: us or ca. Leave out for both.",
+ "type": "string"
+}wenmar_vin2 fields changedInput schema / properties / action / enumPrevious value: -[
- "decode",
- "batch"
-]New value: +[
+ "decode",
+ "batch",
+ "overview",
+ "fuel",
+ "specs",
+ "fluids",
+ "tires"
+]Input schema / properties / countryAdded value: +{
+ "description": "For action=fuel: us for EPA's ratings, ca for Natural Resources Canada's. Leave out for both.",
+ "type": "string"
+}wenmar_vehicleswenmar_vinDecode US-market VINs and list NHTSA recall campaigns for the make, model and year. Free, no auth.
Decode any VIN and see NHTSA safety recalls and owner complaints.
Free NHTSA recalls, complaints and investigations per vehicle, recall alerts, dealer listing events.
Decode VINs, search recalls, complaints, crash ratings, and investigations.
Add one secure layer between your agents and this server.
