UK used-car checks: MOT history, mileage and an advert's claims tested against the records
Scored across 8 tools
Each tool targets a distinct step of the car-report flow (free_check, full_report, unlock_report, sample_report, viewing_advice), and descriptions explicitly say when to use each. There is mild overlap since unlock_report returns the same payload as full_report and full_report already bundles a viewing checklist that viewing_advice also covers, but the guidance largely resolves it.
All names are lower_snake_case and readable, following a noun or verb_noun shape (decode_plate, unlock_report, free_check, credits_balance). Only minor deviation is that most names are noun phrases rather than a uniform verb_noun pattern, which doesn't hurt comprehension.
Eight tools map cleanly onto the product's steps: identity/credits, free lookup, plate decoding, paid unlock, full report, viewing advice, sample, and report history. Nothing appears redundant or bloated for the stated scope.
The lifecycle is well covered: free lookup, decode, unlock (spend), full report, viewing advice, credits, report history, and a public sample. The only visible gap is there is no tool for linking/managing the RegTail account that several tools depend on, though that may live outside this server.
How many credits the user's RegTail account holds, and pricing_url, a page explaining how credits work. Needs the user's RegTail account linked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe-read profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds genuine value beyond them: the account-linking prerequisite and the fact that the response carries a pricing_url explainer rather than just a number.
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 short sentences, front-loaded with the primary return value (credit count) before the secondary pricing_url. The second clause is grammatically fragmented ('and pricing_url, a page explaining how credits work'), which slightly muddies the read but costs little.
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?
A no-argument, read-only tool with an output schema and full annotation coverage needs very little prose. The description covers purpose, an auth prerequisite, and the shape of the return payload, so an agent has everything required to invoke it 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?
The tool takes zero parameters, so there is nothing to disambiguate and no schema gap to compensate for. With no inputs required, parameter documentation is inherently complete at the baseline of 4.
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 concrete resource and outcome: 'How many credits the user's RegTail account holds,' plus the accompanying 'pricing_url' explainer page. It is immediately clear this is a read of account credit state. No sibling (decode_plate, full_report, unlock_report, etc.) overlaps, so no differentiation is needed, but neither is it provided.
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 rather than spelled out, though the description does supply one real precondition: 'Needs the user's RegTail account linked.' That tells the agent when the call will succeed. There is no statement of when not to call it or what to do if the account is unlinked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When a UK plate of this format could have been issued, from the plate alone (format, age identifier, and the window as first and last month). Offline: it does not look the car up; use free_check for that. No account needed.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | UK registration plate, any spacing or case, e.g. 'AB12 CDE' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant context: the tool works offline from the plate string alone, performs no vehicle lookup, and requires no account. It does not state behavior on an unrecognized or non-conforming plate, which is the remaining gap.
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 short sentences, zero filler, with the output scope front-loaded and the exclusion (free_check) immediately after. The opening clause is a sentence fragment that takes a moment to parse, but nothing is wasted.
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?
An output schema exists, so return values need not be explained, and the description nonetheless previews the response fields. It is complete for a single-parameter, read-only decode; the only omission is what happens for plates that don't match the stated format.
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 a single parameter and schema description coverage is 100% — the schema already specifies 'UK registration plate, any spacing or case' with an example. The description adds no syntax, normalization, or validation detail beyond that, so the schema carries the parameter semantics.
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 a UK plate') and enumerates exactly what it returns: format, age identifier, and the issue window as first/last month. It also pre-empts confusion with the sibling that looks up the vehicle itself, so an agent can separate decode_plate from free_check without reading either 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?
Names an alternative and the condition that selects it ('it does not look the car up; use free_check for that') and adds prerequisites ('Offline', 'No account needed'). It does not address the other report-oriented siblings, but the one boundary an agent is likely to confuse is drawn explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The free check of a UK car by its registration plate: make, model, engine and fuel, tax and MOT status with their dates, and the latest MOT test with its result, mileage and any defects or advisories. Use when the user gives a plate or asks about a car. No account needed and nothing is spent.
Returns: car, tax, mot, latest_mot_test, since_previous_test, unlocked (whether the user's linked account can
already see the full report), full_report_covers (what the full report adds) and guidance.| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | UK registration plate, any spacing or case, e.g. 'AB12 CDE' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 useful context beyond that: no account is required, nothing is spent, and it explains the 'unlocked' field's meaning relative to the user's linked account, which no structured field would convey.
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 purpose and usage trigger in two tight sentences, then a scannable return list. Slightly padded by the 'Returns:' enumeration, since an output schema already exists, but nothing is misleading or wasted-heavy.
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?
Covers purpose, trigger, cost/auth posture, and even clarifies the ambiguous 'unlocked'/'full_report_covers' return fields. Since an output schema is present, the remaining return-field listing is mostly redundant, but nothing an agent needs to invoke it correctly 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?
Only one parameter, fully documented at 100% schema coverage including spacing/case tolerance and an example. The description adds only the loose gloss 'by its registration plate,' so per the baseline rule a 3 is appropriate when the schema does the heavy lifting.
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 ('free check of a UK car by its registration plate') and enumerates the exact data domains covered (make/model/engine/fuel, tax, MOT status, latest MOT test). The mention of 'full_report_covers' and 'unlocked' implicitly separates it from the paid sibling full_report, so an agent can distinguish it without opening schemas.
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?
Explicit trigger: 'Use when the user gives a plate or asks about a car,' plus the constraint 'No account needed and nothing is spent,' which tells the agent this is the no-cost entry point. It stops short of naming an alternative (e.g. 'use full_report for a deeper history'), so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full report of a car the user has unlocked on their RegTail account: verdict and top risks, every MOT test with defects and advisories, mileage analysis, recurring advisories, the advert's claims tested, other sections, the viewing checklist, what was not checked, and guidance for explaining it. Use to discuss a car in depth. Needs the user's RegTail account linked. Never spends: for a plate that is not unlocked it returns unlocked=false and a message; then ask the user before calling unlock_report.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | UK registration plate, any spacing or case, e.g. 'AB12 CDE' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that it consumes no credits, that it requires a linked account, and that a locked plate yields unlocked=false with a message. These are real operational traits an agent cannot infer from annotations or schema.
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?
Purpose and scope are front-loaded, and the guidance sentences are tight and action-oriented. The content enumeration is long, but each listed section is meaningful to an agent deciding whether this tool answers the user's question.
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?
Prerequisites, cost model, and the locked-plate error path are all covered, and an output schema exists so return values need no prose. Nothing an agent needs before invoking or after a failed 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?
Only one parameter (plate) and schema coverage is 100%, with the schema itself documenting spacing/case tolerance and an example. The description adds no syntax or format detail beyond that, 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?
Opens with a specific verb+resource ('The full report of a car the user has unlocked') and then enumerates exactly what the report contains (verdict, MOT tests, mileage analysis, advert claims, viewing checklist). This clearly separates it from siblings like free_check, sample_report, and unlock_report.
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 the use case ('Use to discuss a car in depth'), the prerequisite (RegTail account linked), the cost behavior ('Never spends'), and the exact failure path plus the follow-up action (ask the user before calling unlock_report). Alternatives and conditions are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cars the user has unlocked (with when each unlock ends) and their recent checks, so a conversation can pick up a car checked earlier. Needs the user's RegTail account linked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds a real prerequisite beyond them: 'Needs the user's RegTail account linked,' which tells the agent an auth precondition must be met before calling. It stops short of describing return shape or pagination, but the output schema carries that.
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 short sentences, front-loaded with the return content and followed by the prerequisite. Every clause earns its place. Slightly compressed phrasing ('with when each unlock ends') costs a little polish but not clarity.
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 parameters, full annotation coverage, and an output schema that defines the return values, the description only needs to say what the tool is for and any preconditions. It does both, adding the account-linking requirement. The only gap is sibling differentiation, which matters given seven related tools.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a no-param tool is 4, and nothing in the text confuses the (empty) argument surface.
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 specifically what it returns: the user's unlocked cars with each unlock's end time, plus their recent checks. That is a concrete resource and scope an agent can act on. It does not, however, differentiate itself from siblings like unlock_report or full_report, so an agent cannot route on the description alone.
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 phrase 'so a conversation can pick up a car checked earlier' gives an implied use case, which is better than nothing. But there is no explicit when-to-use rule, no when-not-to-use, and no named alternative among the seven siblings, so the selection decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full report and viewing advice for one public sample car (CX52HHM, a 2002 Land Rover Defender), to show what a full report contains. Use when the user asks what RegTail's full report looks like. No account needed. It is always the same sample car, never the user's car.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds behavior the annotations do not: no authentication is required, the response always describes the same static sample car, and the payload includes viewing advice as well as the report.
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 short sentences, front-loaded with what the tool returns, followed by the usage trigger and the scope caveat. The purpose is restated slightly ('to show what a full report contains' / 'what RegTail's full report looks like'), a minor redundancy in an otherwise tight definition.
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?
An output schema exists so return values need no explanation, and the description still tells the agent what to expect (full report plus viewing advice), when to call it, what access is required, and that the data is static and not user-specific. Nothing needed to invoke it correctly 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?
The tool takes zero parameters and the description correctly presents it as argument-free, so there is nothing to disambiguate. Baseline 4 applies for a no-parameter tool.
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 resource (a full report for one fixed sample car), names the concrete sample (CX52HHM, 2002 Land Rover Defender), and explicitly distinguishes it from the real report by noting it is 'never the user's car'. That contrast separates it from the full_report sibling without needing to open either 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?
It gives an explicit trigger ('Use when the user asks what RegTail's full report looks like') and a precondition ('No account needed'), plus an exclusion that the sample car is never the user's car. It stops short of naming full_report or unlock_report as the alternative for real vehicles, so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spends one of the user's RegTail credits to unlock the full report for this plate for 30 days, then returns the full report (as full_report does). Ask the user first, every time, and call this only after they agree; never unlock on your own initiative or to answer a general question. A plate already unlocked costs nothing again. Needs the user's RegTail account linked. With no credits left it unlocks nothing and spends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | UK registration plate, any spacing or case, e.g. 'AB12 CDE' | |
| confirmed | Yes | True only when the user has just said yes to spending one credit on this plate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, idempotent mutation, and the description goes well beyond them: it names the cost (one credit), the unlock duration (30 days), the idempotency detail (already unlocked costs nothing), the account prerequisite, and the zero-credit no-op. This is exactly the added behavioral context the annotations cannot carry.
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 action, cost, and result are front-loaded, followed by the consent guardrail and edge cases. Five short sentences, each carrying a distinct operational fact with no padding.
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 an output schema present, the description needn't explain the return payload, and it covers cost, duration, idempotency, prerequisites, and failure behavior. An agent has everything needed to call this correctly and safely.
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 both 'plate' and 'confirmed' are already fully documented. The description reinforces the intent behind 'confirmed' (user consent), but adds no syntax or format beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 pairs a specific verb (unlock) with a specific resource (the full report for this plate) and clarifies the relationship to the sibling full_report. An agent can immediately distinguish this paid unlock from the free/read siblings 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?
It gives explicit when-to-use ('call this only after they agree'), when-not ('never unlock on your own initiative or to answer a general question'), a required precondition (user's RegTail account linked), and the repeat-call rule. Nothing about invocation timing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advice for viewing an unlocked car in person: a summary, priorities to check (each with why and the report records behind it) and known weak spots of the model. Needs the user's RegTail account linked and the plate unlocked; never spends.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | UK registration plate, any spacing or case, e.g. 'AB12 CDE' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds value the annotations do not: the prerequisite state (account linked, plate unlocked) and the billing behavior ('never spends'), which is exactly the kind of context an agent needs before invoking.
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 sentences, zero filler. The output contents lead and the gating prerequisites plus cost behavior are compressed into the tail, so the most decision-relevant facts are front-loaded.
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?
An output schema exists, so return shape needn't be explained, yet the description still previews the payload's structure. Prerequisites, cost, and scope are all present; nothing an agent needs to call this correctly 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?
Only one parameter, and the schema already documents it fully at 100% coverage, including UK plate format and spacing/case tolerance. The description adds no syntax or format detail 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?
Names a specific deliverable (advice for viewing a car in person) and enumerates its parts: summary, prioritized checks with rationale and backing report records, and known model weak spots. An agent can distinguish this from decode_plate, full_report, or unlock_report 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?
States the operative context (in person) and the prerequisites that gate use: the RegTail account must be linked and the plate already unlocked. It does not, however, name a sibling or say what to call instead when the plate is still locked, so the routing is implied rather than explicit.
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.
credits_balancedecode_platefree_checkfull_reportmy_reportssample_reportunlock_reportviewing_adviceUK used cars: road tax (VED), ULEZ charges, MOT dates, DVSA reliability, live dealer stock.
UK MOT failure data and official UK, French, Japanese and EU vehicle recalls.
Real UK MOT failure data by car model and mileage, aggregated from official DfT test results.
UK vehicle MOT status and full MOT history from official DVSA data, by registration.
Add one secure layer between your agents and this server.