FAERS MCP Server

Overview Schema Source Related Servers Discussions Admin

faers_search_cases

Read-onlyIdempotent

Search the FDA Adverse Event Reporting System for individual case safety reports by drug name, returning compact triage cards with seriousness, reactions, and outcomes, or full records.

Instructions

Search FAERS for individual case safety reports (ICSRs).

Returns compact triage cards by default: report id, dates, seriousness flags, suspect drugs, reactions and outcomes. Pass full=true for complete records.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`full`	No	Return complete ICSR records (~72 KB each) instead of compact cards.
`skip`	No	Pagination offset (openFDA ceiling 25000).
`sort`	No	openFDA sort, e.g. 'receivedate:desc'.	receivedate:desc
`limit`	No	Records per page.
`events`	No	MedDRA preferred terms, e.g. ['PANCREATITIS']. Case-insensitive.
`date_to`	No	End of a receivedate window, YYYYMMDD. Must be paired with date_from.
`date_from`	No	Start of a receivedate window, YYYYMMDD. Must be paired with date_to.
`drug_name`	Yes	Active substance name, e.g. 'EMPAGLIFLOZIN'.
`fatal_only`	No	Restrict to fatal cases (seriousnessdeath=1).
`raw_filter`	No	Extra Lucene clause ANDed onto the preset query, e.g. 'patient.patientsex:2'. Applied to every marginal of a contingency table. See faers_describe_fields.
`role_basis`	No	'suspect_verified' checks each returned record for the drug in a suspect role.	any
`serious_only`	No	Restrict to serious cases (serious=1).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value on top: the default return shape is a compact triage card enumerating report id, dates, seriousness flags, suspect drugs, reactions and outcomes, and full=true yields complete records. It doesn't mention the openFDA pagination ceiling (25000) or rate limits, but that is minor.

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?

Three tight sentences, front-loaded with the core action and then the return-mode distinction. The field list in sentence two is slightly over-enumerated given the output schema exists, but nothing is wasted.

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 12-parameter read-only search with 100% schema coverage and an output schema, the description supplies everything the agent needs: what it does, the default compact return, and how to opt into full records. No material gaps remain.

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 all 12 parameters including 'full'. The description only amplifies 'full' versus the default card mode and adds nothing for skip/sort/limit/dates. Baseline 3 is appropriate when the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search') and resource ('FAERS individual case safety reports (ICSRs)'), which is more precise than the sibling names alone. It does not explicitly name which sibling (e.g. faers_raw_search, faers_get_report) it contrasts with, so an agent still has to infer the boundary, keeping it out of 5 territory.

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?

It gives one internal usage rule ('Pass full=true for complete records') but no when-to-use/when-not guidance relative to the many siblings. The agent must infer whether this or faers_raw_search, faers_case_counts, or faers_get_report is the right entry point.

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

Deploy Server