openFDA Regulatory Metadata MCP server

<!-- mcp-name: com.blackswancausallabs/openfda-mcp -->

openFDA MCP

An MCP server exposing FDA regulatory metadata (drugs, biologics, and medical devices) through the openFDA API.

Built by Black Swan Causal Labs as the identifier-resolution layer for a real-world-evidence (RWE) case roster: given an FDA application number or a product name, resolve it to authoritative regulatory metadata.

Why this exists

There are other openFDA MCP servers, and several are broader. This one is narrow on purpose: it is the instrument that resolved the application numbers in a specific published RWE dataset, and it exists so that dataset can name the tool that produced it.

That matters more than it might sound. Whether BLA 125123/2058 resolves to a particular product, or DEN160026 to a particular device class, is a decision made by a piece of software — and a different wrapper can yield a different roster. "We used openFDA" is not a sufficient methods statement; "openfda-mcp v0.1.0" is. If you use this in research, pin the version.

Its practical edge over a general openFDA client is the device half: resolving a CDRH submission number to a risk class takes a three-hop chain (number → product code → classification) with two non-obvious traps, both handled here.

Tools

Drugs and biologics (/drug/* — CDER, CBER)

Devices (/device/* — CDRH)

Install

pip install openfda-mcp

Add to your MCP client config:

{
  "mcpServers": {
    "openfda": {
      "command": "openfda-mcp",
      "env": { "OPENFDA_API_KEY": "${OPENFDA_API_KEY:-}" }
    }
  }
}

The API key is optional. Without one, openFDA allows 40 requests/min and 1,000/day, which is enough for interactive use. A free key raises it to 240/min and 120,000/day — worth having for bulk sweeps.

Two findings worth knowing

Both were established empirically and are not obvious from FDA's docs.

De Novo grants live in the 510(k) endpoint. DEN###### numbers are stored in the k_number field of /device/510k. There is no De Novo endpoint, and looking for one leads to the wrong conclusion that De Novo numbers can't be resolved. They can.

HDE numbers are not in openFDA at all. Neither the 510(k) nor the PMA endpoint carries H######, so no product code — and therefore no classification — is retrievable. This server still reports deviceclass: "III" for them, by regulatory inference: HDE is by definition the pathway for devices that would otherwise require a PMA. medicalspecialty stays null, because that one really is unavailable, and deviceclasssource says which is which.

Transient failures are never silent

A genuine absence and a failed request are different things, and this package keeps them different:

backoff, then raises OpenFDATransientError; never cache this

• not found (HTTP 404, or 200 with no results) → returns None; safe to cache
• transient failure (timeout, connection error, 429, 5xx) → retried with

• rejected request (other 4xx) → raises OpenFDARequestError

Shortened. The full README is on GitHub.