cpsc-recalls-mcp-server
Server Details
US consumer product recalls from the CPSC — hazards, remedies, and affected products.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/cpsc-recalls-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 3 of 3 tools scored.
Each tool serves a distinct purpose: searching, fetching recent, and getting full detail by number. No overlapping functionality.
All tools follow the consistent pattern of 'cpsc_verb_noun' with snake_case, making names predictable.
Three tools is slightly low but perfectly scoped for a focused recall information server, covering essential operations.
The tool set covers search, recent lookups, and full recall details, providing a complete workflow for CPSC recall queries.
Available Tools
3 toolscpsc_get_recallGet CPSC Recall DetailARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| recall_number | Yes | CPSC 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
| Name | Required | Description |
|---|---|---|
| upcs | Yes | UPC 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. |
| title | Yes | Official recall title. |
| images | Yes | Product and identification images from the recall notice. |
| hazards | Yes | Hazards — read this first. |
| cpsc_url | Yes | Official CPSC recall page — authoritative source for consumers. |
| injuries | Yes | Injury and incident report narrative, e.g. "None reported" or incident count. |
| products | Yes | Products covered. A recall may include multiple products. Note: model numbers are often in the description text, not a structured field. |
| importers | Yes | Importer company names. |
| retailers | Yes | Retailer names with sale date ranges and price. |
| description | Yes | Full 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_date | Yes | Date issued, ISO 8601. |
| source_note | Yes | Provenance caveat: recall fields are relayed from CPSC unedited and unverified; check cpsc_url before a consumer-facing decision. |
| distributors | Yes | Distributor company names. |
| last_updated | Yes | Date last published, ISO 8601. |
| manufacturers | Yes | Manufacturer names (often empty — see importers). |
| recall_number | Yes | Recall identifier. |
| remedy_options | Yes | Remedy 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_contact | Yes | Contact information for claiming the remedy. Null when not provided. |
| cpsc_jurisdiction | Yes | CPSC 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_notes | Yes | Gaps 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_recalls | Yes | URLs of coordinated recalls by other agencies (e.g., Canada Health). |
| remedy_instructions | Yes | Full remedy instructions — exactly what a consumer should do and how to claim. |
| manufacturer_countries | Yes | Countries of manufacture. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint (safe, no side effects). The description adds value by detailing the returned record (hazard, remedy, images, URL) without contradicting annotations.
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 focused sentences plus a one-line jurisdiction note. Every sentence serves a purpose; no filler. Front-loaded with the primary function.
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?
Given the tool's simplicity (single parameter) and the presence of an output schema, the description covers the purpose, usage context, and limitations completely.
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?
With 100% schema coverage, baseline is 3. The description adds the helpful hint to obtain recall_number from search results, which goes beyond the schema's pattern and format details.
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?
Description clearly states it gets full detail for a single CPSC recall by recall number, listing eight specific return fields. It distinguishes itself from sibling tools by directing use after search or recent recall retrieval.
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 instructs to use after 'cpsc_search_recalls' or 'cpsc_get_recent' and adds jurisdiction context (CPSC covers consumer products only), helping the agent decide when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cpsc_get_recentGet Recent CPSC RecallsARead-onlyInspect
Fetch the most recent CPSC consumer product recalls, ordered newest-first. Use for "what's been recalled lately?" or a product safety feed. Always applies a date window (default: last 30 days) — without a date filter the API returns all 9,800+ records. Page past limit with offset: narrowing days cannot page, because the window is anchored to today and shrinking it drops the oldest records rather than advancing past the newest. CPSC jurisdiction: consumer products only — food, vehicles, drugs, and pesticides are covered by other agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look back this many days from today. Defaults to 30. Use 7 for a weekly digest, 90 for a quarterly review. | |
| limit | No | Maximum number of recalls to return. Defaults to 20. | |
| offset | No | Skip this many recalls in the window 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| offset | Yes | Number of recalls skipped before this window. |
| period | Yes | Date range queried. |
| recalls | Yes | Recent recalls, newest-first. |
| has_more | Yes | True when recalls remain past this window — call again with offset raised by the number of recalls returned. |
| truncated | Yes | True when total_found exceeds the limit. Independent of offset. |
| source_note | Yes | Provenance caveat: recall fields are relayed from CPSC unedited and unverified; check cpsc_url before a consumer-facing decision. |
| total_found | Yes | Total recalls in this period, counted before offset and limit narrow the window. |
| cpsc_jurisdiction | Yes | CPSC 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint confirms no destructive actions. The description adds value by disclosing that without a date filter the API returns all records, and clarifies CPSC's jurisdiction, which helps avoid misuse.
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?
The description is extremely concise — three sentences that are front-loaded with the core purpose, followed by critical usage notes. Every sentence serves a purpose, no filler.
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?
Given the simplicity (2 parameters, no nested objects, output schema present, annotations provided) the description covers purpose, usage guidance, behavioral transparency, and parameter hints. It is nearly complete; could mention error handling or return format but not required.
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?
The input schema already provides 100% coverage with detailed parameter descriptions (days, limit, defaults, min/max). The tool description reinforces the default date window but adds no further semantic value beyond the schema.
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?
The description clearly states the verb 'Fetch', the resource 'most recent CPSC consumer product recalls', and specifies ordering 'newest-first'. It distinguishes from siblings by implication: cpsc_get_recall and cpsc_search_recalls are for different use cases.
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 tells when to use the tool ('what's been recalled lately?' or a product safety feed) and provides important context about the date window and CPSC jurisdiction. It mentions other agencies for excluded categories, though it does not explicitly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cpsc_search_recallsSearch CPSC RecallsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (applied client-side — the API returns all matches). Defaults to 20. | |
| offset | No | Skip 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. | |
| remedy | No | Keyword 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_end | No | Include 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. | |
| importer | No | Importer company name. Use when searching for recalls by the company that brought the product into the US. | |
| retailer | No | Retailer name, e.g. "Walmart", "Target", "Amazon". Substring match against the retailer narrative (which includes store name, dates sold, and price). | |
| date_start | No | Include 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. | |
| distributor | No | Distributor 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_end | No | Include 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. | |
| manufacturer | No | Manufacturer 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_name | No | Product name to search for, e.g. "crib", "space heater", "bicycle". Substring match — partial names work. | |
| title_search | No | Keyword 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_search | No | Hazard 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_start | No | Include 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_search | No | Keyword 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
| Name | Required | Description |
|---|---|---|
| offset | Yes | Number of matching records skipped before this window. |
| recalls | Yes | Matching recalls, ordered newest-first. |
| has_more | Yes | True when records remain past this window — call again with offset raised by the number of recalls returned. |
| truncated | Yes | True when total_found exceeds the limit. Independent of offset. |
| source_note | Yes | Provenance caveat: recall fields are relayed from CPSC unedited and unverified; check cpsc_url before a consumer-facing decision. |
| total_found | Yes | Total matching records, counted after hazard_search is applied and before offset and limit narrow the window. |
| cpsc_jurisdiction | Yes | CPSC 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: all filters are optional substring matches combined with AND, limit is applied client-side with a default of 20, and clarifies the non-functional Hazard parameter. This goes beyond annotations without contradicting them.
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?
Every sentence in the description serves a purpose: jurisdictional exclusions, parameter behavior, fallback strategies, and cross-tool references. It is front-loaded with purpose and exclusions, then logically proceeds to details. No redundant or filler content.
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?
With a full output schema and comprehensive annotations, the description covers all essential aspects for effective usage: parameter behavior, known API quirks (non-functional Hazard filter), fallback patterns, and guidance to use cpsc_get_recall for full details. It is complete for a search tool of this complexity.
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%, but the description adds substantial value beyond schema: explains limit is client-side, provides examples for product_name, advises using description_search for hazard types due to API issue, clarifies retailer matches against narrative string, and suggests fallback order for manufacturer/importer/retailer. This far exceeds the baseline of 3.
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?
The description clearly states the tool searches CPSC recalls, lists covered product categories (toys, electronics, etc.), and explicitly excludes other agencies' jurisdictions (FDA, NHTSA, etc.). It distinguishes between this search tool and its siblings (cpsc_get_recall, cpsc_get_recent) by naming them and explaining when to use each.
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 provides explicit guidance on when not to use (excluded categories), fallback strategies (try importer/retailer if manufacturer returns no results), and notes that the dedicated Hazard filter is non-functional, recommending description_search instead. It also directs users to cpsc_get_recall for full records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!