Skip to main content
Glama

KeyVex

get_product_recalls

Read-only

Returns safety recalls from federal agencies — drug recalls (FDA), medical device recalls (FDA), food/dietary supplement recalls (FDA), and (coming in v1A.1) vehicle recalls (NHTSA) and consumer-product recalls (CPSC). Use this when the user asks about: recent recalls for a specific company or product, FDA Class I (most severe) recalls, active vehicle recalls by make/model, food contamination recalls, drug shortages and recalls, or to add a 'product-safety event' flag to insider activity / 8-K filings / enforcement actions. Sources (filter via the source enum): fda_drug — openFDA /drug/enforcement.json. Drug recalls including prescription, OTC, biologics. Class I/II/III severity. fda_device — openFDA /device/enforcement.json. Medical device recalls (implants, diagnostics, equipment, software). Same classification scheme. fda_food — openFDA /food/enforcement.json. Food + dietary supplements. Pathogen contamination, allergen mislabeling, etc. cpsc — saferproducts.gov RestWebServices/Recall. Consumer-product recalls (clothing, electronics, toys, batteries, etc.). No severity classification; classification field is null. nhtsa — Vehicle, tire, equipment, child-seat recalls. Deferred to v1A.1 (api.nhtsa.gov bulk endpoint pending investigation). Cross-source pairing pattern: Recall → 8-K Item 7.01/8.01: pair with get_material_events Recall → insider sells: pair with get_insider_transactions Recall → SEC/DOJ follow-on: pair with get_enforcement_actions Recall → company filings: pair with get_proxy_filings (DEF 14A risk factors) Each record is one recall. Identifier format: {source}-{recall_number} (e.g., 'fda_drug-D-1234-2026'). FDA classifications: Class I — serious adverse health consequence or death Class II — temporary or reversible health consequence Class III — unlikely to cause adverse health consequence Source freshness (per-source publication cadence, not KeyVex bug): CPSC publishes within ~1-2 days; recent data flows hourly-fresh. openFDA's snapshot updates every ~10-14 days, and each snapshot carries recall_initiation_date values that LAG the snapshot date by another 30-45 days (the time between FDA classifying a recall and openFDA exposing it). Net: FDA records in this collection typically run ~4-6 weeks behind real-world recall dates, while CPSC is current. A default desc-by-date sort therefore looks CPSC-heavy at the top even when FDA matters more for the query. Filter by source='fda_*' to see FDA-only and avoid the skew. classification filter scope: 'classification' is an FDA-only field. CPSC records always have classification=null (CPSC doesn't use the FDA severity scheme). Filtering by classification excludes ALL CPSC rows by definition. The query response surfaces this with a notice in coverage_warning when the filter is set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum records to return. Default 50, max 500.
sinceNoISO date (YYYY-MM-DD). Only recalls whose recall_initiation_date is on or after this date.
untilNoISO date (YYYY-MM-DD). Only recalls whose recall_initiation_date is on or before this date.
sourceNoFilter to a single agency / category. Omit to see all sources combined.
statusNoExact match. Common values: 'Ongoing', 'Completed', 'Terminated', 'Recall Initiated'.
sort_byNoDefault: recall_initiation_date.
sort_orderNoDefault: desc (most recent first).
vehicle_makeNoNHTSA-only filter. Vehicle make, uppercase (e.g., 'TOYOTA', 'FORD'). Ignored for other sources.
recall_numberNoRecall identifier as filed (e.g., FDA 'D-1234-2026'). Combine with source for direct doc lookup, fastest path.
vehicle_modelNoNHTSA-only filter. Case-insensitive substring against vehicle model. Ignored for other sources.
classificationNoFDA severity classification. Class I is most severe (death / serious harm). Ignored for NHTSA / CPSC records.
recalling_firmNoCase-insensitive substring against the recalling firm name (e.g., 'Pfizer', 'Toyota', 'Whole Foods').
product_descriptionNoCase-insensitive substring against the product description (e.g., 'lithium', 'romaine', 'airbag').

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/open-world/non-destructive, and the description adds substantial behavior beyond them: per-source publication cadence, the ~4-6 week FDA lag that skews default date sorts, the fact that classification filtering excludes all CPSC rows and surfaces a coverage_warning, and NHTSA being deferred to v1A.1. This is exactly the kind of operational context an agent needs and cannot get from structured fields.

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?

The purpose is front-loaded in the first sentence and the body is organized into clearly labeled sections (source breakdown, pairing pattern, classification scheme, freshness, filter scope). It is long, but the length is largely earned by 13 parameters and five heterogeneous sources; only the 'coming in v1A.1' caveats and per-source repetition could be trimmed.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so partially: it states each record is one recall, defines the identifier format, explains the classification scheme, and flags the coverage_warning. It stops short of describing the full record shape or pagination behavior, which is the only remaining gap.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely extends several parameters: it explains what each `source` enum value maps to (openFDA endpoints, CPSC service), clarifies that `classification` is FDA-only and excludes CPSC, documents the `{source}-{recall_number}` identifier format, and notes `vehicle_make` is uppercase NHTSA-only. It adds little beyond the schema for the self-explanatory filters (limit, sort_by, status), keeping it short of a 5.

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?

Opens with a specific verb+resource ('Returns safety recalls from federal agencies') and enumerates the exact recall categories covered. It is clearly distinguishable from siblings like get_drug_adverse_events, get_fda_approvals, and get_enforcement_actions, which cover different datasets.

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?

Provides an explicit 'Use this when the user asks about...' list covering company/product recalls, Class I severity, vehicle recalls, food contamination, and flagging insider/8-K/enforcement activity. It also names concrete alternatives (get_material_events, get_insider_transactions, get_enforcement_actions, get_proxy_filings) with the pairing conditions, so routing is unambiguous.

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.

Resources