Skip to main content
Glama
paulet4a-commits

WebDataTools Developer, app & research data MCP server

openfda_recall_monitor

Monitor FDA food, drug, and device recalls plus adverse-event reports and drug labels by date range, using optional openFDA search filters for focused results.

Instructions

FDA Recalls & Adverse Events Monitor returns food, drug and device recalls, drug and device adverse-event reports, and drug labels from openFDA — one flat, scored row per record for a date range you choose. Billed to your own Apify account: ~$0.002 per result (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datasetYesDataset — Choose which openFDA dataset to query. Enforcement datasets are product recalls; event datasets are adverse-event reports; drug-label returns FDA drug label (SPL) documents. Options: food-enforcement = Food recalls (enforcement); drug-enforcement = Drug recalls (enforcement); device-enforcement = Device recalls (enforcement); drug-event = Drug adverse events (FAERS); device-event = Device adverse events (MAUDE); drug-label = Drug labels (SPL). Example: "food-enforcement".
maxItemsNoMax items — Enter the maximum number of records to return, e.g. 100. Results are fetched 100 at a time (limit=100&skip=...) until this many are collected or the dataset runs out.
sinceDaysNoSince days — Enter how many days back to search, e.g. 30. Filters the dataset's report_date (enforcement) or receivedate/date_received (events) field; ignored for drug-label, which has no report date.
searchQueryNoopenFDA search query — Optional. A raw openFDA search expression, ANDed with the date range, e.g. recalling_firm:"Nestle" or classification:"Class I". Leave blank to fetch every record in the date range. See https://open.fda.gov/apis/query-syntax/

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits beyond structured fields: billing runs against the caller's own Apify account at ~$0.002/result, and output is one flat, scored row per record. It stops short of describing auth setup or rate limits, so it is good but not complete.

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?

Two sentences, front-loaded with the capability before the pricing note, with no filler. Slightly dense and the undefined term 'scored' costs a little clarity, but it earns its length.

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?

No output schema or annotations exist, so the description must carry the load; it names the six datasets, the return shape, and cost. The one notable omission is that 'scored row' is never defined, leaving the output field semantics unclear.

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 description coverage is 100%, so the schema already documents dataset, maxItems, sinceDays and searchQuery in detail. The description adds only the framing of 'a date range you choose' (mapping to sinceDays) and does not extend parameter meaning beyond the schema, so the baseline 3 applies.

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 verb and a rich resource set: returns food/drug/device recalls, adverse-event reports, and drug labels from openFDA, with the scoping unit (one flat, scored row per record for a chosen date range). No sibling tool overlaps this FDA-data domain, so an agent can route to it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent can infer this is the tool for FDA recall/adverse-event data, but there is no explicit when-to-use or when-not-to-use guidance, and no named alternative. Adequate but with a clear gap.

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