Skip to main content
Glama

Product recalls

list_recalls
Read-only

Check whether household items are under U.S. CPSC recall and retrieve matching hazards, remedies, and contacts; review open recalls or a specific item's status, including resolved cases.

Instructions

U.S. product recalls (from the CPSC) that match things the household owns, each with its id, the item, how sure the match is (barcode or model: almost certainly theirs; possible: same brand and kind of thing — check the model), the hazard, the remedy and who to contact. Without itemId: open recalls only; with itemId: that item's recalls, dealt with ones too. Use it for "is anything we own recalled?" or to explain a recall what_needs_attention mentioned; mark one with set_recall_status once the person says. Empty when there are none or the server's admin hasn't switched recall checks on.

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": "list_recalls"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemIdNoOne item's recalls (from search_inventory), including closed ones; left out: every open one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2026.11.6

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds real context beyond them: the data source (CPSC), the two-level match-confidence semantics (barcode/model vs. same brand and kind), and the empty-result causes including the admin feature flag being off. It does not mention result limits or pagination, which keeps it from a 5.

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?

Information is front-loaded: resource, then result shape, then the itemId branching, then usage and edge cases. It is dense and nearly every clause carries meaning, though the long comma-chained sentence listing return fields is harder to scan than a bulleted structure would be.

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?

With one optional parameter and no output schema, the description compensates by enumerating return fields, explaining match confidence, describing the two itemId modes, and covering the empty-result case including the disabled-feature scenario. Nothing material is missing for correct invocation.

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 coverage is 100% and the schema already explains that itemId scopes to one item including closed recalls while omission returns every open one. The description restates that behavior rather than adding new syntax or edge-case meaning, so it sits at the baseline for fully documented parameters.

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?

States a specific resource (U.S. CPSC product recalls) and an explicit scope constraint — only recalls matching household-owned items — plus what each result contains (id, item, match confidence, hazard, remedy, contact). It is unmistakably distinct from siblings like set_recall_status or what_needs_attention.

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?

Gives concrete triggering questions ("is anything we own recalled?") and a second use case (explaining a recall surfaced by what_needs_attention), then routes the follow-up action to set_recall_status once the user confirms. When-not is implicit but the scope line (only owned items) covers the main exclusion.

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