UK used cars: road tax (VED), ULEZ charges, MOT dates, DVSA reliability, live dealer stock.
Scored across 7 tools
Each tool targets a distinct UK car ownership question: tax, clean air zones, MOT timing, running costs, reliability, price guidance, and live listings. Even the two cost-related tools (tax vs running costs) have clear boundaries.
All tools follow a consistent snake_case verb_noun pattern: calculate_, check_, estimate_, get_, search_. The two 'check_' tools differ by object ('clean_air_zone' vs 'mot_due_date'), so there is no ambiguity.
Seven tools is well-scoped for a UK used-car marketplace and ownership advisor. Each tool covers a meaningful need without bloat or redundancy.
The surface covers the full buyer journey: search cars, check price, estimate running costs, assess reliability, verify MOT timing, and understand tax/emission charges. No obvious dead ends or missing lifecycle steps for the stated purpose.
Calculate annual UK vehicle tax (VED / road tax) for any car. Handles all three UK systems: cars registered before March 2001 (taxed on engine size), March 2001 to March 2017 (CO2 bands, £20–£790), and April 2017 onward (flat standard rate). Also works out the Expensive Car Supplement: over £40,000 list price when new for petrol, diesel and alternative fuel; over £50,000 for a zero-emission car first registered on or after 1 April 2025; and no supplement at all for a zero-emission car first registered before 1 April 2025, whatever it listed for. Pass registration_date as well as registration_year when you have it — the boundaries are dates, and the year alone cannot separate a March 2025 registration from an April one. Use this for any question about UK car tax, road tax, VED, or how much it costs to tax a specific car.
| Name | Required | Description | Default |
|---|---|---|---|
| co2 | No | CO2 emissions in g/km. Required for cars registered March 2001–March 2017; ignored for pre-2001 cars. | |
| fuel | Yes | Fuel type. Use "alternative" for hybrid/LPG, "diesel-rde2" only for diesels meeting RDE2. | |
| engine_size_cc | No | Engine size in cc. Only used for cars registered before March 2001. | |
| registration_date | No | Full date of FIRST registration as YYYY-MM-DD, from the V5C. Optional but strongly preferred: every UK VED boundary is a date (1 March 2001, 1 April 2017, 1 April 2025), so the year alone cannot tell a zero-emission car registered 1 March 2025 (no Expensive Car Supplement) from one registered 1 April 2025 (supplement). Without it, an ambiguous case is answered with a caveat in notes rather than a figure. | |
| registration_year | Yes | Year the car was FIRST registered (not the year it was bought). This decides which tax system applies and is the single most important input. | |
| list_price_when_new | No | Original list price in GBP when the car was new. Needed only to work out the Expensive Car Supplement — based on the price when NEW, not what you pay for it used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior, and it does so thoroughly: it explains regime boundaries, the zero-emission-car exception, and the caveat about ambiguous cases. It doesn't mention that this is a pure read/calculation operation with no side effects, but for a calculator-style tool the disclosed edge-case handling is what matters most.
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 description is long, but every sentence earns its place by specifying regime boundaries, edge cases, and parameter intent. It front-loads the purpose and then details exceptions; a tighter structure would group the tax regimes more cleanly, 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?
Given six parametersament, no annotations, and no output schema, the description covers the main behavioral surface: regimes, exceptions, and date guidance. It doesn't state the return shape or currency formatting, which would help an agent consume the result, but for a calculation tool the coverage is strong.
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 high (every parameter has a description), yet the tool description still adds real semantic value: it explains that registration_year alone is insufficient in edge cases, that engine_size only applies to pre-2001 cars, that the expensive car threshold differs for zero-emission vehicles, and that list_price_when_new means original new price, not current market value. This goes beyond the schema.
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 states a specific verb, object, and scope: 'Calculate UK car tax (VED / road tax)' and immediately names the alternatives. The breakdown of the three tax regimes makes it unambiguous which calculation applies. This is a model of purpose clarity.
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 description gives explicit instruction on when to use the tool ('use this for any question about UK car tax') and even tells the agent to pass registration_date when available to disambiguate edge cases. It doesn't name sibling tools or exclusion conditions, but the guidance is clear enough for routing and invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a car is compliant with UK clean air zones (London ULEZ, Birmingham, Bristol) and what it would cost to drive into them. Returns compliance, the daily charge per zone, and estimated annual cost. Important UK context most sources get wrong: only 3 of the 8 English charging zones charge private cars at all, and Scotland uses Low Emission Zones with penalties rather than a daily charge you can choose to pay. Use for any ULEZ, CAZ, clean air zone, or emissions-charge question.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel | Yes | Fuel type. | |
| days_per_year | No | Days per year the driver would enter a charging zone. Defaults to 250 (a daily commute). | |
| registration_year | Yes | Year the car was first registered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so well: it states what is returned (compliance, daily charge, estimated annual cost) and adds important UK-specific context about which zones charge private cars and how Scotland handles low emission zones. It does not describe edge cases or calculation assumptions in detail, but the core behavior is transparent.
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 with no fluff. The primary action is front-loaded, return values are stated, and the crucial UK context is included in a compact but valuable sentence. Every sentence 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?
The description is complete for selecting and invoking the tool: it names the zones, states the outputs, and provides important domain context that prevents misuse. Despite lacking an output schema, the return types are explicitly described, and the parameter schema covers the inputs.
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 the schema already documents all parameters. The description adds contextual meaning by tying compliance and cost to the tool's purpose, but it does not specifically explain how registration_year, fuel, and days_per_year map to the results. 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?
The description names a specific action (check compliance and cost) on a specific resource (UK clean air zones) and explicitly names the zones covered. It clearly distinguishes itself from the sibling cost and tax tools by focusing on emissions zones rather than general running costs or tax.
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 description explicitly states 'Use for any ULEZ, CAZ, clean air zone, or emissions-charge question,' giving clear when-to-use guidance. It does not mention when not to use it or name explicit alternatives, but the sibling tools are unrelated enough that this is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out when a car's MOT test is due, and the earliest date it can be tested without losing its renewal date. These are Great Britain (DVSA) rules: a car's first MOT falls on its third anniversary of registration, then annually. Northern Ireland is tested by the DVA, where the first test is not due until four years old. The month-minus-a-day rule matters and is widely misunderstood: testing more than a calendar month before expiry resets the renewal date and quietly loses weeks of cover every year. Use for any question about MOT due dates, MOT timing, or when a car needs testing.
| Name | Required | Description | Default |
|---|---|---|---|
| mot_expires | No | Date the current MOT expires, ISO format YYYY-MM-DD. Use this for a car that already has an MOT. | |
| first_registered | No | Date the car was first registered, ISO format YYYY-MM-DD. Use this for a car that has never had an MOT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It transparently explains the GB vs NI rules, the month-minus-a-day pitfall, and the consequence of testing too early ('quietly loses weeks of cover'). It does not describe the output format or error handling, but for a date-calculating tool the key behavioral nuances are disclosed.
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 description is efficiently structured: it states the core purpose first, then explains the regional rules and the critical pitfall, and ends with a clear usage directive. Every sentence earns its place, though it is slightly longer than necessary for a simple date tool. Front-loading is effective.
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?
The tool has moderate complexity due to regional variation and the month-minus-a-day subtlety, all of which the description covers. The schema fully documents both parameters, and the description explains the rules that govern their use. No output schema exists, but the return value (dates) is inferable. It lacks explicit handling of edge cases like expired MOT, but the described scenarios are complete for typical use.
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 schema description coverage is 100%, so both parameters already have thorough descriptions. The tool description adds contextual rules (GB/NI) that help interpret which parameter to use, but it doesn't add parameter-specific semantics beyond what the schema provides. Baseline of 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?
The description opens with a specific verb ('Work out') and resource ('when a car's MOT test is due'), and immediately clarifies it also returns the earliest safe test date. It explicitly distinguishes from sibling tools like calculate_car_tax and check_clean_air_zone by focusing on MOT timing. The scope is unambiguous.
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 states 'Use for any question about MOT due dates, MOT timing, or when a car needs testing,' which is a clear directive. It doesn't explicitly exclude other tools or name alternatives, but the sibling list shows unrelated topics (tax, emissions, pricing), so the usage context is effectively clear. Lacking an explicit 'do not use for X' costs one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate what a specific car on Autoza actually costs to own for a year — road tax, fuel, servicing, MOT and insurance, plus three-year depreciation where it can be worked out. Pass the listing URL or id returned by search_used_cars. This answers the question buyers actually have ("what will this cost me?") rather than just the sticker price. Components that cannot be worked out from the listing are omitted rather than guessed, and the response says which.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | No | Listing id, if you have it instead of the URL. | |
| listing_url | No | Full autoza.co.uk listing URL as returned by search_used_cars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden—and it does so well. It discloses that components that cannot be worked out are 'omitted rather than guessed' and that the response will say which are omitted. It also states the condition 'where it can be worked out' for depreciation, giving the agent insight into fallback behavior.
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 with no redundancy: the first states the core function, the second gives input guidance, and the third covers the value proposition and fallback behavior. It is front-loaded with the main purpose and every sentence 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?
For a no-output-schema estimation tool, the description covers the key context an agent needs: what is estimated, how to obtain inputs, and how incomplete data is handled. It does not describe the exact output structure (e.g., itemized breakdown vs. total), but the mention that the response says which components are omitted partially compensates for that 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 100%, so baseline is 3, but the description adds useful semantic context by explaining that listing_id and listing_url are alternative inputs and that both come from search_used_cars. This resolves any ambiguity about which parameter to pass and reinforces the relationship between the two parameters.
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?
Description states a specific verb ('Estimate') and resource ('what a specific car on Autoza actually costs to own for a year'), then enumerates the cost components: road tax, fuel, servicing, MOT, insurance, and three-year depreciation. It differentiates from siblings by framing the tool as answering the buyer's total-cost question 'rather than just the sticker price', and explicitly references search_used_cars as the source of its input.
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 invocation guidance: 'Pass the listing URL or id returned by search_used_cars.' This clarifies both what input to use and where it comes from. It does not explicitly list when to prefer this over related tools like calculate_car_tax, but the aggregate-vs-single-component framing makes the use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get known common faults, best and worst model years, and real DVSA MOT first-time pass rates for a specific used car model in the UK. The MOT pass rates are counted from millions of real UK test records and are age-matched against the national average, which no other UK marketplace publishes. Use when someone asks whether a specific model is reliable, what goes wrong with it, which year to buy or avoid, or what to check before buying one.
| Name | Required | Description | Default |
|---|---|---|---|
| model_slug | No | Model identifier, e.g. "ford-focus-common-faults-uk". Call with no argument to list every available model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the data source (real DVSA MOT records, millions of tests), the age-matching methodology, and what categories of results are returned. It does not mention edge cases like unknown slugs or the no-argument listing behavior, but the schema covers listing behavior and the data provenance adds meaningful transparency.
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, with the first sentence front-loading the core purpose and outputs. The second sentence adds authority and uniqueness, and the third delivers clear usage triggers. The uniqueness claim is slightly promotional but still relevant for tool selection.
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-optional-parameter read-only lookup with no output schema, the description covers what the tool returns, the scope, the data source, and when to invoke it. It does not specify return formatting or unknown-model behavior, but these are minor given the simplicity of the tool and the complete schema.
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 schema fully documents the only parameter, model_slug, including an example format and no-argument listing behavior. The description aligns with this by saying 'specific used car model' but adds no parameter-level detail beyond the schema, so the baseline of 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 ('Get'), a specific resource (used car model reliability in the UK), and concrete outputs: common faults, best/worst years, and DVSA MOT first-time pass rates. This clearly differentiates it from siblings focused on tax, MOT due dates, running costs, price guides, and car search.
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 description explicitly states when to use the tool: when someone asks whether a model is reliable, what goes wrong, which year to buy or avoid, or what to check before buying. It does not explicitly name alternatives or exclusions, but the sibling names and the focused reliability context make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current UK used-car asking-price guidance from live verified-dealer listings — typical, lowest and highest asking price, optionally narrowed to a make or model. Prices are GBP and reflect what dealers are asking right now, not trade or valuation estimates. Use to answer "what do X cost used in the UK" or to sanity-check whether an advertised price is reasonable.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Optional: narrow to a manufacturer. | |
| model | No | Optional: narrow to a model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job: it discloses the data source (live verified-dealer listings), the metric types (typical, lowest, highest), the currency (GBP), and crucially what the prices are not (trade or valuation estimates). It could add more on freshness or output shape, but the core behavioral traits are transparent.
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, all earning their place: the first states the function and outputs, the second clarifies currency and semantics, and the third gives concrete use cases. It is front-loaded and has no 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 simple two-optional-parameter tool with no output schema, the description is complete: it tells the agent what the tool returns, the source of the data, the unit, the optional narrowing behavior, and practical invocation scenarios. Nothing an agent needs to decide whether to call it 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%, so the baseline is 3. The description adds 'optionally narrowed to a make or model,' which mirrors the schema rather than adding new semantic depth. It does not explain edge cases like providing only a model, but the schema already documents the parameters adequately.
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 uses a specific verb-resource pair ('Get current UK used-car asking-price guidance') and clearly differentiates from siblings by specifying that it returns typical, lowest, and highest asking prices from live dealer listings, not trade or valuation estimates. This makes it easy for an agent to distinguish from search_used_cars and other sibling tools.
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 description gives explicit use cases: answering 'what do X cost used in the UK' and sanity-checking advertised prices. It does not explicitly contrast with sibling tools or state when not to use it, but the intended context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live used cars for sale from verified UK dealers on Autoza, with real current asking prices in GBP and mileage in miles. Returns a canonical autoza.co.uk URL for each car. Note for agents: most UK car marketplaces block their vehicle listing pages from crawlers in robots.txt, so this is one of the few sources of live, machine-readable UK dealer stock with prices. Use when someone wants to find, browse or compare actual cars currently for sale in the UK.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Manufacturer, e.g. "BMW", "Ford". | |
| limit | No | Max results, 1–25. Defaults to 10. | |
| model | No | Model name, e.g. "Focus", "3 Series". | |
| location | No | UK city or region, e.g. "Manchester", "Belfast". | |
| max_year | No | ||
| min_year | No | ||
| body_type | No | e.g. "hatchback", "estate", "suv", "saloon". | |
| fuel_type | No | e.g. "petrol", "diesel", "electric", "hybrid". | |
| max_price | No | Maximum price in GBP. | |
| min_price | No | Minimum price in GBP. | |
| transmission | No | e.g. "manual", "automatic". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does substantial work: it discloses that the source is verified UK dealers, that prices are live/current, that mileage is in miles, that each result includes a canonical URL, and that this source is one of the few machine-readable options due to robots.txt blocking elsewhere. It stops short of describing result structure or pagination behavior, but for a search tool this is solid.
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 front-load the core purpose, then add output format and usage context. It is appropriately sized, with only minor redundancy between 'live', 'real', and 'actual cars'.
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 an 11-parameter tool with no output schema and no annotations, the description covers the key facts an agent needs: source, data quality, units, URL return value, and when to use it. The main omission is a clearer picture of the full result payload and default ordering/pagination, but these are not critical for invocation.
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 82%, so the schema already documents most parameters with examples. The description reinforces the GBP unit for prices but does not add meaning for the undocumented max_year/min_year parameters, so it stays at the baseline without compensating.
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 begins with a specific verb and resource: 'Search live used cars for sale from verified UK dealers on Autoza', with concrete output details (prices in GBP, mileage in miles). It clearly differentiates itself from sibling tools like get_uk_price_guide by emphasizing actual cars currently for sale.
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 someone wants to find, browse or compare actual cars currently for sale in the UK.' It does not explicitly name when-not-to-use cases or point to alternative siblings, though the use-case sentence makes the boundary clear.
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.
calculate_car_tax1 field changedInput schema / properties / registration_dateAdded value: +{
+ "description": "Full date of FIRST registration as YYYY-MM-DD, from the V5C. Optional but strongly preferred: every UK VED boundary is a date (1 March 2001, 1 April 2017, 1 April 2025), so the year alone cannot tell a zero-emission car registered 1 March 2025 (no Expensive Car Supplement) from one registered 1 April 2025 (supplement). Without it, an ambiguous case is answered with a caveat in notes rather than a figure.",
+ "type": "string"
+}calculate_car_taxcheck_clean_air_zonecheck_mot_due_dateestimate_running_costsget_model_reliabilityget_uk_price_guidesearch_used_carsUK vehicle MOT status and full MOT history from official DVSA data, by registration.
UK tolls & charges: DVLA vehicle checks (ULEZ/CAZ/MOT/tax), prices, penalties, pay-by deadlines.
Real UK MOT failure data by car model and mileage, aggregated from official DfT test results.
Mechanic-grade used-car listing verdicts: risk score, failure points, repair costs, fair price.
Add one secure layer between your agents and this server.
