MOT Check

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 context beyond that: the data source (official DVSA records), the UK/Northern Ireland-only boundary, and the derived mileage-decrease check that flags potential clocking — a non-obvious analytic an agent should know it gets for free.

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 the critical constraint ('UK-registered vehicles only') and the data source before the resource detail. The trailing list of six example queries is longer than strictly necessary and slightly redundant with the body, costing a point.

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 explain the return shape, and it does: per-test date, result, mileage, advisories, defects, failures, plus the mileage-anomaly indicator. Scope restrictions are stated, so an agent has everything needed to call it and interpret the response.

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 the single 'registration' param is thoroughly documented in-schema (case/space insensitivity, GB/NI-only). The description only reinforces the UK-registration restriction, which is already in the schema, so it adds marginal value. Baseline 3 applies when the schema carries the parameter burden.

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 (get) and resource (full MOT test history) and enumerates exactly what is returned — every test with date, result, recorded mileage, advisories, minor defects and failures. That content detail is enough to distinguish it from get_mot_status (a status checker) without naming the sibling, so the agent can route correctly.

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?

Six concrete example queries ('why did it fail its MOT', 'what were the advisories', 'has it been clocked') map clearly onto when to reach for this tool, and 'UK-registered vehicles only' sets a hard scope. It stops short of naming the alternative tools (get_mot_status / lookup_vehicle) or stating when-not-to-use, so it does not reach a 5.

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

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description adds genuinely non-obvious context beyond that: DVSA is the authoritative source, coverage is UK (GB/NI) only, and the special sentinel status first_mot_not_due carries a non-intuitive meaning for expiry_date. That domain-specific caveat is exactly the kind of value annotations cannot express.

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-loads the hard constraint ('UK-registered vehicles only') and then flows into return values before the example queries. The long quoted-query list is somewhat padded, but each phrase maps to a distinct intent, so it largely 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?

There is no output schema, so the description must explain what comes back — and it does: status, expiry date, days remaining, and last-test result, mileage, advisories and defects. Combined with the sentinel-status explanation and UK-only scope, an agent has everything needed to call and interpret this 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% and the single registration parameter is fully documented in the schema, including case/space normalization and GB/NI scoping. The description restates the UK-only constraint but adds no new syntax or format detail. Baseline 3 is appropriate when the schema already 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+resource: the current MOT status of a UK car, van or motorbike, plus expiry date, days remaining, and last-test result. It enumerates the returned fields precisely, which implicitly separates it from get_mot_history (full past tests) and lookup_vehicle (vehicle attributes). An agent can distinguish it from its 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?

The trailing queries ('when is my MOT due', 'has my MOT expired', 'did it pass its last MOT') give concrete triggering conditions that map to real user phrasing. It also scopes the tool to UK-registered vehicles only. It stops short of explicitly naming when to prefer get_mot_history or lookup_vehicle instead, so it lands at a strong 4 rather than 5.

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

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered; the description adds genuinely new context on top, namely the upstream data sources (DVSA, DVLA, HPI) and the hard coverage boundary (GB/NI only, other countries will not be found). It stops short of noting any rate limiting or failure modes for unknown plates, which would have pushed it higher.

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 important constraint (UK-only) is front-loaded, followed by sources, returned fields, and routing cues in a logical order. The seven-phrase example list is longer than strictly necessary but earns part of its space as query-matching vocabulary; the last set of quoted examples could be trimmed.

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 correctly compensates by enumerating the returned fields, and it covers scope, data provenance, and invocation triggers. The one remaining gap for a tool that sits beside two MOT-focused siblings is the absence of a handoff rule telling the agent when to prefer get_mot_history or get_mot_status.

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 the registration parameter is already richly documented (spaces/case do not matter, GB or NI only), so the baseline is 3. The description adds synonym coverage ('number plate, reg, registration') and the 'UK-registered vehicles only' constraint at tool level, which helps the agent map informal user phrasing onto the single parameter.

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?

It names a specific verb and resource ('look up a UK number plate') and enumerates exactly what comes back: make, model, colour, year, fuel type, age, MOT validity/expiry, and tax status/due date. It also frames itself as 'the best first call for any general question', which implies a division of labour with its MOT-specific siblings, but it never names get_mot_status or get_mot_history, so the differentiation stays implicit.

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 well signposted with seven concrete trigger phrasings ('what car is wr25vup', 'is it taxed', 'is it road legal'), giving the agent strong positive context for when to invoke it. What's missing is the negative case: there is no statement that detailed MOT test records or a narrow MOT-status check should be routed to get_mot_history or get_mot_status instead, despite significant field overlap.

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