Skip to main content
Glama

cpsc-recalls-mcp-server

Get CPSC Recall Detail

cpsc_get_recall
Read-onlyIdempotent

Full detail for a single CPSC recall by recall number. Returns the complete record: hazard description, remedy instructions, all product variants, incident/injury reports, images, and the official CPSC recall page URL. Use after cpsc_search_recalls or cpsc_get_recent to get the full picture on a specific recall. CPSC jurisdiction: consumer products only — food, vehicles, drugs, and pesticides are covered by other agencies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recall_numberYesCPSC recall number. Modern records (2002–present) are 5-digit numeric, e.g. "25043". Historical records from 1998–2001 may have a letter suffix a–d, e.g. "99003a". Obtain from cpsc_search_recalls results.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
upcsNoUPC codes for this recall (sparse — ~4% of records have UPCs). UPCs are stored at the recall level in the API, not per-product; when the recall covers multiple products, UPC-to-product attribution is ambiguous.
errorNoPresent when the call failed. Absent on success.
titleNoOfficial recall title.
imagesNoProduct and identification images from the recall notice.
hazardsNoHazards — read this first.
cpsc_urlNoOfficial CPSC recall page — authoritative source for consumers.
injuriesNoInjury and incident report narrative, e.g. "None reported" or incident count.
productsNoProducts covered. A recall may include multiple products. Note: model numbers are often in the description text, not a structured field.
importersNoImporter company names.
retailersNoRetailer names with sale date ranges and price.
descriptionNoFull recall description including product identification details. Model numbers are typically embedded here, not in a structured field. Null when CPSC published the record without a description — rare, but a genuine record can still be complete otherwise.
recall_dateNoDate issued, ISO 8601.
source_noteNoProvenance caveat: recall fields are relayed from CPSC unedited and unverified; check cpsc_url before a consumer-facing decision.
distributorsNoDistributor company names.
last_updatedNoDate last published, ISO 8601.
manufacturersNoManufacturer names (often empty — see importers).
recall_numberNoRecall identifier.
remedy_optionsNoRemedy types available: Refund, Repair, Replace, New Instructions, Dispose, Label, No Remedy Available, Inspect. Often empty — CPSC classified the remedy on fewer than half its records. Read remedy_instructions when this is empty, and fall back to cpsc_url when that is empty too, rather than reporting that no remedy exists.
consumer_contactNoContact information for claiming the remedy. Null when not provided.
cpsc_jurisdictionNoCPSC covers consumer products — toys, electronics, furniture, appliances, tools, clothing. Does NOT cover: food/drugs (FDA), motor vehicles/tires (NHTSA), boats (USCG), pesticides (EPA), firearms (ATF).
data_quality_notesNoGaps this server observed in the upstream CPSC record — absent description, absent hazard text, absent product entries. Derived from which fields CPSC left empty, not from any judgement about the recall itself. Empty when nothing is missing.
coordinated_recallsNoURLs of coordinated recalls by other agencies (e.g., Canada Health).
remedy_instructionsNoFull remedy instructions — exactly what a consumer should do and how to claim.
manufacturer_countriesNoCountries of manufacture.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description correctly avoids repeating that. It adds substantive behavior detail: the exact contents of the return (hazard description, remedy instructions, product variants, incident reports, images, official URL) and the jurisdiction note. No contradiction with annotations. Slight gap: doesn't mention error behavior for invalid recall numbers, but that's minor given annotation coverage.

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

Conciseness5/5

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

Three sentences with zero fluff. The first sentence states the action and scope, the second lists what's returned, and the third gives usage context and jurisdiction. Information is front-loaded and every sentence earns its place.

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

Completeness5/5

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

The tool has one simple parameter, full annotations for safety (readOnly, idempotent), and an output schema (not shown but noted as present). The description provides usage guidance, return fields, and boundary conditions. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema fully documents recall_number with a pattern, example formats, and guidance to obtain it from search results. The description itself doesn't need to add anything to the parameter semantics; it correctly relies on the schema. Baseline 3 is appropriate.

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?

The description clearly states the tool fetches full detail for a single CPSC recall by recall number, listing the specific fields it returns (hazard, remedy, variants, incidents, images, official URL). This distinguishes it from siblings: it's for a specific recall, not a search or a recent list. The verb 'get' and resource 'recall detail' are unambiguous.

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

Usage Guidelines5/5

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

Explicitly instructs to use this tool after cpsc_search_recalls or cpsc_get_recent to get the full picture on a specific recall. Also notes the CPSC jurisdiction limitation (consumer products only), indirectly telling when not to use it (food, vehicles, drugs, pesticides). This is clear routing guidance with no ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: search for recalls, fetch recent recalls, and get full details by recall number. There is no overlap in functionality, and the descriptions reinforce when to use each.

Naming Consistency5/5

All tool names follow the cpsc_ prefix with a verb_noun pattern (get_recall, get_recent, search_recalls). The naming is perfectly consistent and predictable.

Tool Count5/5

Three tools is a well-scoped set for a recall lookup server. Each tool serves a necessary role (search, recent, detail) with no redundant or missing core operations.

Completeness5/5

The tool set covers the full read-only lifecycle for CPSC recalls: searching, browsing recent, and retrieving detailed records. All necessary operations for the domain are present, with no obvious gaps.