AI agents are good at reasoning and terrible at facts. Ask Claude whether a particular frozen product is under an active FDA recall, and it will give you a confident answer from its training data that may be months out of date, or simply invented. In food safety, "probably fine" is how a Class I allergen ends up on a shelf.
In this guide we fix that. We connect Claude to the official Apify MCP server, expose a single Actor that reads the FDA's food recall and enforcement reports, and turn "is this product recalled?" from a guess into a live lookup against the source of record. By the end you will have a working recall-monitoring tool that Claude, Cursor, or any MCP client can call mid-conversation, and you will understand exactly where in the run the tool fires and what it returns.
Everything below is a real setup with real output. No mocked responses.
What is the Apify MCP server?
Model Context Protocol (MCP) is an open standard that lets AI clients call external tools. The Apify MCP server (https://mcp.apify.com) implements that standard on top of the Apify platform, which means every one of the thousands of Actors in the Apify Store becomes a tool an agent can invoke.
Why route an Actor through MCP instead of hard-coding an API call?
- The agent decides when to fetch. Claude reads the conversation, notices it needs a fact it does not have, and calls the tool on its own. You do not write glue code for every question.
- Structured input and output. The MCP server hands Claude the Actor's input schema, so the model fills in the parameters correctly, and returns a clean dataset it can reason over.
-
One connection, many tools. The same MCP endpoint exposes
search-actors,fetch-actor-details, andcall-actor, so an agent can discover and run any Actor without new configuration. - No infrastructure. The server is hosted. You add a few lines to a config file and you are done.
The Actor we will use
We will expose the openFDA Food Recall & Enforcement Scraper (USA). It reads the FDA's official food recall and enforcement reports and returns the full record for each event: recall number, hazard classification (Class I/II/III), product description, the reason for the recall, the recalling firm and its address, product quantity and code information, distribution pattern (which states, and whether it was nationwide), and the key dates.
That field set is exactly what a grocery buyer, importer QA lead, or retail compliance team needs to answer one question fast: is anything we stock, or are about to stock, on the recall list, and how serious is it? Food recalls are public and authoritative, with no login wall, which makes them an ideal first data source to hand an agent.
Step 1: Get your Apify API token
Sign in to the Apify Console, open Settings → Integrations, and copy your personal API token. The MCP server uses it to authenticate and to bill Actor runs to your account.
📌 Note: the token is a secret. Keep it in the client config only, never in a prompt or a committed file.
Step 2: Point Claude Desktop at the Apify MCP server
Open Claude Desktop's config file (Settings → Developer → Edit Config, or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the Apify server. The tools query parameter is the important part: it tells the server which Actor to expose, so Claude gets one focused tool instead of the entire Store.
{
"mcpServers": {
"apify": {
"url": "https://mcp.apify.com?tools=scrapers_lat/openfda-food-recalls-scraper",
"headers": {
"Authorization": "Bearer YOUR_APIFY_TOKEN"
}
}
}
}
Cursor uses the same JSON in .cursor/mcp.json. If you prefer to run it locally over stdio instead of the hosted endpoint:
{
"mcpServers": {
"apify": {
"command": "npx",
"args": ["-y", "@apify/actors-mcp-server", "--tools", "scrapers_lat/openfda-food-recalls-scraper"],
"env": { "APIFY_TOKEN": "YOUR_APIFY_TOKEN" }
}
}
}
Restart Claude Desktop so it picks up the new server.
Step 3: Confirm the tool is loaded
After the restart, the Actor shows up as a callable tool. If you list the tools the Apify server exposes, you will see the storage helpers plus the Actor itself, named after its Store handle:
get-actor-run, get-dataset-items, get-key-value-store-record,
abort-actor-run, scrapers_lat--openfda-food-recalls-scraper
That last entry, scrapers_lat--openfda-food-recalls-scraper, is our recall-lookup tool. Claude now knows it exists, what it does (from the Actor's README), and what inputs it takes (from the input schema the server passes along).
Step 4: Ask Claude to check for recalls
Now the payoff. In a normal chat, ask a question that requires ground truth:
"We stock imported frozen Asian groceries. Are there any recent Class I FDA recalls for undeclared allergens we need to pull from our shelves?"
Claude recognizes it cannot answer this reliably from memory, selects the recall tool, and fills in the input from your question. Under the hood the client sends a tools/call with the Actor's parameters:
{
"name": "scrapers_lat--openfda-food-recalls-scraper",
"arguments": {
"searchQuery": "undeclared allergen",
"classification": "Class I",
"dateFrom": "2025-01-01",
"maxRecalls": 10
}
}
The Apify MCP server starts the Actor, waits for it to finish, and returns the dataset. Here is the real run metadata it produced:
{
"runId": "NmLimdVRabbDI9oSk",
"actorName": "scrapers_lat/openfda-food-recalls-scraper",
"status": "SUCCEEDED",
"startedAt": "2026-07-30T17:47:32.578Z",
"finishedAt": "2026-07-30T17:47:35.730Z",
"stats": { "runTimeSecs": 3.0 }
}
Three seconds, live against the FDA's enforcement reports.
Step 5: Read the real output
The dataset the tool returns is structured recall data. This is an actual record from the run (trimmed to the fields that matter for a shelf check):
{
"recallNumber": "H-0530-2026",
"classification": "Class I",
"status": "Terminated",
"productDescription": "Fish Ball, Frozen, 40 pieces per pack, 200g Wt. UPC# 810093891338",
"reasonForRecall": "Undeclared allergen ingredient (Wheat and Sesame)",
"recallingFirm": "MIN JIANG FOOD STORE INC DBA KOI KOI TRADING",
"city": "Commerce",
"state": "CA",
"productQuantity": "344 cases",
"codeInfo": "Item# 27010",
"distributionPattern": "Product was distributed to 50 consignees... primarily to restaurants and retail grocery stores.",
"distributionStates": ["CA", "CO", "GA", "HI", "NJ", "OR", "TX", "WA"],
"reportDate": "2026-03-04",
"eventId": "98355"
}
Claude reads that and answers in plain language: yes, there is a Class I recall for a frozen fish ball product, recall number H-0530-2026, because it contains undeclared wheat and sesame (both U.S. major allergens), pulled by KOI KOI Trading of Commerce, California, 344 cases, distributed to restaurants and retail grocery stores across eight states. Every one of those facts is traceable to an official FDA enforcement report, not the model's memory.
The hazard class is what turns data into a decision. Class I means a reasonable probability that use of the product will cause serious health consequences or death, which is the difference between "flag it for the next review" and "quarantine it today." An agent that surfaces the classification, the UPC, and the exact distribution states gives a food-safety lead everything they need to act; the model alone would give none of it reliably.
A real use case: a shelf-monitoring agent
Put this in context. A grocery chain's food-safety desk or an importer's QA team needs to confirm, continuously, that nothing on their shelves or inbound in a container is under an active recall. Three things matter to them:
- is the product they carry named in a recall,
- how serious is it (Class I versus a minor mislabel), and
- does the distribution footprint actually reach their stores or region.
Without a tool, an analyst opens the FDA recall site, searches by product or firm, reads each enforcement report, and copies the recall number, class, and states into a tracker, once per SKU. With the tool wired into Claude, the analyst pastes a supplier list or a batch of product names into the chat and asks the agent to check each one. Claude calls the Actor per query, filters to Class I events, compares the returned distributionStates against the chain's footprint, and produces a short pull-or-monitor list with the recall number as evidence. The manual lookup step disappears; the judgment stays with the human.
This is the shape of every good agent tool: it removes the mechanical fetch, not the decision.
Going further: chain a second tool
Recall monitoring rarely stops at the packaged product. If you also run or supply foodservice, you want to know whether the establishments handling these goods have a clean inspection history. The same MCP connection can expose more Actors by extending the tools parameter:
https://mcp.apify.com?tools=scrapers_lat/openfda-food-recalls-scraper,scrapers_lat/usa-restaurant-inspections-scraper
Now the agent can find a Class I recall on the FDA enforcement reports and pull the health-inspection record for a restaurant or facility in the same conversation, then combine both into one risk summary: this product is recalled, and here is the inspection standing of the outlets it reached. Because each Actor is a separate tool, the agent picks the right one for each step on its own.
🏹 Troubleshooting: if the tool does not appear in Claude, the two usual causes are a missing or misspelled Actor handle in the tools parameter (it must be the exact username/actor-name from the Store URL) and a config that was edited while Claude was running. Fix the handle, save, and fully restart the client.
📌 Note: each tool call is a real Actor run billed to your Apify account (this Actor is pay-per-result). For an occasional shelf check the cost is a fraction of a cent; if you plan to sweep thousands of SKUs on a schedule, run the Actor directly through the Apify API or a scheduled task and store the results, instead of one call per chat message.
Wrapping up
You now have an AI agent that can check a food product against official FDA recall and enforcement reports, on demand, mid-conversation, with the hazard class and distribution detail a real shelf decision needs. The pattern is reusable: pick an Actor that returns authoritative structured data, expose it through the Apify MCP server with the tools parameter, and let the agent decide when to call it.
To take it further:
- Narrow the query with the Actor's filters (classification, state, recalling firm, date range) so the agent only sees the events that matter to your footprint.
- Add restaurant inspection, drug label, or device recall Actors to build a broader food- and product-safety agent.
- Read the Apify MCP server docs for OAuth setup, resource reads, and the
search-actors/call-actortools that let an agent discover Actors it was not preconfigured with.
The Actor used in this guide: openFDA Food Recall & Enforcement Scraper (USA).
Top comments (0)