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: Label prefixes (BB:, Lot#, Best By, Exp, etc.) are ignored. Matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches notice title and description when the lot is at least 4 characters — 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_recalls_by_identifier"
  }
}

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. Label prefixes (BB:, Lot#, Best By, Exp, etc.) are ignored. Matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches the notice title and description when the lot is at least 4 characters. 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.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / lot_code / description

Previous 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."New value: +"lot or batch code. Label prefixes (BB:, Lot#, Best By, Exp, etc.) are ignored. Matches extracted lot codes after normalizing spaces, case, and punctuation; if lots were not extracted, also searches the notice title and description when the lot is at least 4 characters. Verify against the notice."

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"
+}
```

First observedSep 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real behavior beyond that: AND-matching across identifiers on the same product, lot-code normalization rules, a 4-character threshold for title/description fallback, and the caveat that VIN lookup only returns NHTSA campaigns for the decoded year and make and must be confirmed on nhtsa.gov. The main omission is any statement about what happens when no identifiers are supplied.

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?

Front-loaded with the core purpose and identifier list, then ordered by identifier-specific caveats. It is dense but each clause carries information; the cost is that the lot_code and VIN sentences repeat the schema text almost word for word, which is wasted space for an agent that already sees the schema.

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 7 optional parameters and an output schema present, the description covers matching semantics, normalization, and fallbacks well and need not describe return values. The one meaningful gap is that no parameter is required, and the description never says what an empty-argument call returns or whether at least one identifier is expected.

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 would be 3, but the description adds semantics the schema lacks: multiple identifiers are AND-matched on the same product, and product_name falls back to the search_product_recalls full-text behavior with a hint if still empty. Most of the lot_code and VIN text is duplicated verbatim from the schema, which caps it at 4.

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

Purpose4/5

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

States a specific verb and resource plus the exact identifier set it searches (UPC, lot code, model number, product name, VIN), which lets an agent distinguish it from the single-identifier sibling search_product_recalls_by_upc. It never explicitly contrasts itself with that sibling, so it stops short of a 5.

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?

Implies the use case clearly (lookup when you hold one or more extracted identifiers) and explains fallback behavior when exact matches fail, including the hint returned for product_name. It does not state when to prefer this over search_product_recalls or search_product_recalls_by_upc, leaving the routing decision partly to inference.

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.