Skip to content
MCPCompare

Use case

Food safety and recall monitoring with MCP

Four of the 33 servers we publish touch food safety. Two answer without credentials: RecallRadar, with four tools across FDA, USDA FSIS and CPSC recalls, and Argus HQ, with five FDA enforcement tools covering warning letters, 483s and lot lookups. Atlas Verified sits behind OAuth with 32 scopes for supplier verification. fmcg.network declares FDA recall watch alongside nutrient and EU labelling data. None of the four declares an installable package, and none documents retention or audit logging.

What a recall watch actually has to do#

Break the job down before looking at servers. A quality or regulatory affairs function doing recall monitoring is running five distinct things: a standing watch on agency publications; a lookup when a customer complaint, a supplier notice or a trade press item lands; a traceable citation back to the source record so a decision can be defended later; a supplier-side check on whether a firm or an import is in good standing; and an entry in the system of record that proves the organisation responded.

Only the first four are read operations, and only read operations are plausibly served by what is in this catalog today. The fifth is not: no server among the 33 we publish is described as a quality-management, complaint or CAPA system. The nearest things we list are general work trackers — Atlassian, monday, Linear, Notion — which is not the same category of tool. The erp-and-supply-chain category exists in our taxonomy and is published with zero servers. So an assistant wired to these tools speeds up the finding and the reading, and stops at the boundary where the record has to be created by a person in the system your auditors accept.

That boundary is not a disappointment, it is a scoping decision. The honest description of the win is that a weekly manual sweep of three agency websites becomes a query an analyst can ask in the tool they are already in, with the source record attached. The tools that matter for that are the single-record fetches — RecallRadar's get_recall, Argus HQ's get_warning_letter — because a search result without a retrievable source record is an assistant assertion, and an assistant assertion is not evidence.

What is actually published#

Four of the 33 servers in the catalog sit in food safety and compliance, and one more in a different category carries recall data. Three are directly useful here.

RecallRadar, published by withglint.app at version 1.0.0, advertised four tools when we connected on 19 September 2026: diff_since, get_recall, list_agencies and search_recalls. The publisher's own description gives the coverage as U.S. FDA, USDA FSIS and CPSC recalls, with access by "API key or x402". It is the only server in the catalog whose description names FSIS or CPSC, which matters if your exposure includes meat, poultry and egg products or non-food consumer goods sold alongside them.

Argus HQ, published by argushq.ai at version 1.0.0, advertised five tools: get_company_history, get_recall_by_lot, get_warning_letter, list_recent_actions and search_enforcement. Its declared scope is FDA enforcement data — warning letters, recalls, approvals and 483s. It is narrower by agency and wider by document type. Those two shapes answer different questions: RecallRadar tells you what has been recalled across three agencies and what changed since a date; Argus HQ tells you what the FDA has said to a given firm over time.

Atlas Verified (atlasverified.ai) is doing a different job — pre-incident rather than post-incident. Its description is organic supply chain verification: certification, OFAC and FDA import checks. It requires credentials: an unauthenticated initialize returned HTTP 401, with a full OAuth chain in place, including protected-resource metadata and a dynamic client registration endpoint. Its 32 published scopes give the clearest picture of its surface, since the tool list cannot be read without a token. Fourteen are read scopes including suppliers:read, verification:read, shipments:read and tradedata:read; fourteen are write scopes including suppliers:write, verification:write, paperwork:write, signatures:write and ingestion:write. The remaining four — mcp:*, readonly, chat and documents — carry no read or write suffix.

fmcg.network, at version 0.6.1, bundles "FDA recall watch" with USDA FoodData Central nutrient lookup and EU FMCG labelling. It also returned 401 with OAuth and dynamic registration available, so its tool names could not be enumerated and the depth of the recall side is not visible from outside. We file it under market and consumer intelligence rather than food safety because of that bundle, not because the recall claim is doubted.

One server in the food safety category is not a recall source at all: DAG Studio MCP is causal DAG analysis — backdoor paths, adjustment sets, bias simulation, described as validated against dagitty. That is a different kind of instrument, for a root-cause or epidemiological argument, and it is not a feed.

What adoption costs an IT team#

The first cost is architectural and unavoidable: none of the four declares an installable package, so all four are recorded as hosted-remote only over streamable HTTP, with no SSE remote declared. Six of the 33 servers in the catalog do publish a package; none of these does. That means no version to pin, no declared offline mode, and nothing in the records describing a way to run the component inside a validated environment of your own. During the one hour when a recall genuinely matters, availability is a third party's problem and your incident is still yours.

The second cost is that the two open servers publish nothing an identity team can attach to. Neither serves OAuth discovery metadata, so OAuth, dynamic registration, scopes and scope separation are all recorded as not documented or not checked. Nothing published tells you whether an individual analyst can be issued a revocable, read-scoped credential, or how you would evidence in a review that access was read-only — an unanswered question to put to the publisher, not a documented absence. RecallRadar's registry record declares one credential input, an Authorization header, optional and correctly marked secret; Argus HQ's record lists no credential input at all, and its secrets claim reads as not checked.

Invert the usual risk framing, though, and the picture changes. The payload here is public regulatory data, and the nine tool names enumerated across the two open servers are all retrieval verbs: search, get, list, diff. No write-shaped tool was advertised. The material exposure is therefore not exfiltration of your data but disclosure of your questions. A diff_since poll or a search naming a supplier, a brand or a lot code tells the operator of that endpoint what your quality team is worried about, and a repeated poll tells them your watch list. For all four servers, retention, audit logging, access control and data residency are recorded as not documented — sixteen claims, not one of them answered. You cannot tell a supplier audit where those queries are stored or for how long, because nobody has said.

The practical mitigation is cheap and worth doing on day one: route the calls through an egress proxy you control and keep the query log on your side. Nothing published commits any of these publishers to giving you one.

Atlas Verified inverts the trade. You get a real authorisation story — protected-resource metadata, a registration endpoint at api.atlasverified.ai/register, 32 named scopes including a blanket readonly — which is more than most of the catalog offers and enough to issue a narrow token. What you do not get before you hold credentials is the tool list: the endpoint returned 401, so we could not enumerate it. Fourteen write scopes are visible, and paperwork:write, signatures:write and ingestion:write are not casual grants. Ask the vendor for the tool inventory and the scope-to-tool mapping before an assistant is allowed anywhere near a token that includes them.

What "vendor-verified" means here, and what it does not#

All 33 servers we publish carry the maintainer type vendor-verified, and all four discussed here reached it the same way: the registry namespace resolves to a domain the publisher controls and the endpoint host sits inside that domain. app.withglint.recallradar maps to withglint.app; ai.argushq to argushq.ai; ai.atlasverified to atlasverified.ai; network.fmcg to fmcg.network. That is a provenance test. It says the thing at the end of the URL is run by the party whose name is on the package. It says nothing about company size, track record, financial stability or data quality.

The four score identically on our curation scale — 80 each, assembled from exactly the same three components: verified domain, a reachable endpoint, and a well-formed authentication or initialize response. A score built from those inputs cannot distinguish a deep enforcement archive from a thin proxy over a public API, and it is not trying to. So an evaluator has to read the signals underneath it.

Those signals are thin and worth stating plainly. Three of the four are at version 1.0.0 and fmcg.network at 0.6.1. Documented claim coverage runs from 6 of 18 for Argus HQ and 7 of 18 for RecallRadar, through 8 for fmcg.network, to 10 for Atlas Verified — against a catalog mean of 9.4. Three of the four declare no public repository at all. Argus HQ does declare one, at github.com/andrewjgaber-commits/empire-distribution: a personal namespace whose repository name does not match the product. We record the repository as public on the strength of that declaration and have not checked its licence or last commit; both read as not checked. Contrast the fourth server in the category, DAG Studio, where the repository was read: Apache-2.0, last push 61 days before the check. A repository link is worth what has been verified about it.

The reasonable conclusion is not that these servers are untrustworthy. It is that they are small, single-endpoint dependencies run by young publishers, and should be governed as such: a named internal owner, a review date, and an accepted answer to the question of what happens the week the endpoint stops responding. By the publishers' own descriptions, everything behind these tools is public agency data, so that failure costs you convenience and speed rather than data. That is the argument for adopting them quickly and depending on them lightly.

A pilot that fits the evidence#

Start with the two open servers, because there is nothing to procure. Both answered an unauthenticated initialize on 19 September 2026 — two of only five servers in the whole catalog that did — so a trial is a configuration entry in a client, reviewed by whoever governs outbound connections, not a contract. Run them both: they overlap on FDA and diverge usefully elsewhere.

Design the trial around the number nobody publishes. No registry record among the four states a refresh cadence, and we do not track data freshness as a claim, so lag is the thing to measure yourself. Take ten historical events in your own categories — ideally ones your team handled — and run them through search_recalls and search_enforcement. Check three things: whether the event is present at all, how long after the agency posting it appeared, and whether get_recall or get_warning_letter returns a record you would be willing to paste into an internal note. Completeness and lag decide whether this replaces a manual sweep or merely supplements one. Nothing on the page can tell you that; your categories can.

Keep the assistant's permissions honest to what is there. Across both open servers the nine advertised tools are all retrieval-shaped, so a read-only posture is the natural one — but it is a property of what was advertised, not a guarantee enforced by a scope system, because neither server publishes scopes. Treat the write question as unanswered rather than answered in your favour.

Handle Atlas Verified on a separate track, because it is a different purchase with a different question attached. It sits on the supplier side, before an incident, and it has both the strongest authorisation story in this group and the least visible tool surface. Ask for the tool list and the scope mapping, then ask for a token scoped to readonly or to the specific read scopes you need, and decline the write scopes until there is a named workflow that requires them.

Finally, write the boundary into the runbook. The output of any of these tools is a lead: it tells a human where to look and what to read. The determination, the hold, the customer notification and the record that proves you acted stay in systems none of these four servers reaches, and no server in the catalog is described as a quality-management, complaint or CAPA system. Building the pilot that way costs nothing now and saves an argument later.

Servers that serve this today

Servers relevant to Food safety and recall monitoring with MCP
ServerWhy it fitsAuthRead-only grantable
RecallRadar

Vendor-published

Four tools — search_recalls, get_recall, diff_since, list_agencies — across FDA, USDA FSIS and CPSC. Answered unauthenticated on 19 Sep 2026.NoNot checked
Argushq Enforcement Database

Vendor-published

Five FDA enforcement tools, including get_warning_letter, get_recall_by_lot and get_company_history. Deeper history, one agency, no credential needed.NoNot checked
Atlasverified Atlas

Vendor-published

Supplier-side checks — organic certification, OFAC, FDA import — behind OAuth with 32 declared scopes, 14 of them write scopes.YesYes
fmcg.network

Vendor-published

Publisher declares FDA recall watch alongside USDA nutrient lookup and EU labelling. OAuth-gated, so its tools could not be listed.YesNot checked

What is missing

Checked against all 33 servers we publish, from a registry of 33,512, on .

  • No European rapid-alert coverage: no description among the 33 published servers mentions RASFF. The only European regulatory data declared anywhere is fmcg.network's "EU FMCG labelling", and its tool list could not be enumerated because the endpoint returned 401. The catalog's one other European entry, offerhopper.ai, is German grocery and drugstore pricing, not alerts.
  • No non-US national recall feed: the agencies named across the catalog are FDA, USDA FSIS and CPSC. No server mentions Canada's CFIA, the UK Food Standards Agency, FSANZ or EFSA.
  • No quality-management system of record: no description among the 33 mentions CAPA, complaint handling, deviations, HACCP or LIMS. An assistant can read an enforcement record but cannot open or update the internal record that evidences your response.
  • No lot genealogy from your own systems: the erp-and-supply-chain category is published in our taxonomy with zero servers, and the absent-vendor list names Blue Yonder, Kinaxis, o9 Solutions, Manhattan Associates, Coupa, Anaplan and E2open. Argus HQ advertises a tool named get_recall_by_lot, but that server's declared scope is public FDA enforcement data, not your shipment records.
  • No audit-scheme certification lookup: Atlas Verified declares organic certification, OFAC and FDA import checks. No server in the catalog declares BRCGS, SQF or FSSC 22000 certificate status.
  • No refresh cadence anywhere: none of the four registry records states how often its data updates, and we do not carry a freshness claim. Lag against the agency source has to be measured by the adopting team.
  • No self-hostable option among these four: none declares an installable package, against six of 33 across the catalog. No air-gapped or version-pinned deployment is declared for any of them.
  • No documented operational controls: audit logging, access control, data residency and retention are all "not documented" for all four servers — 16 claims, none answered by any publisher.
  • No visible tool inventory for the two authenticated servers: Atlas Verified and fmcg.network both returned 401, so tool names could not be enumerated. Atlas Verified's 32 published scope names, 14 of them write scopes, are the only public description of its write surface.
  • No public source code for three of the four: RecallRadar, Atlas Verified and fmcg.network declare no repository, so the query logic cannot be read and nothing survives the endpoint going away.

Questions

Can an assistant watch for new recalls on its own?
Not without a scheduler you supply. RecallRadar exposes a tool called diff_since, which is the change-detection primitive a watch needs, and Argus HQ exposes list_recent_actions. But an MCP server answers a client's call; nothing in these records describes a push, webhook or subscription. Something on your side has to run the query on a cadence and decide what counts as new.
Do we need credentials to pilot this?
For the two recall search servers, not as of 19 September 2026. Our unauthenticated probe of RecallRadar (recallradar.withglint.app/mcp) and Argus HQ (argushq.ai/api/mcp) each returned HTTP 200 and a usable initialize response. RecallRadar's registry record does declare an optional Authorization header marked secret, and its publisher description mentions an API key or x402, so a credentialed tier may exist. Atlas Verified and fmcg.network both returned 401.
Which one suits a plant quality team versus corporate regulatory affairs?
A plant team chasing a supplier alert or a complaint tends to want breadth and recency across agencies: RecallRadar covers FDA, USDA FSIS and CPSC and has a diff tool. A regulatory affairs group building a picture of a firm's enforcement history wants depth on one agency: Argus HQ adds warning letters, 483s, approvals and get_company_history, all FDA. Running both is cheap, since neither required a credential when we checked.
Is it safe to point an assistant at an unauthenticated third-party endpoint?
The payload is public regulatory data, so the exposure is not data loss but disclosure of the question. A query naming your supplier, brand or lot code reveals what your quality team is investigating, and retention, audit logging, access control and data residency are all recorded as not documented for all four servers. If that matters, route calls through an egress proxy you control and log them on your side, because nothing published promises you a log from theirs.
Can any of these cover our EU or UK sites?
Not for alerts. No description among the 33 published servers mentions RASFF, the UK Food Standards Agency, Canada's CFIA, FSANZ or EFSA. The only European regulatory data declared anywhere in the catalog is fmcg.network's "EU FMCG labelling", and that server requires credentials, so we could not enumerate its tools to see what the labelling side actually does. The catalog's one other European entry, offerhopper.ai, covers live prices and deals for German grocery and drugstore chains, which is retail data rather than a regulatory feed.
Can we run any of this inside our own network?
Not from anything published. None of the four declares an installable package, so deploy.self_host is recorded as unsupported for each; six of the 33 servers we publish do declare one. Every call therefore leaves your network for a single vendor endpoint over streamable HTTP. No version to pin, no air-gapped mode and no validated-environment deployment appears in any of the four records. If you need one, that is a question to put to the publisher, not something the registry answers.

Evaluate these for your own stack

Compare the servers above side by side against your own requirements, and export the result with every source and verification date attached.