UK car reliability from real MOT results: first-time pass rates by make, model and number plate.
Scored across 4 tools
Each tool targets a distinct level of the domain: make-level aggregation, model-level (with optional year/fuel/engine refinement), a single-vehicle DVSA lookup by plate, and name search. The descriptions explicitly cross-reference each other (search_cars output feeds get_model_reliability/get_make_reliability), so an agent can route unambiguously.
All four names are snake_case verb_noun (get_make_reliability, get_model_reliability, lookup_plate, search_cars). The verbs differ (get/lookup/search) but each accurately reflects the operation, and the resource nouns are predictable.
Four tools is a tight, focused surface for a MOT-reliability domain: discovery, two aggregation levels, and per-vehicle history. It is slightly thin — no comparison or bulk operation — but nothing is redundant.
The surface covers the full user journey from finding a make/model to viewing aggregate grades to looking up a specific car's MOT history. Minor gaps exist (no model-vs-model comparison, no enumerate-all-makes endpoint, no bulk plate lookup), but these are workable via search_cars plus repeated calls.
A make's MOT reliability grade over all its cars, and every graded model of that make ranked by the share of UK cars it beats once age and mileage are taken into account.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | Car make, e.g. Ford, VW or Mercedes-Benz. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-inferable context: the dataset is MOT-based, the ranking is normalized for age and mileage, and each model's rank reflects the share of UK cars it beats. It does not cover what happens for an unknown or ungraded make, but the methodological disclosure is substantive.
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 sentence, front-loaded with the primary return value, with no filler. The second clause is dense and slightly tangled ('ranked by the share of UK cars it beats once age and mileage are taken into account'), but every element carries information.
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 must describe return values; it does so at a high level (a make grade plus a ranked model list) but never indicates the grade's form or the fields per model. For a simple one-parameter read tool with rich annotations this is adequate, though edge cases such as ungraded makes are unaddressed.
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 required parameter with 100% schema description coverage, including concrete examples (Ford, VW, Mercedes-Benz) and length bounds. The description adds nothing about accepted make spelling or normalization, so 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 resource (a make's MOT reliability grade) plus the accompanying per-model ranking, so the agent knows exactly what data comes back. It stops short of explicitly contrasting with the sibling get_model_reliability, and the mention of 'every graded model of that make' could momentarily blur the make-vs-model boundary.
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 when-to-use guidance and no alternative is named; the agent must infer from the name and the sibling list that this is the make-level lookup and get_model_reliability is the per-model one. No prerequisites, exclusions, or fallback behavior are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A model's MOT reliability over all years: grade, first-time pass rate, points above or below a typical car of the same age and mileage, and the share of UK cars it beats. Give year, fuel and/or engine to also get those versions, each with its own grade and the areas where it fails more often than similar cars (weak spots).
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | No | ||
| make | Yes | Car make, e.g. Ford, VW or Mercedes-Benz. | |
| year | No | Year first registered. | |
| model | Yes | Model name, e.g. Fiesta, Golf or Qashqai. | |
| engine | No | Engine size in litres, e.g. 1.0 (or cc, e.g. 999). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's main added value is the non-obvious behavioral point that optional params expand results into per-version breakdowns rather than filtering them, plus the disclosure of weak-spot output. It does not address data recency, coverage limits, or what an unmatched make/model yields.
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, front-loaded with the primary resource and its metrics, then the conditional extension. Dense but every clause carries information; a slight restructuring into a bulleted metric list would improve scannability 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?
With no output schema, the description must carry the return-value burden, and it does so by naming each metric returned, including the qualitative weak-spot sections. Given only 2 of 5 params are required, a brief note on required make/model or on no-match behavior would close the remaining gap.
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 already documents make, model, year and engine. The description nonetheless adds meaning the schema does not: that year/fuel/engine select version-level results, and that each version carries its own grade and failure weak spots. It does not clarify how engine tolerates litres vs. cc beyond the schema's example, or how multiple optional params combine.
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 the specific resource (a car model's MOT reliability, aggregated over all years) and enumerates the returned metrics (grade, first-time pass rate, points vs. typical car, share of UK cars beaten). It implicitly distinguishes itself from get_make_reliability by scoping to a model, but never names that sibling explicitly, so the differentiation requires inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction "Give year, fuel and/or engine to also get those versions" is genuine usage guidance for the optional parameters, and the "also get" phrasing correctly signals additive rather than restrictive behavior. However, there is no statement of when to choose this over get_make_reliability or search_cars, and no guidance on failure cases such as an unknown make/model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One UK car's MOT history from the DVSA by its registration: each test with its result, mileage and defects or advisories, whether its MOT is valid, warnings (mileage going down, gaps with no MOT, an outstanding safety recall) and its model's reliability grade.
| Name | Required | Description | Default |
|---|---|---|---|
| registration | Yes | UK number plate, e.g. AB12 CDE. |
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 real substance beyond that by enumerating the returned payload (per-test result, mileage, defects/advisories, validity, warnings, reliability grade) and naming the upstream source, DVSA. It does not mention error behaviour for unknown plates or rate limits.
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 dense sentence, front-loaded with the core action and resource, with the return payload following in a natural colon-list. No filler, though the length pushes the edge of what a single sentence can carry readably.
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?
There is no output schema, so the description must carry the return-value story — and it does, listing tests, results, mileage, defects, validity, warnings and reliability grade. Missing only edge-case behaviour (no data for a plate, invalid formats) for full completeness.
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 a single parameter at 100% schema coverage, the schema already documents the registration format and example. The description's 'by its registration' and 'UK car' add country/entity framing but no format, normalization or validation detail beyond what the schema states.
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+resource+scope: MOT history for one UK car, looked up by registration, sourced from the DVSA. It is clearly distinguishable from search_cars (finding cars) and the reliability siblings (which the description treats as a field of this result rather than a separate lookup), though it never names those alternatives explicitly.
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 'by its registration' and 'One UK car' — the singular, plate-keyed framing signals a per-vehicle lookup. There is no explicit when-to-use/when-not guidance or statement of what to call instead when the plate is unknown or a broader search is wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find UK car makes and models by name, e.g. "Fiesta", "Toyota Yaris" or "Kia". Returns up to 10 matches with their MOT reliability grade, first-time pass rate and the share of UK cars they beat, for get_model_reliability or get_make_reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Make and/or model name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: a hard cap of 10 matches and the exact fields returned (MOT reliability grade, first-time pass rate, share of UK cars beaten).
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 sentence, front-loaded with the lookup purpose and examples, ending with the downstream consumer. No filler and nothing an agent needs is buried.
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 of describing results and does so fully (count cap plus the three returned metrics). Scope (UK), input format, and next step are all present for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description earns an extra point by illustrating the accepted query shapes — bare model ("Fiesta"), make plus model ("Toyota Yaris"), and make alone ("Kia") — which clarifies free-text flexibility the schema's 'Make and/or model name' only hints at.
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 (find) and resource (UK car makes and models), supplies concrete query examples, and distinguishes itself from the reliability siblings by framing its output as input to get_model_reliability or get_make_reliability.
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 closing clause makes the workflow explicit: this is the discovery step whose results feed the two reliability tools. It does not state exclusions (e.g. when to use lookup_plate instead), but the intended sequencing is unambiguous.
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.
get_make_reliabilityget_model_reliabilitylookup_platesearch_carsReal UK MOT failure data by car model and mileage, aggregated from official DfT test results.
UK 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.
UK vehicle lookup, MOT status and full MOT history from official DVSA data, by registration.
Add one secure layer between your agents and this server.