Skip to main content
Glama

cpsc-recalls-mcp-server

by io.github.cyanheads

Search CPSC Recalls

cpsc_search_recalls
Read-onlyIdempotent

Search consumer product recalls from the CPSC (Consumer Product Safety Commission) database. Covers toys, electronics, furniture, appliances, children's products, tools, and clothing — everything under CPSC jurisdiction. Does NOT cover food/drugs (FDA), motor vehicles/tires (NHTSA), boats (USCG), or pesticides (EPA). All filter fields are optional substring matches that combine with AND. Start with title_search when you have a product in hand — CPSC titles carry the brand, product, and hazard phrasing. For hazard-type filtering ("fire", "choking", "burn"), use hazard_search, which matches hazard text, product names, and remedy instructions in one pass. When manufacturer returns no results, try importer, retailer, or distributor: many recalls list one of those as the primary responsible org. Page past limit with offset — total_found and has_more say where the window sits in the full result set. Use cpsc_get_recall with a recall_number from results to retrieve the full record including complete description, all images, and incident reports.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (applied client-side — the API returns all matches). Defaults to 20.
offsetNoSkip this many matching records before returning results. Combine with limit to page through total_found — e.g. limit 20 with offset 0, 20, 40. An offset at or past total_found returns an empty result set rather than an error.
remedyNoKeyword search within the free-text remedy instructions, e.g. "repair", "refund", "firmware update". Substring match, applied upstream. This searches the remedy narrative, not the structured remedy_options enum — "repair" matches records whose remedy_options list only "Refund" but whose instructions describe a free repair kit. Combines with the other filters using AND; use hazard_search instead to match remedy text as one of several fields.
date_endNoInclude only recalls on or before this date. ISO 8601 format: "YYYY-MM-DD". Must be a real calendar date, and on or after date_start.
importerNoImporter company name. Use when searching for recalls by the company that brought the product into the US.
retailerNoRetailer name, e.g. "Walmart", "Target", "Amazon". Substring match against the retailer narrative (which includes store name, dates sold, and price).
date_startNoInclude only recalls on or after this date. ISO 8601 format: "YYYY-MM-DD". Must be a real calendar date — "2026-02-31" and "2026-99-99" are rejected.
distributorNoDistributor company name, e.g. "Walmart", "Costco". Substring match against the Distributors array — a role distinct from retailer and importer, and populated on far fewer records.
updated_endNoInclude only recalls last published by CPSC on or before this date. ISO 8601 format: "YYYY-MM-DD". Must be a real calendar date, and on or after updated_start.
manufacturerNoManufacturer name, e.g. "Samsung", "LEGO". Substring match against the Manufacturers array. Note: many recalls list the importer or retailer as the primary org rather than the manufacturer — try importer or retailer if this returns no results.
product_nameNoProduct name to search for, e.g. "crib", "space heater", "bicycle". Substring match — partial names work.
title_searchNoKeyword search within the recall Title, e.g. "chandelier", "space heater", "inclined sleeper". Substring match. CPSC titles name the brand, the product, and the hazard, which makes this the highest-signal single filter for most searches.
hazard_searchNoHazard or safety-concept keyword, e.g. "fire", "choking", "burn", "laceration". Applied client-side after the upstream fetch. Matches when the term appears in any of: hazard descriptions, product names, or remedy instructions (OR across the three, case-insensitive substring). Use this rather than the upstream Hazard parameter, which CPSC recognizes but never matches.
updated_startNoInclude only recalls last published by CPSC on or after this date. ISO 8601 format: "YYYY-MM-DD". A separate axis from date_start: a 2003 recall re-published in 2025 matches updated_start "2025-01-01". Use to answer "what has CPSC updated recently". Must be a real calendar date.
description_searchNoKeyword search within the recall Description field only (does not search Title, Hazards, or remedy text). Use for product details not captured in product_name — model numbers, colors, sale channels. For hazard concepts, prefer hazard_search; for the recall headline, prefer title_search.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
offsetNoNumber of matching records skipped before this window.
recallsNoMatching recalls, ordered newest-first.
has_moreNoTrue when records remain past this window — call again with offset raised by the number of recalls returned.
truncatedNoTrue when total_found exceeds the limit. Independent of offset.
source_noteNoProvenance caveat: recall fields are relayed from CPSC unedited and unverified; check cpsc_url before a consumer-facing decision.
total_foundNoTotal matching records, counted after hazard_search is applied and before offset and limit narrow the window.
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).

TDQS

A5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and idempotentHint, which the description doesn't contradict. It goes beyond this by disclosing client-side filtering behavior ('hazard_search applied client-side after upstream fetch', 'limit applied client-side'), pagination semantics ('offset at or past total_found returns an empty result set rather than an error'), AND-combination of filters, and distinct date axes (date_start vs updated_start). These traits materially affect how an agent interprets results.

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?

The description is long but every sentence carries unique value—scope, exclusions, filter strategy, pagination, and next-step linkage. It is front-loaded with the core purpose and exclusions before diving into usage details, and it uses lists and short sentences to keep scanning easy. No redundancy or filler.

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?

Given 15 parameters and an output schema, the description comprehensively covers scope, exclusions, per-filter guidance, fallback strategies (manufacturer → importer/retailer), pagination, and the correct follow-up tool. It explains the distinct date axes and client-side constraints, leaving no significant gap for an agent to call it correctly. The output schema handles return details, so no need to repeat those.

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

Parameters5/5

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

While the schema covers all 15 parameters with detailed descriptions, the tool description adds critical nuance per field: title_search is called 'the highest-signal single filter,' hazard_search ORs across fields and is client-side, remedy clarifies it searches narrative not the structured enum, and manufacturer warns that importer/retailer may be the primary org. These enrich the schema meanings and directly reduce misuse.

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 opens with a specific verb and resource: 'Search consumer product recalls from the CPSC database.' It enumerates covered categories and explicitly excludes other agencies (FDA, NHTSA, USCG, EPA), making the tool's scope unambiguous. It also differs from its sibling cpsc_get_recall by describing the search role, and the final sentence directs the agent to that retrieval tool, clearly separating the two.

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?

The description provides rich, actionable guidance: 'Start with title_search when you have a product in hand,' 'use hazard_search' for hazard concepts, and 'When manufacturer returns no results, try importer, retailer, or distributor.' It also instructs to use cpsc_get_recall for full records and explains pagination with offset. This gives the agent both when-to-use and when-to-avoid this tool, with explicit alternatives.

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

All cpsc-recalls-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources