Autoza UK

Work out MOT due date

check_mot_due_date

Read-only

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 the third anniversary of registration, then annually. Northern Ireland is tested by the DVA, where the first test is not due until 4 years old. Test up to one calendar month minus a day before the current certificate expires and the renewal date is kept; test earlier and it resets. Pass first_registered for a car that has never had an MOT, or mot_expires for one that has. If first_registered puts the first test in the past, the response says so and points to the car's MOT record rather than giving a due date. Use for questions about MOT due dates, MOT timing, or when a car needs testing.

Input Schema

TableJSON Schema

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.

Output Schema

TableJSON Schema

Name	Required	Description
`rule`	Yes
`_note`	Yes	Where the figures come from: Autoza, prices in GBP, distances in miles.
`rule_source`	No
`next_mot_due`	No	The date the current MOT expires (YYYY-MM-DD)
`first_mot_due`	No	First MOT due, for a car that has not had one yet (YYYY-MM-DD)
`tell_the_user`	No
`max_test_fee_gbp`	Yes
`first_mot_was_due`	No	When the first MOT fell due, when that is already in the past (YYYY-MM-DD)
`max_test_fee_scope`	Yes
`penalty_for_no_mot`	No
`first_mot_already_passed`	No
`next_anniversary_guide_only`	No	The next anniversary of that first due date. A guide, not the real expiry (YYYY-MM-DD)
`earliest_test_keeping_that_date`	No	The earliest a test keeps the same renewal date (YYYY-MM-DD)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "_note": {
+      "description": "Where the figures come from: Autoza, prices in GBP, distances in miles.",
+      "type": "string"
+    },
+    "earliest_test_keeping_that_date": {
+      "description": "The earliest a test keeps the same renewal date (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "first_mot_already_passed": {
+      "type": "boolean"
+    },
+    "first_mot_due": {
+      "description": "First MOT due, for a car that has not had one yet (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "first_mot_was_due": {
+      "description": "When the first MOT fell due, when that is already in the past (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "max_test_fee_gbp": {
+      "type": "number"
+    },
+    "max_test_fee_scope": {
+      "type": "string"
+    },
+    "next_anniversary_guide_only": {
+      "description": "The next anniversary of that first due date. A guide, not the real expiry (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "next_mot_due": {
+      "description": "The date the current MOT expires (YYYY-MM-DD)",
+      "type": "string"
+    },
+    "penalty_for_no_mot": {
+      "type": "string"
+    },
+    "rule": {
+      "type": "string"
+    },
+    "rule_source": {
+      "type": "string"
+    },
+    "tell_the_user": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "rule",
+    "max_test_fee_gbp",
+    "max_test_fee_scope",
+    "_note"
+  ],
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare a safe read operation; the description goes well beyond that with domain behavior: the third-anniversary/annual rule, the NI four-year first test, the 'one calendar month minus a day' retention rule and its reset consequence, and the fallback that returns a pointer to the MOT record rather than a due date when first_registered is in the past.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded and every sentence carries information, but the middle section is dense with stacked clauses and jurisdiction caveats, making it slightly heavier than needed for a two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 described. Given that, the description covers the remaining gaps an agent needs: jurisdiction rules, which parameter applies to which situation, the renewal-date consequence, and the fallback behavior when no due date can be produced.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 schema already documents ISO format and which param suits an MOT'd vs non-MOT'd car. The description reinforces this routing and adds genuinely new semantics around the past-first_registered edge case, pushing it modestly above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Work out when a car's MOT test is due') and immediately adds the second capability (earliest testable date that preserves renewal). It is clearly distinct from siblings like mot_outlook, calculate_car_tax, and get_uk_price_guide without the agent needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to use each input ('Pass first_registered for a car that has never had an MOT, or mot_expires for one that has') and names the triggering question types ('MOT due dates, MOT timing, or when a car needs testing'). It also scopes the jurisdiction (GB/DVSA vs NI/DVA), removing ambiguity about applicability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Autoza UK tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?