UK MOT failure data and official UK, French, Japanese and EU vehicle recalls.
Scored across 9 tools
Each tool is scoped by a clear country prefix plus resource (recalls vs MOT/reliability vs complaints) and action (for_model vs search), so an agent can pick correctly in almost all cases. The main risk is eu_safety_gate_recalls, a non-functional stub that could be selected in place of fr_recalls_for_model for EU questions, and uk_mot_vehicle_search vs uk_recalls_for_model both take make/model text and may briefly confuse.
The set follows a predictable {country}_{domain}_{operation} scheme (fr_recalls_for_model, fr_recalls_search, uk_recalls_search, jp_recalls_for_model), which is easy to scan. Deviations are mild: uk_mot_reliability and jp_complaints_summary are noun-phrase style rather than matching the retry-friendly *_for_model/*_search pattern used elsewhere.
Nine tools is well within a sensible range for a multi-jurisdiction vehicle data server, with lookups and keyword searches pairing cleanly. The only waste is eu_safety_gate_recalls, which occupies a slot while returning covered:false.
Coverage is asymmetric: France and the UK each get both a structured per-model lookup and a cross-brand keyword search, but Japan has only per-model tools (no jp recall keyword search), and the EU path is a dead-end stub. Core recall lookups work, but agents asking cross-brand Japanese questions or expecting EU data will hit gaps.
STUB — not yet live. EU Safety Gate (RAPEX) vehicle alerts are being added; until then this returns covered:false with the official Safety Gate URL and points to fr_recalls_* (RappelConso republishes the Safety Gate automobile alerts that concern France).
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | ||
| model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/non-destructive/openWorld=false), the description discloses the actual runtime behavior an agent cannot infer: the call returns covered:false and an official Safety Gate URL, i.e. it is a deliberate no-op placeholder. That is genuinely useful and consistent with the annotations; no auth, rate-limit or side-effect detail is needed for a stub.
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 'STUB — not yet live', which is the single most decision-relevant fact, followed immediately by the alternative. 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 stub with no output schema, the description covers the essentials: it is not live, what it returns, and where to go instead. The remaining gap is the unaddressed brand/model parameters and any hint of when the stub will become live, but for a placeholder this is close to complete.
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?
Both brand and model are undocumented in the schema (0% coverage) and the description never mentions them, so an agent gets no signal whether they filter, are ignored, or are reserved for the live version. The stub framing mitigates this slightly, but the description does not compensate for the coverage gap as required.
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 exactly what the tool currently is and does: a not-yet-live stub for EU Safety Gate (RAPEX) vehicle alerts that returns covered:false plus the official URL. It names the resource precisely and distinguishes itself from siblings by naming fr_recalls_*. It stops short of 5 only because the eventual retrieval behavior is described prospectively ('are being added') rather than fully defined.
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-not guidance ('not yet live') and routes the agent to an alternative family (fr_recalls_*) with the reason that RappelConso republishes the Safety Gate automobile alerts concerning France. The routing is conditional on the agent needing the data rather than a blanket 'always use X', which keeps it just under a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official French vehicle recall notices (RappelConso, DGCCRF open data; 1663 automobile fiches 2018-01-19 → 2026-08-07) for a brand and model: fiche number, date, risks, defect description (motif, in French), commercialisation periods and the official fiche link. Omit model to list a brand. Matches by a reviewed alias table plus whole-word text match; each fiche says which.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | e.g. peugeot, Mercedes-Benz, VW | |
| model | No | e.g. 208, Classe A, Golf (optional: omit to list the brand) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, not open-world), so the description earns credit for adding non-obvious behavior: matching is done via a reviewed alias table plus whole-word text match, and each fiche reports which method applied. It does not mention result caps or ordering.
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 resource and scope, then the optional-parameter rule, then matching semantics — a logical order with no filler. The parenthetical date/count clause is dense but earns its place as provenance.
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 usefully enumerates the returned fields (fiche number, date, risks, motif in French, commercialisation periods, fiche link) and notes the French-language content. Minor gaps remain around result volume/ordering, but an agent can call this confidently.
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; the description goes beyond it by explaining the semantic consequence of omitting model and by disclosing the alias/whole-word matching strategy that governs how brand and model strings are interpreted.
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 (recall notices for a brand/model) with the exact data source (RappelConso, DGCCRF), coverage window, and the concrete fields returned. The name/title pair 'recalls_for_model' vs. sibling 'fr_recalls_search' is clearly differentiated by the 'for a brand and model' scoping.
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?
Gives a clear operational rule — 'Omit model to list a brand' — which is the main usage fork for this tool. It does not, however, tell the agent when to prefer this over fr_recalls_search or eu_safety_gate_recalls, so the routing decision against siblings is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across all RappelConso automobile fiches (brand, model text, label, defect description, risks), newest first, optionally since a date. Text is French and lowercase ("airbag", "incendie", "takata", "batterie haute tension"). Use for cross-brand questions ("recent EV battery fire recalls in France").
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | words that must all appear, e.g. "airbag takata" | |
| since | No | optional ISO date YYYY-MM-DD — only fiches published on/after it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safe read-only, idempotent, non-destructive behavior, so the description is free to add value: it discloses that results are ordered newest-first, that matching requires all words to appear, and that indexed text is French and lowercase. Pagination/result-count behavior is not mentioned, which is the only real 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?
Compact and front-loaded: scope and searchable fields come first, then ordering and the optional date filter, then the intended use case. Every clause carries information an agent would otherwise have to guess.
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 two-parameter read-only search with no output schema, the description covers scope, fields indexed, language, ordering, date filtering, and intended use. Only result volume/pagination and the returned fiche shape are unaddressed, which is a minor gap given the annotations.
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 both parameters are already documented and the baseline is 3. The description adds genuinely new semantics beyond the schema: the indexed text is French and lowercase, with concrete vocabulary examples ("airbag", "incendie", "takata") that tell the agent what tokens will actually match.
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 verb (keyword search) and a precisely scoped resource (all RappelConso automobile fiches, with the exact fields searched), and it distinguishes itself from the model-specific sibling by framing its use case as cross-brand questions. An agent can tell this apart from fr_recalls_for_model or uk_recalls_search 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 a clear positive trigger ("Use for cross-brand questions") with a concrete example, which implicitly routes model-specific queries to fr_recalls_for_model. However, it never explicitly names the alternative tool or states an exclusion, so the routing is inferred rather than declared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Owner defect reports filed with MLIT's 不具合情報ホットライン (39954 across 313 models): total reports for a model and the breakdown by defective device (brakes, lights, engine, body…) from the newest sample. Reports are unverified owner submissions — compare shapes, not raw counts. Accepts English or Japanese names.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | e.g. honda | |
| model | Yes | e.g. n-box |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful context beyond that: the data source, corpus size (39,954 reports across 313 models), that results come from the newest sample, and an important caveat that reports are unverified owner submissions.
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 front-loaded with the core purpose and return shape, then follows with a caveat and input-language note. It is dense but appropriately sized, with no clearly wasted sentences, though the first sentence is somewhat long.
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 two-parameter summary tool with no output schema, the description explains what is returned, where the data comes from, a key reliability caveat, and the accepted input languages. It is mostly complete, though 'newest sample' could be clearer and no return structure details are given.
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 both required parameters are already documented with examples. The description adds useful semantics by noting that make and model accept either English or Japanese names, which is not captured in the schema examples.
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—owner defect reports filed with MLIT's hotline—and specifies the returned summary: total reports for a model plus a breakdown by defective device. It distinguishes itself from recall-focused siblings implicitly through the complaints framing, though it does not explicitly name or contrast 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?
Usage is implied by the complaint-report domain, and the caution to 'compare shapes, not raw counts' gives interpretive guidance. However, the description does not explicitly state when to use this versus recall or reliability tools, nor does it name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official Japanese recall filings (国土交通省 MLIT; 3283 filings matched to 313 models sold in Japan, incl. Lexus and imports) for a make and model: notification number, date, defective device, affected vehicles, situation and remedy (Japanese originals) and the official filing PDF. Accepts English (Toyota Prius, Honda N-BOX) or Japanese (トヨタ プリウス) names.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | e.g. toyota, Honda, スズキ | |
| model | Yes | e.g. prius, N-BOX, ジムニー |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful context (data source, corpus size, Japanese-original content, official PDF link), but says nothing about behavior when no model matches or how results are ordered/limited.
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 front-loaded sentence with the essential scope first, then supporting detail. The nested parentheses make it dense but nearly every clause (source, corpus size, returned fields, bilingual input) 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?
No output schema exists, and the description enumerates the returned fields (notification number, date, defective device, vehicles, situation/remedy, PDF), which is what an agent needs. Coverage-limit notes are present; only empty-result and volume/pagination behavior 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?
Schema coverage is 100% and both params are required, so the schema carries the basics. The description still adds real value by stating that make/model accept either English ('Toyota Prius') or Japanese ('トヨタ プリウス') names, clarifying the normalization behavior the schema examples only hint 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+resource ('Official Japanese recall filings ... for a make and model') and pins the data source (MLIT, 3283 filings, 313 models) so it is unmistakably distinct from the fr_/uk_/eu_ recall siblings.
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 'for a make and model' framing implies the usage context, but there is no explicit when-to-use/when-not guidance or pointer to alternatives such as jp_complaints_summary or the search-style siblings. The agent must infer that this is the model-scoped lookup versus a free-text search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real UK MOT failure data for a used car: per-category failure rates (overall and interpolated at a given mileage) and the riskiest components with typical failure mileages, for one model generation. Live proxy to whatbreaks.uk (same operator; aggregated from DfT anonymised MOT results). Use when a user is buying, comparing or maintaining a car sold in the UK. If several generations match, the result lists candidates — retry with year or the exact model name.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | e.g. Volkswagen | |
| year | No | optional registration year | |
| model | Yes | e.g. Golf — generation resolved via year | |
| mileage | No | optional current mileage in miles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower, and the description still adds provenance (live proxy to whatbreaks.uk, aggregated from DfT anonymised MOT results) plus the multi-match fallback behavior. It does not mention latency, rate limits, or data recency beyond the source attribution.
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 what the tool returns, then usage context, then the retry hint — three dense sentences with no filler. Slightly packed, but every clause 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?
No output schema exists, and the description compensates by sketching the return shape (per-category rates, riskiest components, typical failure mileages, candidate list on ambiguous generations). Combined with annotations covering the safety profile, an agent has enough to call it correctly, though response format and pagination are unmentioned.
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 real meaning: mileage drives interpolation of failure rates, and year resolves the model generation. That clarifies how the two optional parameters interact with the core result rather than just restating field names.
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: real UK MOT failure data, broken out as per-category failure rates and riskiest components with typical failure mileages, scoped to one model generation. This is clearly distinguishable from sibling tools like uk_mot_vehicle_search and the various recalls 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?
Gives an explicit usage context ('buying, comparing or maintaining a car sold in the UK') and a concrete recovery path when several generations match (retry with year or exact model name). It does not, however, state when NOT to use it or name an alternative sibling, so routing between this and uk_mot_vehicle_search is still partly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 530 UK model generations covered by the MOT dataset by free text (e.g. "focus", "golf"). Use to check coverage or disambiguate a generation before uk_mot_reliability. Live proxy to whatbreaks.uk.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | free-text query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the dataset's fixed scope (530 generations) and the fact that it is a live proxy to whatbreaks.uk, implying an external call with potential latency.
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 tight sentences with no filler; the scope and examples are front-loaded, and the downstream-tool relationship comes last where it reads naturally.
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-parameter read-only search this covers purpose, scope, usage and external dependency adequately, and no output schema means return values needn't be described. It would be stronger if it hinted at what the result contains (generation names/IDs needed to feed uk_mot_reliability).
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 100% schema coverage the baseline is 3, and the description adds real meaning by giving example queries ("focus", "golf") and clarifying that the free text matches against model generations rather than arbitrary fields. It still doesn't note matching rules (partial match, case sensitivity, aliases).
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 (search) and resource (530 UK model generations in the MOT dataset) with concrete query examples. It also distinguishes itself from the sibling uk_mot_reliability by framing this as the coverage/disambiguation step that precedes it.
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?
"Use to check coverage or disambiguate a generation before uk_mot_reliability" explicitly gives the condition for choosing this tool and names the downstream tool. It does not spell out when not to use it or contrast it with the other search siblings (e.g. uk_recalls_search), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official UK vehicle safety recalls (DVSA, Open Government Licence; 4876 recalls launched 2016-01-01 → 2027-02-03, 272 makes) for a make and model: recall number, launch date, concern, defect and remedy text (DVSA's English originals), build-date range, vehicles affected and a GOV.UK recall-checker link. Omitting model lists the make's recalls and model names. "Vauxhall Corsa", "vauxhall corsa" and "VAUXHALL CORSA" resolve identically; "Mercedes-Benz", "VW" and "Land Rover" are understood. Covers cars, vans, HGVs, buses, motorcycles, trailers and components, not individual VINs.
| Name | Required | Description | Default |
|---|---|---|---|
| make | Yes | e.g. Vauxhall, Mercedes-Benz, VW, Land Rover | |
| model | No | e.g. Corsa, A Class, Golf (optional: omit to list the make) | |
| since | No | optional ISO date YYYY-MM-DD — only recalls launched on/after it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial extra context: data provenance and licence (DVSA, Open Government Licence), dataset scale and coverage window (4876 recalls, 2016→2027, 272 makes), case-insensitive and alias normalization behaviour, and the explicit exclusion of VIN-level lookups. This is rich behavioural disclosure beyond structured fields.
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?
Dense but front-loaded — the core purpose and return fields come first, then normalization and scope notes. Slightly overpacked with parenthetical detail, but nearly every clause carries information an agent needs.
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 compensates by enumerating the returned fields and linking them to a GOV.UK checker. Combined with the coverage window and scope exclusions, an agent has everything needed to call this 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it documents normalization ('Vauxhall Corsa', 'vauxhall corsa', 'VAUXHALL CORSA' resolve identically; 'Mercedes-Benz', 'VW', 'Land Rover' understood) and the effect of omitting model. The 'since' parameter is only indirectly covered via the launch-date window.
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: 'Official UK vehicle safety recalls (DVSA...)' for a make and model, and enumerates the exact fields returned (recall number, launch date, concern, defect, remedy, build-date range, vehicles affected, GOV.UK link). It is immediately distinguishable from sibling tools like uk_mot_reliability and uk_mot_vehicle_search by domain.
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?
Gives clear conditional guidance: 'Omitting model lists the make's recalls and model names' and bounds the tool's scope ('not individual VINs'). However, it never names or contrasts the closest sibling, uk_recalls_search, so the agent must infer which recall tool to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across all served DVSA recalls (make, model names, concern, defect and remedy text), newest first, optionally since a date. Text is English ("airbag", "fire", "steering rack", "takata", "high voltage battery"); every word must appear. Suited to cross-make questions such as recent EV battery fire recalls in the UK.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | words that must all appear, e.g. "airbag takata" | |
| since | No | optional ISO date YYYY-MM-DD — only recalls launched on/after it |
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 real operational context the annotations lack: results are ordered newest first, matching is conjunctive (every word must appear), and the corpus is English-language DVSA text. Pagination/result limits are not 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?
Three sentences, front-loaded with the core behavior before the examples. The example keywords (
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 two-parameter search tool with no output schema, the description covers scope, matching semantics, language, ordering and a usage scenario. It omits result-count limits, pagination and how matches on different fields are weighted, which an agent would want before relying on it.
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 both parameters are already documented ('words that must all appear', 'only recalls launched on/after it'). The description reinforces the AND semantics and date scoping but adds no syntax 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?
States a specific verb (keyword search) over a named resource (all served DVSA recalls) and enumerates the searched fields (make, model, concern, defect, remedy). The 'all served / cross-make' framing implicitly distinguishes it from the sibling uk_recalls_for_model, which is model-scoped.
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?
Gives a concrete use case ('cross-make questions such as recent EV battery fire recalls in the UK'), which tells the agent when this tool fits. It does not explicitly name uk_recalls_for_model as the narrower alternative or state exclusions, so it stops short of full routing guidance.
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.
eu_safety_gate_recallsfr_recalls_for_modelfr_recalls_searchjp_complaints_summaryjp_recalls_for_modeluk_mot_reliabilityuk_mot_vehicle_searchuk_recalls_for_modeluk_recalls_searchNHTSA & EU car recalls, UK MOT stats, EU car specs/WLTP CO2, EU VAT (VIES), LEI & Cyprus companies
Real UK MOT failure data by car model and mileage, aggregated from official DfT test results.
UK vehicle lookup, MOT status and full MOT history from official DVSA data, by registration.
UK used cars: road tax (VED), ULEZ charges, MOT dates, DVSA reliability, live dealer stock.
Add one secure layer between your agents and this server.