Recall Kitchen

search_recalls_by_identifier

Read-onlyIdempotent

Search recalls by extracted UPC, lot code, model number, product name, or VIN. Multiple identifiers are AND-matched on the same product. VIN lookup lists NHTSA campaigns for the decoded year and make; confirm your vehicle on nhtsa.gov/recalls. lot_code matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches notice title and description — verify against the notice. product_name falls back to the same full-text search as search_product_recalls when no exact extracted name matches, and returns a hint if still empty.

Input Schema

Name	Required	Description
`upc`	No	product UPC or EAN as stored on the recall
`vin`	No	17-character VIN. Lookup lists NHTSA campaigns for the decoded year and make; confirm your vehicle on nhtsa.gov/recalls.
`limit`	No	number of recalls to return
`offset`	No	number of recalls to skip
`lot_code`	No	lot or batch code. Matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches the notice title and description. Verify against the notice.
`model_number`	No	model number as stored on the recall
`product_name`	No	extracted product name (exact match; if none, falls back to the same full-text search as search_product_recalls)

Output Schema

Name	Required	Description	Default
`hint`	No
`offset`	Yes
`recalls`	Yes
`nextOffset`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / lot_code / description

Previous value: -"lot or batch code as stored on the recall"New value: +"lot or batch code. Matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches the notice title and description. Verify against the notice."

changedInput schema / properties / vin / description

Previous value: -"17-character vehicle identification number. Decoded locally to year and make, then matched against NHTSA campaigns. Does not call NHTSA live."New value: +"17-character VIN. Lookup lists NHTSA campaigns for the decoded year and make; confirm your vehicle on nhtsa.gov/recalls."

Changed2 schema fields changedOct 20, 2026

changedInput schema / properties / product_name / description

Previous value: -"extracted product name (exact match)"New value: +"extracted product name (exact match; if none, falls back to the same full-text search as search_product_recalls)"

addedOutput schema / properties / hint
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedSep 3, 2026

addedInput schema / properties / vin

Added value: +{
+  "description": "17-character vehicle identification number. Decoded locally to year and make, then matched against NHTSA campaigns. Does not call NHTSA live.",
+  "type": "string"
+}

First observedSep 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is low, and the description clears it by disclosing non-obvious behaviors: multi-identifier AND-matching on the same product, VIN returning decoded year/make campaigns rather than exact recalls, lot-code normalization of spaces/case/punctuation, and an empty-result hint after full-text fallback.

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

Conciseness3/5

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

Purpose and identifier list are front-loaded, but the second half re-narrates the VIN, lot_code, and product_name schema descriptions almost verbatim, so a noticeable share of the text duplicates structured data rather than earning its place.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description covers the quirky parts an agent would otherwise miss (fallback chains, hint on empty, AND-matching). Pagination via limit/offset is left entirely to the schema, which is acceptable but makes the coverage not quite exhaustive.

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 coverage is 100%, so baseline is 3, but the description adds a genuine semantic the schema omits: multiple identifiers are AND-matched against the same product, which changes how an agent should combine parameters. The remaining per-identifier notes largely restate the schema.

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?

States a specific verb (search) plus the exact resource (recalls) and enumerates the five identifier types that select it (UPC, lot code, model number, product name, VIN). It also distinguishes itself from the sibling search_product_recalls by naming it and explaining the product_name fallback path.

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

Usage Guidelines4/5

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

Explains the conditions under which each identifier is the right input (VIN -> NHTSA campaigns, lot_code -> normalized lots then title/body, product_name -> exact then full-text fallback), which gives clear contextual routing. It stops short of an explicit 'use this instead of X when Y' statement against siblings like search_product_recalls_by_upc.

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

All Recall Kitchen 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?