FAERS MCP Server

Overview Schema Source Related Servers Discussions Admin

faers_ebgm

Read-onlyIdempotent

Compute empirical Bayes (EBGM/EB05) disproportionality scores for a drug's adverse events, shrinking observed-to-expected ratios toward 1 when evidence is limited.

Instructions

Empirical Bayes signal scores (EBGM with EB05/EB95) via the Gamma-Poisson Shrinker.

EBGM shrinks the observed-to-expected ratio toward 1 in proportion to how little evidence supports it. EB05 is the conventional screening statistic; EB05 > 2 is the usual threshold. The prior is fitted across a drug x event background table, so the FIRST call for a FAERS release builds and caches that table (~100 s, 3 + background_drugs calls). Call faers_warm_cache first, or raise the client timeout. Later calls take a few seconds.

Input Schema

TableJSON Schema

Name	Required	Description
`top_n`	No	Events to score when `events` is omitted.
`events`	No	Specific MedDRA PTs. Omit to score the drug's most-reported events.
`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'.
`min_cases`	No	Minimum observed count for a row.
`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.
`stratify_by`	No	Adjust expected counts for a confounder. Stratification enters MGPS only through E, so the prior is refitted. ~2 calls per stratum, cached. 'year' resolves its strata from the data and prunes negligible years.
`background_drugs`	No	Substances in the background table the prior is fitted on. Building it costs 3 + this many calls, once per FAERS release, then it is cached.
`background_events`	No	Terms in the background table.

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

A4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the expensive first-call cost (~100 s, 3 + background_drugs calls), the caching lifetime (once per FAERS release), and the timeout remedy. This is exactly the behavioral context an agent needs before invoking a tool that can block for minutes.

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?

Roughly five sentences, front-loaded with the method and the screening threshold, then the cost warning. Dense but every line carries information; the only flab is mild detail on the shrinker mechanics.

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?

With a rich 10-parameter schema, an output schema, and full annotation coverage, the description correctly focuses on the non-obvious parts: cost, caching, and stratification side effects. The remaining gap is the absence of sibling routing guidance for a tool in a cluster of signal-detection alternatives.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: stratification enters MGPS only through expected counts so the prior is refitted, ~2 calls per stratum, and 'year' resolves and prunes strata from the data. That meaning isn't recoverable from the schema descriptions alone.

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 names a specific statistic and method ('Empirical Bayes signal scores (EBGM with EB05/EB95) via the Gamma-Poisson Shrinker') and explains what EBGM does mechanically. An agent can tell this computes Bayesian disproportionality scores rather than raw counts, though it never explicitly distinguishes itself from faers_disproportionality or faers_signal_screen.

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 interpretive guidance ('EB05 is the conventional screening statistic; EB05 > 2 is the usual threshold') and an operational instruction to call faers_warm_cache first or raise the timeout. However, it never says when to prefer this tool over faers_disproportionality or faers_signal_screen, so sibling selection is left to inference.

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

Deploy Server