Look up a UK or Dutch number plate or decode a VIN: make, model, MOT history, mileage checks
Scored across 5 tools
The three UK plate tools overlap heavily: uk_vehicle already returns full MOT test history and latest mileage, which are also the focus of uk_mot_history and uk_mileage_check. Descriptions help distinguish the narrower checks, but an agent may still reasonably pick uk_vehicle for most MOT-related tasks, leaving unclear boundaries.
All names use snake_case and are readable, but the conventions are mixed: some use a country prefix (uk_vehicle, uk_mot_history), one is country plus action phrase (uk_mileage_check), and vin_decode follows a noun_verb pattern. It is not chaotic, but there is no predictable verb_noun or resource_action pattern throughout.
Five tools is a well-scoped count for a vehicle lookup server, with each tool representing a distinct lookup dimension (UK plate, MOT history, mileage, VIN, Dutch plate). The set is neither too thin nor too heavy.
The core UK vehicle lookup surface is covered: plate details, MOT history, mileage anomaly check, and VIN decode. However, for pre-purchase use cases there are notable gaps such as road tax status (explicitly excluded), and broader checks like finance/stolen status are absent.
Dutch number plate (kenteken) lookup from the Dutch vehicle authority RDW: make, model, body, colour, doors, seats, engine, power, fuel, CO2, weights, towing, original list price, first registration, MOT (APK) expiry, insured, open recall, odometer verdict. (cost: 20 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| plate | No | string, required: Dutch plate, e.g. XN-097-Z |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the description's job is to add context, which it does: it names the authoritative data source (RDW), enumerates the data classes returned including sensitive ones (insured status, open recall, odometer verdict), and discloses a cost of 20 credits. It does not cover failure behavior for an unregistered or malformed plate, but the added disclosure is substantial.
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 sentence, front-loaded with the action and the authority, then a dense field list and the credit cost at the end. Every clause carries information; the mid-sentence attribute enumeration is long but justified because no output schema exists.
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 field enumeration effectively documents the return payload, and the credit cost flags a paid call — both important for a one-parameter tool. Missing only edge-case behavior (invalid plate handling, partial data) to be fully complete.
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?
Only one parameter, and the schema already documents it at 100% coverage with an example (XN-097-Z). The description contributes the Dutch term 'kenteken' and reinforces that the input is a Dutch plate, but adds no format or normalization rules beyond the schema, so the baseline 3 applies.
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: number plate (kenteken) lookup against the Dutch RDW authority, followed by an enumeration of the returned attributes. It is clearly distinguishable from most siblings, though the near-neighbour vin_decode is not named as the alternative for non-plate vehicle identification.
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 implied by 'lookup from the Dutch vehicle authority RDW' — you call it when you have a Dutch plate. There is no explicit when-to-use/when-not guidance and no mention of vin_decode as the alternative for VINs or non-Dutch vehicles, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a UK car's recorded mileage ever went backwards between MOT tests (a sign of clocking), with the latest reading and the number of readings, from official DVSA MOT records. (cost: 10 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| plate | No | string, required: UK registration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and open-world behaviour, so the description focuses on what they cannot convey: the official DVSA source and a cost of 10 credits, which matters for call budgeting. It also previews the return content (latest reading and number of readings).
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?
One front-loaded sentence carries the check, its meaning, the data source, the return fields and the cost. It is dense but has no filler; only the parenthetical cost might be separated for scannability.
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 lookup with no output schema, the description explains the data source and the shape of the result, which is most of what an agent needs. The absence of any note on missing-record behaviour or result framing keeps it short of a 5.
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% and there is a single 'plate' parameter documented as a required UK registration, so the description adds nothing further about the input. Baseline 3 applies.
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 — checks whether a UK car's recorded mileage ever went backwards between MOT tests — and frames the anomaly as clocking. This clearly separates it from the sibling uk_mot_history, which presumably returns raw test records.
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 implied by the anomaly it detects (clocking detection), and the DVSA provenance hints at the data domain, but the description never says when to pick this over uk_mot_history or uk_vehicle, nor what to do if no records are found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full MOT test history for a UK number plate from DVSA: every test date, pass or fail, expiry, recorded mileage, and each failure, advisory and dangerous defect. For checking a used car before buying or when the next MOT is due. (cost: 10 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| plate | No | string, required: UK registration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description is not carrying that burden. It still adds real value beyond them by naming the upstream source (DVSA) and disclosing a 10-credit cost, which matters for invocation decisions. It doesn't say what happens for an unknown or non-UK plate.
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?
Two tight sentences: the payload of returned fields is front-loaded, then use case plus cost. The field enumeration earns its place because there is no output schema, and there is no redundant restatement of the tool name.
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 compensates by listing the returned data (dates, pass/fail, expiry, mileage, defect severities), and it adds source and cost. For a one-parameter lookup this is complete enough for an agent to call 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?
Schema coverage is 100% and there is only one parameter, so the schema does the work. The description's 'UK number plate' does add a modest constraint on the expected input format beyond 'string, required: UK registration', but no spacing/format normalisation guidance.
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 + resource: full MOT test history for a UK plate, sourced from DVSA, and enumerates what the history contains. It is clearly distinct from siblings such as uk_vehicle or vehicle_recalls in substance, though it never names an alternative to contrast against.
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 a usage context ('checking a used car before buying or when the next MOT is due'), which is genuine when-to-use guidance. It stops short of explicit exclusions or pointing to neighbours like uk_mileage_check or uk_vehicle for adjacent questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK number plate lookup from official DVSA MOT records: make, model, colour, fuel, engine size, first registration date, MOT expiry, outstanding recall flag, latest mileage, and the full MOT test history with failures and advisories. Does not include road tax status. Cars under 3 years old have no MOT history yet. (cost: 10 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| plate | No | string, required: UK registration, e.g. AB12 CDE | |
| history | No | boolean, default true: include each MOT test |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant behavior: an explicit cost of 10 credits, the authoritative source (DVSA MOT records), and two coverage limits. Missing is anything about rate limiting, error behavior for unknown plates, or result freshness.
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?
Three sentences, no filler, front-loaded with the core capability before the field list, then caveats last. Every clause carries information, including the parenthetical cost.
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 read-only lookup with no output schema, the description does the heavy lifting well by enumerating returned fields and flagging the two data-availability caveats. It could go one step further by noting what a failed/unknown-plate response looks like or how the history flag changes the payload size, but nothing essential to correct invocation 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 description coverage is 100% with only two parameters, so the schema already documents both `plate` and `history` (including the default). The description's mention of "the full MOT test history" loosely gestures at the history flag but adds no format or example beyond the schema's own "AB12 CDE" example. 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?
Names a specific verb and resource (UK number plate lookup) and enumerates exactly what comes back: make, model, colour, fuel, engine size, registration date, MOT expiry, recall flag, mileage, and full MOT history. That level of specificity is well above a restatement of the name. It stops short of a 5 because it does not differentiate itself from near-overlapping siblings such as uk_mot_history, uk_mileage_check, or vin_decode, which an agent would need to disambiguate.
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?
Scope exclusions are given ("Does not include road tax status", "Cars under 3 years old have no MOT history yet"), which usefully tell the agent when results will be thin. However, there is no guidance on when to pick this tool over the sibling tools that overlap on MOT history and mileage, and no statement of alternatives. Usage is implied by the field list rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a VIN (vehicle identification number): make, model, year, trim, body, doors, engine, transmission, drive, fuel, seats, plant, airbags and driver-assist kit (NHTSA vPIC). Fullest for North American vehicles. (cost: 5 credits)
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | string, required: 17-character VIN | |
| modelYear | No | number: optional, helps older VINs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the underlying data source (NHTSA vPIC), a geographic coverage limitation, and a 5-credit cost — the kind of information an agent cannot get from structured fields.
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 front-loaded sentence carries the verb, the resource, the full field list, the data source, the coverage caveat and the cost — with no boilerplate or repetition. 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?
With no output schema, the field enumeration is the right compensation and is present; source, coverage limits and cost round it out. Minor gaps remain: nothing is said about failure behavior for an invalid or unknown VIN, and the schema marks vin as 'required' while the top-level required list is empty.
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% and both parameters are documented there, including the 17-character VIN format and the note that modelYear helps older VINs. The description adds nothing about parameter behavior beyond the schema, so the baseline 3 applies.
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 names a specific verb (decode) and resource (VIN), then enumerates exactly what attributes are returned (make, model, year, trim, body, engine, transmission, plant, airbags, driver-assist). It is unambiguous about what the tool does, but it never references the sibling nl_vehicle, which an agent might reasonably confuse with a VIN decode.
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?
There is no explicit when-to-use or when-not-to-use statement. The caveat 'Fullest for North American vehicles' implicitly tells the agent when results will be weaker, and the '(cost: 5 credits)' note gives a cost-based selection signal, but neither is framed as guidance and no alternative tool is named.
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.
nl_vehicleuk_mileage_checkuk_mot_historyuk_vehiclevin_decodeFree used-car facts from the official register (NL, GB, IL, IS, DK) with source and date.
UK vehicle lookup, MOT status and full MOT history from official DVSA data, by registration.
Dutch licence plates: APK, recalls, odometer, history, model reliability. 5 checks a day free.
Look up a vehicle by license plate against official sources (make/model, year, status, restrictions)
Add one secure layer between your agents and this server.