DDI-Checker — MCP Server (Prototype) for Interaction Research

Experimental prototype, not for clinical use, not for patient care.

An interaction (a drug-drug interaction, or DDI) means two drugs affect each other. For a pair of active ingredients, the tool checks whether official sources name such an interaction and which side effects have been co-reported for that pair. MCP stands for Model Context Protocol — an open standard through which an AI assistant connects to external tools and data sources; here it makes the lookup available to an AI system. Throughout, the server follows a cite-only principle: it reports only the source finding — what the source says — never an assessment of its own.

What the server does

Three tools work together:

• Label check (check_pair, openFDA Drug Label): Does a drug’s official US label name the other ingredient in an interaction or warning section? It checks both directions, and matches both by name and by drug class — the pharmacological group a substance belongs to, such as NSAIDs (non-steroidal anti-inflammatory drugs) or SSRIs (selective serotonin reuptake inhibitors).
• Co-reported side effects (coreported_adverse_events, FAERS): Which adverse events have been reported together for exactly this pair of ingredients?
• Multiple ingredients, pairwise (screen_regimen): For a list of ingredients, the server looks up each occurring pair on its own (with n ingredients, n·(n−1)/2 pairs) — a pairwise reference lookup over the list, not an overall assessment of the medication. Interactions are a multifactorial phenomenon; the pairwise check is a tractable approximation, not a complete picture.

The sources

openFDA and FAERS are public-domain US government data; RxNorm/RxClass are queried via the open RxNav API:

• openFDA — the open query interface (API, Application Programming Interface: a machine-readable interface through which a program fetches data) of the FDA, the US Food and Drug Administration. It provides the drug labels.
• FAERS (FDA Adverse Event Reporting System) — a database of spontaneous reports: voluntarily submitted suspected side effects, e.g. from health professionals, patients, or manufacturers. It shows what was reported — not what is proven.
• RxNorm and RxClass — naming and classification services from the US National Library of Medicine (NLM). They translate any input or brand name into the one standard US ingredient name (for example paracetamol → acetaminophen) and also supply the drug class. Without this normalization the lookup would already fail on differing spellings and names.

Signal or noise: the PRR

Rather than just passing the FAERS reports through, the server computes the PRR (Proportional Reporting Ratio). The PRR is a standard disproportionality measure in pharmacovigilance for signal detection from spontaneous reports — introduced by Evans et al. 2001 and commonly used for FAERS analyses. Put simply: does a given side effect occur far more often for this pair than would be expected across all reports? If so, that is a disproportionality signal — a statistical flag that separates a real signal from general reporting noise. Crucially, such a signal is a hint, not proof. Being reported together is not the same as a causal link.

Cite, don’t judge

What cite-only means in practice: no severity rating, no therapy recommendation — the server only reports the source finding. The computed PRR, too, is a statistical signal, not a severity grade. The result found=false therefore explicitly does not mean “no interaction”, only: “the sources checked do not name one”. Every response carries the note that the clinical judgment stays with the pharmacist.

Whether software is a medical device is decided under the MDR (Medical Device Regulation, EU 2017/745) not by the technology but by its intended purpose — the purpose the manufacturer explicitly ascribes to the tool. The moment a system assigns severities or supports treatment decisions, it has a medical intended purpose and would be regulated as a medical device. As a pure information system, the tool gives itself no such purpose.

Limitations

Methodological and source-related:

• found=false does not mean “no interaction”, but: the US sources queried name none.
• openFDA provides US prescribing information, FAERS US spontaneous reports. Active ingredients approved in Germany/Europe but not marketed in the US have no label, even when the name resolves. The German prescribing information may also name other interactions and warnings.
• FAERS is spontaneous reporting, not causality. The PRR filters generic noise but does not separate an interaction signal from the co-reporting already expected from each drug’s individual profile.
• It checks pair by pair; additive effects (e.g. serotonergic load, QT prolongation, anticholinergic burden) are not pairwise-decomposable and remain outside the model.

The server provides research citations; the clinical judgment stays with the pharmacist.

Technical setup

Data flow:
RxNorm normalisation → label scan (Branch A) and FAERS signal (Branch B) → cite-only JSON back to the client

This is how a request flows: the AI client invokes one of the three tools — in the vocabulary of AI systems, an MCP tool call (also tool use). It passes only the raw ingredient names, as they arrive. The first step inside the tool is RxNorm normalisation — deliberately server-side, so the client need not know US ingredient names. Only then come the label check and the FAERS signal. Back to the client goes a cite-only JSON dict, i.e. the result as a structured data record.

The server follows the MCP standard and returns its results as JSON — a simple, machine-readable text format. The connection to the AI client runs over streamable-http (the transport between client and server), built with the FastMCP component. It runs on own infrastructure (Hetzner, Coolify) as a working prototype for demonstration and research.