Skip to main content
Glama
mymedi-ai-mcp-server

mymedi-ai-mcp-server

by MyMedi-AI

Drug-combination adverse-event disproportionality (FDA FAERS)

drug_interactions
Read-only

Analyze co-reported adverse events for 2–5 drugs using FAERS counts, top reactions, and PRR disproportionality to flag statistical signals—not clinical interaction evidence.

Instructions

Adverse event reports that name drugs together: coReportCount, the number of FAERS reports naming every listed drug; the reactions most often named in them; and for each reaction a proportional reporting ratio (PRR) with a 95% confidence interval against the reports of each drug without the others. A reaction is marked disproportionate when it has at least 3 co-reports and the lower bound exceeds 1 against every drug (null when a comparison cannot be computed). Drugs are matched by the product name as reported: a brand name such as Coumadin is not merged with its generic, warfarin. A name no FAERS report names is refused (refunded), naming it. FAERS reports are unverified and can be duplicated: report counts and disproportionality are statistical associations, not evidence of an interaction or of causation, and no substitute for a clinical drug-interaction reference. Source: the FDA Adverse Event Reporting System (FAERS), via openFDA.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "drugs": "<drugs>"
    },
    "name": "drug_interactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
drugsYesArray of 2-5 different drug names (brand or generic), each matched against the product name reported in FAERS. Drug names need at least two letters or digits and may otherwise hold only spaces, hyphens, apostrophes, periods, slashes, parentheses and commas; accents, curly apostrophes, ® and ™, "+" and "&", and strengths such as 0.5% or 1:100,000 are normalized first (a refused name is refunded)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.9
    • changedInput schema / properties / drugs / description
      Previous value: -"Array of 2-5 drug names to check for interactions"New value: +"Array of 2-5 different drug names (brand or generic), each matched against the product name reported in FAERS. Drug names need at least two letters or digits and may otherwise hold only spaces, hyphens, apostrophes, periods, slashes, parentheses and commas; accents, curly apostrophes, ® and ™, \"+\" and \"&\", and strengths such as 0.5% or 1:100,000 are normalized first (a refused name is refunded)"
    • addedInput schema / properties / drugs / items / maxLength
      Added value: +500
  2. Addedv1.2.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses the refusal-and-refund behavior for unknown drug names, the null result when a comparison cannot be computed, the exact disproportionality threshold (≥3 co-reports, lower bound >1 against every drug), and the brand-vs-generic non-merging rule. It also warns that FAERS reports are unverified, duplicable, and associational — meaningful context the annotations cannot carry.

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?

Every sentence carries information, but the opening is a long dense clause chain that leads with return fields rather than a one-line statement of what the tool does. It is efficient yet slightly front-loading-poor.

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?

With one parameter, full schema coverage, and no output schema, the description still explains what is returned (counts, reactions, PRR with CI) and what edge cases produce (nulls, refusals). Nothing an agent needs to invoke it correctly is missing.

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 semantic value: names are matched against the reported product name, and a brand such as Coumadin is not merged with warfarin. The normalization details are largely duplicated from the schema, which caps this at 4.

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 names the exact resource (FAERS reports naming drugs together) and the exact computation (coReportCount, top reactions, PRR with 95% CI versus each drug alone). This is clearly distinct from siblings like drug_lookup, drug_enrich, and drug_rxnorm, which do not compute disproportionality. An agent can identify this tool without opening the schema.

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?

Usage context is clear: 2-5 drugs, combination-level analysis, and an explicit exclusion ('no substitute for a clinical drug-interaction reference'). It does not name a specific sibling tool to use instead for single-drug or interaction-reference needs, which keeps it short of a 5.

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