Check an Australian vehicle for open safety recalls by VIN. The index mirrors the federal vehicle recall register: 5,587 notices and 8.8 million VINs, refreshed hourly. Look up one VIN, check a batch, search by make and model, or read the full notice. Free, read-only, no authentication.
Scored across 4 tools
Each tool targets a distinct access path: single recall by notice number, single VIN, batch VIN, and attribute-based search. The single-vs-batch pair (lookup_vin/lookup_vins) is explicitly clarified by descriptions, so misselection risk is low. search_recalls even states it returns summaries only, deferring full text to get_recall, which reinforces the boundary.
All four names follow a consistent snake_case verb_noun pattern (get_recall, lookup_vin, lookup_vins, search_recalls). The only near-duplicate is the intentional singular/plural pair for batch vs single lookup, which is a standard and readable convention.
Four tools is well-scoped for a read-only recall reference database, with no bloat or filler. Each tool covers a distinct query mode (ID, VIN, batch VIN, faceted search) and earns its place.
The surface covers the core retrieval paths for the domain: fetch by recall number, resolve by VIN singly or in batch, and search by make/model/year/date. Minor gaps remain around pagination and enumerating all recalls for a make without other criteria, but agents can work around these via search_recalls.
Return one recall notice: what is defective, the hazard, what the owner should do, and who to contact. found: false means this database has no record under that number.
| Name | Required | Description | Default |
|---|---|---|---|
| recall_number | Yes | The recall number from `search_recalls` or a lookup match, e.g. `REC-006722`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the returned content shape and the `found: false` negative-result semantics, which prevents the agent from treating an empty result as an error. It omits that this is a non-mutating lookup and says nothing about failure modes beyond not-found, keeping it short of a 5.
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, no filler. The positive result shape comes first and the edge case (`found: false`) is front-loaded into the second sentence where it is most likely to be read.
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 justifiably describes return fields and the not-found indicator, which is exactly what an agent needs before calling. The only gap is that it does not describe the shape of a successful response wrapper beyond field contents, but for a one-parameter read tool this is close to sufficient.
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 parameter already has an example (`REC-006722`) and a source pointer, so the schema does the heavy lifting. The description adds nothing about the identifier beyond "that number", 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 and resource ("Return one recall notice") and immediately enumerates the payload (defect, hazard, owner action, contact), which distinguishes it from the sibling search_recalls that would return many. An agent can tell single-record retrieval apart from listing without inspecting either 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?
Usage context is clear but implicit: "one recall" plus the schema note that the number comes from `search_recalls` or a lookup match routes the agent correctly. It does not explicitly say "use this after search_recalls returns a recall number" or name lookup_vin as an alternative source, so the when-not guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an Australian vehicle recall by VIN. status: "recalled" means the VIN appears in the manufacturer's published recall list, with matches. status: "no_record" means this database holds no record for that VIN. There is no "not recalled" answer: a VIN we do not hold is not a vehicle free of recalls.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | The 17-character VIN to look up. Case-insensitive; VINs never contain I, O or Q. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does real work: it defines the two possible status values and explicitly warns there is no 'not recalled' answer. That negative-result caveat is exactly the kind of behavior an agent would otherwise misread. It stops short of stating read-only safety or error behavior for malformed VINs, so not a 5.
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 tight sentences, front-loaded with the action, then the result semantics. Every sentence carries information; only mild redundancy between the 'no_record' definition and the closing caveat.
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 return values, and it does cover status and the matches field. It does not describe the shape of individual match entries, leaving a small gap for a tool with no output 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?
Schema coverage is 100% and the vin parameter is fully documented, including length and forbidden characters. The description adds no syntax or format guidance 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 and resource: look up an Australian vehicle recall by VIN. The scope (Australian recalls) is precise, but nothing distinguishes it from the sibling lookup_vins, which an agent would reasonably read as a batch variant of the same lookup.
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 single-VIN framing, but there is no explicit statement of when to prefer this over lookup_vins (many VINs) or get_recall. The agent must infer the routing from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a batch of Australian vehicle recalls by VIN. Each result carries status: "recalled" with matches, or status: "no_record". There is no "not recalled" answer: a VIN we do not hold is not a vehicle free of recalls. One invalid VIN is reported in its own result instead of failing the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| vins | Yes | VINs to look up, in the order answers should come back. At most 10 per call. Case-insensitive; a VIN is 17 characters and never contains I, O or Q. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the two possible result statuses, the critical caveat that absence of a record is not evidence of no recall, and per-VIN error containment rather than whole-batch failure. It omits any note on auth, rate limits, or what `matches` contains, but the core behavioral contract is clear.
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?
Four short sentences, front-loaded with purpose, then the result contract, then the interpretive caveat, then error behavior. Nothing is redundant and each sentence carries a distinct, actionable 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?
There is no output schema, and the description steps in to describe the return shape (`status: "recalled"` with `matches`, or `no_record`) along with per-VIN error behavior. What remains unstated — pagination, rate limits, contents of `matches` — is minor for a bounded 10-VIN batch read 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 `vins` parameter already documents ordering, the 10-per-call cap, and VIN format rules. The description adds only an indirect hint that results correspond per-VIN, so it neither compensates for nor duplicates the schema meaningfully — 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 and resource with batch scope ("Look up a batch of Australian vehicle recalls by VIN"), which distinguishes it from a singular lookup. It never names the sibling lookup_vin as the single-VIN alternative, so the differentiation is only implied by the word "batch".
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 clarifies interpretation ("There is no 'not recalled' answer") and error tolerance ("One invalid VIN is reported in its own result instead of failing the batch"), which is real usage context. But it gives no explicit when-to-use-this vs lookup_vin or get_recall guidance, leaving routing to inference from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Australian vehicle recall index by make, model, year and publication date. Returns summaries only — full text is get_recall's job. The index lists what this database holds, so an empty page is not a statement that a vehicle is free of recalls.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | Manufacturer name, matched case-insensitively and exactly. | |
| year | No | Model year; matches recalls whose year range includes it. | |
| limit | No | Rows to return, clamped to between 1 and 20. Defaults to 20. | |
| model | No | Model name; a case-insensitive substring, so `cresta` finds `Cresta 480`. | |
| since | No | Only recalls published on or after this date, as `YYYY-MM-DD`. | |
| cursor | No | Pass back the `next` value from the previous page; omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does good work: it discloses that only summaries are returned, that the result set is limited to what this index holds, and that empty results are not negative evidence. Pagination mechanics are left to the cursor field in the schema, which is a minor gap for an unannotated tool.
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 short sentences, front-loaded with purpose, followed by return-shape and the caveat. No filler and every sentence 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?
Covers purpose, scope limits, return shape, and the sibling handoff, which is sufficient for a six-parameter read-only search with fully documented params and no output schema. It stops short of describing what a summary contains or how paging terminates, but nothing essential to calling it correctly 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 coverage is 100%, so every parameter (make, model, year, since, limit, cursor) is already documented with matching semantics like substring matching for model. The description only lists the filter dimensions, adding no syntax or behavior 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?
States a specific verb (search) and resource (Australian vehicle recall index) plus the filter dimensions, and explicitly contrasts with the sibling get_recall for full text. An agent can distinguish it from get_recall and the VIN lookups without opening a 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?
Explicitly routes the agent to get_recall when full text is needed and warns that an empty page does not prove a vehicle is recall-free. It does not address when to prefer lookup_vin/lookup_vins over this search, so the guidance is clear but not exhaustive.
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_recalllookup_vinlookup_vinssearch_recalls
Add one secure layer between your agents and this server.