How do I use fda-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fda-mcp Search for adverse events related to OZEMPIC" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

fda-mcp

by Limecooler

Overview Schema Related Servers Score Discussions

Python

Remote

FDA MCP Server

PyPI Python License: MIT

An MCP server that provides LLM-optimized access to FDA data through the OpenFDA API and direct FDA document retrieval. Covers all 21 OpenFDA endpoints plus regulatory decision documents (510(k) summaries, De Novo decisions, PMA approval letters).

Quick Start

No clone or local build required. Install uv and run directly from PyPI:

uvx fda-mcp

That's it. The server starts on stdio and is ready for any MCP client.

Related MCP server: fda-approvals-mcp

Usage with Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "fda": {
      "command": "uvx",
      "args": ["fda-mcp"],
      "env": {
        "OPENFDA_API_KEY": "your-key-here"
      }
    }
  }
}

Config file location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Usage with Claude Code

Add directly from the command line:

claude mcp add fda -- uvx fda-mcp

To include an API key for higher rate limits:

claude mcp add fda -e OPENFDA_API_KEY=your-key-here -- uvx fda-mcp

Or add interactively within Claude Code using the /mcp slash command.

API Key (Optional)

The OPENFDA_API_KEY environment variable is optional. Without it you get 40 requests/minute. With a free key from open.fda.gov you get 240 requests/minute.

Features

4 MCP tools — one unified search tool, count/aggregation, field discovery, and document retrieval
3 MCP resources for query syntax help, endpoint reference, and field discovery
All 21 OpenFDA endpoints accessible via a single search_fda tool with a dataset parameter
Server instructions — query syntax and common mistakes are injected into every LLM context automatically
Actionable error messages — inline syntax help, troubleshooting tips, and .exact suffix warnings
FDA decision documents — downloads and extracts text from 510(k) summaries, De Novo decisions, PMA approvals, SSEDs, and supplements
OCR fallback for scanned PDF documents (older FDA submissions)
Context-efficient responses — summarized output, field discovery on demand, pagination guidance

Tools

Tool	Purpose
`search_fda`	Search any of the 21 OpenFDA datasets. The `dataset` parameter selects the endpoint (e.g., `drug_adverse_events`, `device_510k`, `food_recalls`). Accepts `search`, `limit`, `skip`, and `sort`.
`count_records`	Aggregation queries on any endpoint. Returns counts with percentages and narrative summary. Warns when `.exact` suffix is missing on text fields.
`list_searchable_fields`	Returns searchable field names for any endpoint. Call before searching if unsure of field names.
`get_decision_document`	Fetches FDA regulatory decision PDFs and extracts text. Supports 510(k), De Novo, PMA, SSED, and supplement documents.

Dataset Values for `search_fda`

Category	Datasets
Drug	`drug_adverse_events`, `drug_labels`, `drug_ndc`, `drug_approvals`, `drug_recalls`, `drug_shortages`
Device	`device_adverse_events`, `device_510k`, `device_pma`, `device_classification`, `device_recalls`, `device_recall_details`, `device_registration`, `device_udi`, `device_covid19_serology`
Food	`food_adverse_events`, `food_recalls`
Other	`historical_documents`, `substance_data`, `unii`, `nsde`

Resources (3)

URI	Content
`fda://reference/query-syntax`	OpenFDA query syntax: AND/OR/NOT, wildcards, date ranges, exact matching
`fda://reference/endpoints`	All 21 endpoints with descriptions
`fda://reference/fields/{endpoint}`	Per-endpoint field reference

Example Queries

Once connected, you can ask Claude things like:

"Search for adverse events related to OZEMPIC"
"Find all Class I device recalls from 2024"
"What are the most common adverse reactions reported for LIPITOR?"
"Get the 510(k) summary for K213456"
"Search for PMA approvals for cardiovascular devices"
"How many drug recalls has Pfizer had? Break down by classification."
"Find the drug label for metformin and summarize the warnings"
"What COVID-19 serology tests has Abbott submitted?"

Configuration

All configuration is via environment variables:

Variable	Default	Description
`OPENFDA_API_KEY`	(none)	API key for higher rate limits (240 vs 40 req/min)
`OPENFDA_TIMEOUT`	`30`	HTTP request timeout in seconds
`OPENFDA_MAX_CONCURRENT`	`4`	Max concurrent API requests
`FDA_PDF_TIMEOUT`	`60`	PDF download timeout in seconds
`FDA_PDF_MAX_LENGTH`	`8000`	Default max text characters extracted from PDFs

OpenFDA Query Syntax

The search parameter on all tools uses OpenFDA query syntax:

# AND
patient.drug.openfda.brand_name:"ASPIRIN"+AND+serious:1

# OR (space = OR)
brand_name:"ASPIRIN" brand_name:"IBUPROFEN"

# NOT
NOT+classification:"Class III"

# Date ranges
decision_date:[20230101+TO+20231231]

# Wildcards (trailing only, min 2 chars)
device_name:pulse*

# Exact matching (required for count queries)
patient.reaction.reactionmeddrapt.exact:"Nausea"

Use list_searchable_fields or the fda://reference/query-syntax resource for the full reference.

Installation Options

From PyPI (recommended)

# Run directly without installing
uvx fda-mcp

# Or install as a persistent tool
uv tool install fda-mcp

# Or install with pip
pip install fda-mcp

From source

git clone https://github.com/Limecooler/fda-mcp.git
cd fda-mcp
uv sync
uv run fda-mcp

Optional: OCR support for scanned PDFs

Many older FDA documents (pre-2010) are scanned images. To extract text from these:

# macOS
brew install tesseract poppler

# Linux (Debian/Ubuntu)
apt install tesseract-ocr poppler-utils

Without these, the server still works — it returns a helpful message when it encounters a scanned document it can't read.

Development

# Install with dev dependencies
git clone https://github.com/Limecooler/fda-mcp.git
cd fda-mcp
uv sync --all-extras

# Run unit tests (187 tests, no network)
uv run pytest

# Run integration tests (hits real FDA API)
OPENFDA_TIMEOUT=60 uv run pytest -m integration

# Run a specific test file
uv run pytest tests/test_endpoints.py -v

# Start the server directly
uv run fda-mcp

Project Structure

src/fda_mcp/
├── server.py              # FastMCP server entry point
├── config.py              # Environment-based configuration
├── errors.py              # Custom error types
├── openfda/
│   ├── endpoints.py       # Enum of all 21 endpoints
│   ├── client.py          # Async HTTP client with rate limiting
│   └── summarizer.py      # Response summarization per endpoint
├── documents/
│   ├── urls.py            # FDA document URL construction
│   └── fetcher.py         # PDF download + text extraction + OCR
├── tools/
│   ├── _helpers.py        # Shared helpers (limit clamping)
│   ├── search.py          # search_fda tool (all 21 endpoints)
│   ├── count.py           # count_records tool
│   ├── fields.py          # list_searchable_fields tool
│   └── decision_documents.py
└── resources/
    ├── query_syntax.py    # Query syntax reference
    ├── endpoints_resource.py
    └── field_definitions.py

How It Works

LLM Usability

The server is designed to be easy for LLMs to use correctly:

Server instructions — Query syntax, workflow guidance, and common mistakes are injected into every LLM context automatically via the MCP protocol (~210 tokens).
Unified tool surface — A single search_fda tool with a typed dataset parameter replaces 9 separate search tools, eliminating tool selection confusion.
Actionable errors — InvalidSearchError includes inline syntax quick reference. NotFoundError includes troubleshooting steps and the endpoint used. No more references to invisible MCP resources.
Visible warnings — Limit clamping and missing .exact suffix produce visible notes instead of silent fallbacks.
Response summarization — Each endpoint type has a custom summarizer that extracts key fields and flattens nested structures. Drug labels truncate sections to 2,000 chars. PDF text defaults to 8,000 chars.
Field discovery via tool — Instead of listing all searchable fields in tool descriptions (which would cost ~8,000-11,000 tokens of persistent context), the list_searchable_fields tool provides them on demand.
Smart pagination — Default page sizes are low (10 records). Responses include total_results, showing, and has_more. When results exceed 100, a tip suggests using count_records for aggregation.

FDA Decision Documents

These documents are not available through the OpenFDA API. The server constructs URLs and fetches directly from accessdata.fda.gov:

Document Type	URL Pattern
510(k) summary	`https://www.accessdata.fda.gov/cdrh_docs/reviews/{K_NUMBER}.pdf`
De Novo decision	`https://www.accessdata.fda.gov/cdrh_docs/reviews/{DEN_NUMBER}.pdf`
PMA approval	`https://www.accessdata.fda.gov/cdrh_docs/pdf{YY}/{P_NUMBER}A.pdf`
PMA SSED	`https://www.accessdata.fda.gov/cdrh_docs/pdf{YY}/{P_NUMBER}B.pdf`
PMA supplement	`https://www.accessdata.fda.gov/cdrh_docs/pdf{YY}/{P_NUMBER}S{###}A.pdf`

Text extraction uses pdfplumber for machine-generated PDFs, with automatic OCR fallback via pytesseract + pdf2image for scanned documents.

License

MIT

Available Tools

4 tools

count_recordsA

Count/aggregate records by field across any OpenFDA endpoint. Returns top values with counts, percentages, and a narrative summary.

When to use: Getting statistics, distributions, or "top N" lists. For individual records, use search_fda instead.

Args: endpoint: One of the 21 OpenFDA endpoint paths (e.g., "drug/event", "device/510k"). Call list_searchable_fields to see valid endpoints. count_field: Field to aggregate on. IMPORTANT: You MUST add .exact suffix for text fields (e.g., "patient.reaction.reactionmeddrapt.exact"). Without .exact, text fields are tokenized and counts will be wrong. Numeric and date fields do NOT need .exact. search: Optional search filter to narrow records before counting. limit: Number of top values to return (default 10, max 1000).

Examples: Top adverse reactions for a drug: endpoint="drug/event", count_field="patient.reaction.reactionmeddrapt.exact", search='patient.drug.openfda.brand_name:"ASPIRIN"' Device recalls by classification: endpoint="device/enforcement", count_field="classification.exact" Food recall reasons: endpoint="food/enforcement", count_field="reason_for_recall.exact", limit=5

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`search`	No
`endpoint`	Yes
`count_field`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/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. It discloses return components (counts, percentages, narrative summary), the critical .exact suffix requirement with the consequence of tokenized counts, and the limit's default/max. It lacks rate limits or error behavior, but for this read/aggregate tool it provides substantial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a concise summary, 'When to use' section, labeled Args list, and practical examples. Every section earns its place and the markdown formatting improves scannability without adding fluff.

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

Completeness5/5

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

For a complex tool with 4 parameters and a non-obvious .exact suffix requirement, the description addresses the core nuances, gives multiple examples, and references sibling tools for additional context. The output schema exists, so not detailing return values is acceptable; the description still mentions the output composition.

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

Parameters5/5

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

Schema coverage is 0%, so the description must fully compensate. It does: endpoint is explained with examples and a cross-reference, count_field gets a crucial .exact warning with text vs numeric/date distinction, search is described as an optional filter, and limit has default and max values. Examples further clarify usage.

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?

The description clearly states 'Count/aggregate records by field across any OpenFDA endpoint,' giving a specific verb, resource, and scope. It distinguishes itself from the sibling tool search_fda, which is for individual records, and references list_searchable_fields for endpoint discovery.

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?

An explicit 'When to use' section states to use this for statistics, distributions, or top-N lists, and instructs to use search_fda for individual records. It also cross-references list_searchable_fields, providing clear guidance on when to use this tool vs alternatives.

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

get_decision_documentA

Fetch FDA regulatory decision documents (not available via OpenFDA API). Downloads the PDF from FDA servers and extracts text content.

When to use: After finding a device submission via search_fda (e.g., dataset="device_510k" or "device_pma"), use the submission number from those results to retrieve the full decision document.

Args: document_type: Type of document to retrieve. submission_number: FDA identifier. Formats: 510k_summary: "K" + 6 digits (e.g., "K213456") denovo_decision: "DEN" + 6 digits (e.g., "DEN200001") pma_approval/pma_ssed/pma_supplement: "P" + 6 digits (e.g., "P200001") supplement_number: Required for pma_supplement only (e.g., "013"). max_length: Max text characters to return (default 8000). Increase for longer documents.

Examples: document_type="510k_summary", submission_number="K213456" document_type="pma_approval", submission_number="P200001" document_type="pma_supplement", submission_number="P200001", supplement_number="013"

ParametersJSON Schema

Name	Required	Description	Default
`max_length`	No
`document_type`	Yes
`submission_number`	Yes
`supplement_number`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden. It discloses it downloads PDFs from FDA servers and extracts text, and explains max_length controls output character count. It doesn't mention error cases or explicitly state read-only behavior, but the key behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: a concise purpose sentence, a 'When to use' block, an Args list with format examples, and three concrete usage examples. Every sentence contributes useful information without redundant fluff.

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?

The tool has 4 parameters with format nuances and an output schema is present, so return structure need not be described. The description covers the workflow, parameter constraints, and examples. Minor gaps remain around error handling and document availability, but it's sufficiently complete for successful usage.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and does so thoroughly. It provides exact formats for each document_type (e.g., 'K' + 6 digits for 510k_summary), clarifies supplement_number is required only for pma_supplement, and specifies max_length default (8000). This goes far beyond the bare string types in the schema.

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?

The description opens with 'Fetch FDA regulatory decision documents' and specifies it downloads PDFs and extracts text, clearly stating the action and resource. It distinguishes from sibling search_fda by emphasizing this tool retrieves full documents after a submission is found, not perform searches.

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

Usage Guidelines4/5

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

An explicit 'When to use' section directs agents to use this after finding a device submission via search_fda, tying directly to sibling tool usage. It also notes the tool is 'not available via OpenFDA API,' implying a unique role, but it doesn't name exclusions for other siblings or when not to use.

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

list_searchable_fieldsA

List searchable fields for any OpenFDA endpoint. Returns field names, types, and descriptions.

When to use: Call this BEFORE searching if you're unsure which field names to use in a search query. Field names vary between endpoints.

Args: endpoint: One of the 21 OpenFDA endpoint paths: Drug: drug/event, drug/label, drug/ndc, drug/drugsfda, drug/enforcement, drug/shortage Device: device/event, device/510k, device/pma, device/classification, device/enforcement, device/recall, device/registrationlisting, device/udi, device/covid19serology Food: food/event, food/enforcement Other: other/historicaldocument, other/substance, other/unii, other/nsde category: "common" for the most frequently used fields (default), "all" for the complete field listing.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No		common
`endpoint`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/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. It transparently states the output ('field names, types, and descriptions') and the scope (all 21 endpoints, common vs. all fields). Although it doesn't explicitly say 'read-only', 'List' and 'Returns' make the non-mutating behavior clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every part earns its place: a one-sentence summary, a usage pointer, and a well-structured Args block. The endpoint list is necessary because the schema offers no descriptions. It is front-loaded and readable.

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

Completeness5/5

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

Given the tool's moderate complexity, the presence of an output schema, and the lack of annotations, the description is complete. It fully covers the endpoint and category parameters, explains when to use the tool, and states what results to expect.

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

Parameters5/5

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

The input schema has 0% description coverage, so the description must compensate. It does: the 'Args' section enumerates every allowed endpoint path grouped by Drug/Device/Food/Other, and explains the category parameter ('common' default, 'all' complete listing). This is far more informative than the bare schema.

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?

The description opens with a specific verb and resource: 'List searchable fields for any OpenFDA endpoint. Returns field names, types, and descriptions.' This clearly distinguishes it from siblings like search_fda (which executes searches) and count_records (which counts records).

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

Usage Guidelines4/5

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

It gives explicit when-to-use guidance: 'Call this BEFORE searching if you're unsure which field names to use in a search query. Field names vary between endpoints.' While it does not name a specific alternative tool, the 'before searching' naturally points to the search_fda sibling.

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

search_fdaA

Search any of the 21 OpenFDA datasets. Returns individual records.

When to use: Finding specific records — adverse events, drug labels, device submissions, recalls, etc. For aggregation/statistics, use count_records instead. If unsure which fields to search, call list_searchable_fields first.

Args: dataset: Which FDA dataset to search. Options by category:

    Drug:
      drug_adverse_events — FAERS adverse event reports
      drug_labels — SPL drug labeling (package inserts)
      drug_ndc — National Drug Code directory
      drug_approvals — NDA/ANDA/BLA approval history (Drugs@FDA)
      drug_recalls — Drug recall enforcement reports
      drug_shortages — Drug shortage reports

    Device:
      device_adverse_events — MDR adverse event reports
      device_510k — 510(k) clearances, De Novo grants, and HDE submissions
      device_pma — PMA approvals and supplements
      device_classification — Product code classification database
        (submission_type_id: 1=510k, 2=PMA, 4=510k Exempt, 6=De Novo, 7=HDE)
      device_recalls — Device recall enforcement reports
      device_recall_details — Detailed device recall information
      device_registration — Facility registrations and product listings
      device_udi — Unique Device Identifier database
      device_covid19_serology — COVID-19 serology test performance

    Food:
      food_adverse_events — CAERS adverse event reports
      food_recalls — Food/cosmetic recall enforcement reports

    Other:
      historical_documents — FDA historical documents
      substance_data — Substance data (GSRS)
      unii — Unique Ingredient Identifier codes
      nsde — NDC SPL Data Elements

search: OpenFDA query string. Quote string values and use + for spaces.
limit: Max results to return (default 10, max 100).
skip: Number of results to skip for pagination.
sort: Sort field and direction (e.g., "report_date:desc").

Examples: Drug adverse events: dataset="drug_adverse_events", search='patient.drug.openfda.brand_name:"ASPIRIN"' Drug labels: dataset="drug_labels", search='openfda.brand_name:"LIPITOR"' Device 510(k) clearances: dataset="device_510k", search='device_name:"pulse+oximeter"' De Novo grants (also in device_510k): dataset="device_510k", search='decision_code:"DENG"+AND+advisory_committee:"DE"' Food recalls: dataset="food_recalls", search='classification:"Class I"' Device classification lookup: dataset="device_classification", search='device_name:"oximeter"+AND+device_class:2'

ParametersJSON Schema

Name	Required	Description	Default
`skip`	No
`sort`	No
`limit`	No
`search`	Yes
`dataset`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that it returns individual records, not aggregates, and details query syntax with quoting and + for spaces, plus pagination and sorting behavior. It could mention rate limits or error handling, but the core behavior is transparent.

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 description is long but dense, with clear headers and practical examples. The dataset list is necessary given 21 enum values, and every section earns its place. Slightly verbose but not wasteful.

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

Completeness5/5

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

Covers all essential aspects: purpose, usage guidance, parameter semantics, and examples. Since an output schema exists, not detailing return values is fine. This is a complete description for a complex tool with many dataset options.

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

Parameters5/5

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

The description adds extensive meaning beyond the schema: dataset options are categorized and explained, search syntax is specified (quote strings, + for spaces), limit has default and max, skip is for pagination, and sort has a format example. This fully compensates for the 0% schema description coverage.

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?

Description clearly states it searches any of 21 OpenFDA datasets and returns individual records. It distinguishes from siblings by explicitly pointing to count_records for aggregation and list_searchable_fields for field guidance.

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 'When to use' section, stating it's for finding specific records and directing users to count_records for statistics and list_searchable_fields if unsure of fields. This gives clear when-to-use and alternatives guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.2.2Aug 2, 2026
- First observedcount_records
- First observedget_decision_document
- First observedlist_searchable_fields
- First observedsearch_fda

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct role: search_fda returns individual records, count_records provides aggregate statistics, list_searchable_fields shows schema metadata, and get_decision_document fetches FDA decision documents. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase underscores: search_fda, count_records, list_searchable_fields, get_decision_document. This makes tool selection predictable and easy.

Tool Count5/5

With 4 tools, the server is well-scoped for the OpenFDA data domain. Each tool earns its place and the count falls comfortably within the ideal 3-15 range.

Completeness5/5

The tool set covers the full workflow: exploring searchable fields, querying individual records, aggregating counts, and retrieving FDA decision documents. No obvious gaps exist for the stated domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

atlas-fda A
io.github.atlasbyauro
FDA 510(k)s, PMAs, recalls & trials, linked: predicate search and review-time stats for AI agents.
Biology & Medicine Government Data Open Data
71
Fda Devices A
io.github.pipeworx-io
FDA medical-device regulatory intelligence from keyless openFDA datasets.
Biology & Medicine Government Data
412
OpenFDA Safety DataOAuth
io.github.Taru0208
Search FDA safety data: drug adverse events, recalls, and device events.
Government Data Search Health & Wellness
2
openfda-mcp-server A
io.github.cyanheads
Query FDA data on drugs, food, devices, and recalls via openFDA. STDIO or Streamable HTTP.
Government Data Health & Wellness Open Data
1424

Related MCP Servers

OpenFDA FastMCP Server
Biology & Medicine Open Data Government Data
SuyashEkhande
F
license
Not graded
quality
D
maintenance
Enables AI agents to query and analyze FDA adverse events, drug labels, medical device clearances, and other public health datasets through natural language commands.
Updated 5 months ago (2026-04-12 13:12 UTC)
13
-
fda-approvals-mcp
Biology & Medicine Research & Data Open Data
guptaprakhariitr
F
license
Not graded
quality
D
maintenance
Enables querying FDA drug approvals, device clearances (510(k)), recalls, and adverse events via the openFDA API, providing tools for clinical and pharmaceutical research.
Updated 3 months ago (2026-06-11 08:39 UTC)
1
-
Healthcare Compliance MCP
Biology & Medicine Research & Data Legal & Compliance
red-cars-io
F
license
Not graded
quality
D
maintenance
Enables AI agents to access FDA and ClinicalTrials.gov data for medical device compliance, adverse event monitoring, and regulatory due diligence.
Updated 4 months ago (2026-05-05 01:38 UTC)
-
openfda-mcp-server
Biology & Medicine Search
ek-nath
A
license
A
quality
D
maintenance
Enables LLMs to search FDA drug labels and adverse event data via the OpenFDA API, supporting natural language queries for drug safety information.
Updated 8 months ago (2026-01-12 13:27 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Limecooler/fda-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

FDA MCP Server

Quick Start

Usage with Claude Desktop

Usage with Claude Code

API Key (Optional)

Features

Tools

Dataset Values for search_fda

Resources (3)

Example Queries

Configuration

OpenFDA Query Syntax

Installation Options

From PyPI (recommended)

From source

Optional: OCR support for scanned PDFs

Development

Project Structure

How It Works

LLM Usability

FDA Decision Documents

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Dataset Values for `search_fda`