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
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. |
| recall_date | Yes | Date issued, ISO 8601. |
| 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, Dispose, Label, New Instructions. |
| 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). |
| 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. 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| period | Yes | Date range queried. |
| recalls | Yes | Recent recalls, newest-first. |
| truncated | Yes | True when total_found exceeds the limit. |
| total_found | Yes | Total recalls in this period before the limit was applied. |
| 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. For hazard-type filtering ("fire", "choking", "burn"), use description_search — the dedicated Hazard filter is non-functional in the upstream API. When manufacturer returns no results, try importer or retailer: many recalls list the importer or retailer as the primary responsible org. 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. | |
| date_end | No | Include only recalls on or before this date. ISO 8601 format: "YYYY-MM-DD". | |
| 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". | |
| 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. | |
| description_search | No | Keyword search within the recall Description field only (does not search Title or Hazards text). Use for hazard types like "fire", "choking", "burn", or to find product details not captured in product_name. Note: hazard keywords often appear in the Description field — this is the correct filter for hazard-type searching since the Hazard filter param is non-functional upstream. |
Output Schema
| Name | Required | Description |
|---|---|---|
| recalls | Yes | Matching recalls, ordered newest-first. |
| truncated | Yes | True when total_found exceeds the limit. |
| total_found | Yes | Total matching records before the limit was applied. |
| 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!