Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@drug-label What are the boxed warnings for Eliquis?"
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.
Answers medication questions from the official FDA label, in the label's own words, with the label it came from: which manufacturer, which version, from when, and a link to read it on DailyMed. Also resolves any drug name, brand, misspelling or NDC through RxNorm, and reports FDA recalls and drug shortages.
A model asked about a drug answers from memory, and memory is out of date: labels change, boxed warnings are added, and interactions are revised. Drug Label reads the current label instead, and picks the right one: a common generic has hundreds of labels on DailyMed, most of them repackaged copies, so it chooses from manufacturers only (openFDA's original-packager index), with the brand's own NDA label first, and always says which label it used and how many others exist.
It is careful where mistakes are dangerous:
Look-alike names cause medication errors, so a misspelling is corrected only when one name is clearly meant. When two names are equally close, it refuses and asks which drug is meant.
A missing section is an explicit answer ("this label has no boxed warning section"), never a silent empty result.
Interaction answers are what each label says. NLM retired its drug-interaction API in 2024; this server does not pretend to replace it, and a label not mentioning an interaction does not mean there is none.
This is label information, not medical advice. Confirm anything that affects treatment with a pharmacist or prescriber.
No account or key needed. Built and maintained by Arhan Canli.
Needs Node.js 20 or newer. No account or key.
Claude Code
claude mcp add drug-label -- npx -y drug-label-mcpClaude Desktop: download drug-label-mcp-<version>.mcpb from the latest release and open it. The bundle is signed; verify it with gh attestation verify <file> --repo arhancanli/drug-label-mcp.
Any other client (Windsurf, Zed, Cline, Continue and others), in its MCP config file:
{
"mcpServers": {
"drug-label": {
"command": "npx",
"args": [
"-y",
"drug-label-mcp"
]
}
}
}Docker
docker build -t drug-label-mcp https://github.com/arhancanli/drug-label-mcp.git && docker run -i --rm drug-label-mcpHosted (Streamable HTTP): node src/server.mjs --http serves stateless MCP at POST /mcp (port from PORT, default 3000).
Related MCP server: DailyMed MCP Server
An agent calls find_drug with:
{
"name": "atorvastatin"
}and gets back (recorded from the live server on 2026-09-26):
{
"rxcui": "83367",
"name": "atorvastatin",
"term_type": "IN",
"ingredients": [
"atorvastatin",
"atorvastatin / ezetimibe",
"amlodipine / atorvastatin"
],
"brands": [
"Lipitor",
"Atorvaliq",
"Caduet"
],
"classes": [
{
"name": "Hydroxymethylglutaryl-CoA Reductase Inhibitors",
"type": "MOA"
},
{
"name": "HMG-CoA Reductase Inhibitor",
"type": "EPC"
}
],
"labels_total": 25,
"labels": [
{
"setid": "a60cc18b-0631-4cf0-b021-9f52224ece65",
"brand": "Lipitor",
"generic": "atorvastatin calcium",
"manufacturer": "Viatris Specialty LLC",
"application": "NDA020702",
"category": "NDA",
"form": "TABLET, FILM COATED",
"since": "2024-05-01"
},
{
"setid": "d9adb9e4-c495-9530-e5e3-7e3b01d53e4c",
"brand": "ATORVASTATIN CALCIUM",
"generic": "ATORVASTATIN CALCIUM",
"manufacturer": "Apotex Corp.",
"application": "ANDA090548",
"category": "ANDA",
"form": "TABLET, FILM COATED",
"since": "2012-05-29"
},
{
"setid": "901550e6-22be-68c9-eb86-f85a9c9dd998",
"brand": "Atorvastatin Calcium",
"generic": "Atorvastatin Calcium",
"manufacturer": "Dr. Reddy's Laboratories Limited",
"application": "ANDA091650",
"category": "ANDA",
"form": "TABLET",
"since": "2012-07-17"
},
{
"setid": "6ccdb6f3-22c7-5b48-46bc-ce4a4c65eb4d",
"brand": "Atorvastatin Calcium",
"generic": "Atorvastatin Calcium",
... (18 more lines)Tool | What it does |
| Resolves a brand or generic name, misspelling or NDC through RxNorm: ingredients, brands, FDA classes, and the best manufacturer labels (not repackagers) with set ids. Never guesses between look-alike names. |
| Returns one topic of the official FDA label as the label's own text under its headings, citing the label's set id, version and date. Says so when the label has no such section. |
| FDA drug recalls (class, reason, status, date, product) and shortage records (status, company, reason) for a drug, newest first, from openFDA. |
| Finds every paragraph of the official FDA label that mentions a term (another drug, grapefruit, alcohol, a condition), with its section heading and topic. |
Topics for label_section: boxed_warning, indications, dosage, contraindications,
warnings, interactions, pregnancy_lactation, specific_populations, adverse_reactions,
overdosage, description, how_supplied, clinical_pharmacology. Each maps to the FDA's section
codes, including the older WARNINGS and PRECAUTIONS layout and OTC Drug Facts labels.
Read-only: no tool changes anything outside this process.
Network: HTTPS only, to the hosts listed in package.json under factory.allowHosts, with a
deadline, a size cap and bounded retries; a stalled read is retried. Nothing else is contacted, and
nothing is logged except unexpected failures (to stderr, without your inputs).
Keeps to each source's limits (RxNav asks for at most 20 requests per second; openFDA allows 240 per minute without a key) and caches for 12 hours, as NLM asks. Parsed labels are kept in memory.
Label text keeps lists as items and tables row by row, repeating a cell that spans rows so each row reads on its own. Long answers are cut at 12,000 characters with a count of what was left out.
Results are compact JSON with a matching output schema.
Measured 2026-09-26 with gpt-5.4-mini, 10 fixed tasks graded by fixed checks (bench/tasks.json, raw results in bench/results/).
Server | Correct | Input tokens | Output tokens | Tool calls | Median time |
This server | 10/10 | 23729 | 459 | 14 | 4.1 s |
@ythalorossy/openfda, the most downloaded openFDA server | 7/10 | 118095 | 643 | 14 | 2.2 s |
Measured 2026-09-26 from Dubai, home connection against the live upstream, Node 24.19.0 (bench/perf.json, scripts/perf.mjs in the factory).
Call | First call | Repeat | Result size |
find_drug: atorvastatin (brand and generic manufacturers ranked) | 3673 ms | 1.2 ms | 1,560 chars |
find_drug: a misspelled name | 4053 ms | 0.9 ms | 1,591 chars |
label_section: warfarin boxed warning | 4171 ms | 0.5 ms | 1,437 chars |
label_section: Lipitor boxed warning (none) | 4192 ms | 0.3 ms | 508 chars |
search_label: Lipitor and grapefruit | 4694 ms | 0.4 ms | 3,766 chars |
label_section: metformin contraindications | 4468 ms | 0.6 ms | 1,257 chars |
recalls_shortages: metformin | 2352 ms | 0.7 ms | 4,766 chars |
First call: a fresh server process, including the TLS connection and the upstream's own time. Repeat: the same call again, answered from the in-process cache, so it shows this server's own overhead.
Tool definitions the model reads on every turn (name, description, input schema): 1,958 characters, against 23,915 for @ythalorossy/openfda, the most downloaded openFDA server. The full tool list, with the output schemas and annotations clients use to validate results, is 3,819 characters (24,351 for the alternative).
DailyMed (National Library of Medicine): FDA label text (SPL).
RxNorm through RxNav: drug names, ingredients, brands, NDCs, FDA pharmacologic classes. Only RxNorm's own content is used.
openFDA: the NDC directory (to find manufacturers' labels), recall enforcement reports and drug shortages.
All three are US government services. They do not endorse this server.
Citation Check: Verifies citations: finds fabricated or mismatched references and retractions, returns clean BibTeX.
End of Life: Is this version still supported? EOL dates, latest patch and upgrade target for 470+ products.
Internet Standards: RFC sections, status, obsoleted-by chains, errata and IANA registries for coding agents.
Package Truth: Checks packages exist before install: version, deprecation, vulnerabilities, licence. 7 ecosystems.
Recall Check: One recall check across CPSC, FDA and NHTSA: match by name, model number, UPC or VIN.
Satellite Imagery: Find the clearest Sentinel-2, Landsat, Sentinel-1 or NAIP scene for any place, with band links.
Vuln Priority: Which vulnerabilities to fix first: CISA KEV, EPSS, CVSS and CISA's SSVC decisions in one ranking.
MIT, Copyright (c) 2026 Arhan Canli.
Resolves a brand or generic name, misspelling or NDC through RxNorm: ingredients, brands, FDA classes, and the best manufacturer labels (not repackagers) with set ids. Never guesses between look-alike names.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Drug name or NDC |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| rxcui | Yes | |
| labels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds a critical behavioral constraint: 'Never guesses between look-alike names,' and specifies that it returns 'the best manufacturer labels (not repackagers).' These details clarify output selection and ambiguity handling, adding value beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence packs the core action and outputs; the second adds a key behavioral caveat. It is front-loaded with the main purpose and stays tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, an output schema (present), and annotations covering safety and idempotency, the description supplies everything an agent needs: what input types are accepted, the resolution source, the selection rule, and the ambiguity behavior. Return format is covered by the output schema, so no additional explanation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter as 'Drug name or NDC', but the description expands it to 'brand or generic name, misspelling or NDC', clarifying that misspellings and both name types are accepted. This adds meaning beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Resolves') and a precise resource ('a brand or generic name, misspelling or NDC through RxNorm'), and enumerates the outputs (ingredients, brands, FDA classes, manufacturer labels). It clearly differentiates from siblings like search_label and recalls_shortages by focusing on drug identification and resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool — whenever a drug name or NDC needs resolving — but it does not explicitly contrast it with siblings or state when not to use it. There are no direct alternatives mentioned, so usage is inferred rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one topic of the official FDA label as the label's own text under its headings, citing the label's set id, version and date. Says so when the label has no such section.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Drug name, NDC or label setid | |
| setid | No | A specific DailyMed label | |
| topic | Yes |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| label | Yes | |
| topic | Yes | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral detail beyond those flags: it returns the label's own text under its headings, cites set id/version/date, and explicitly says so when the section is absent. This is useful without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the core action and resource, then adding the key behavioral nuance and missing-section handling. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, rich annotations, and enum-based topic parameter, the description covers the essential behavior well. It could add guidance on how to choose between 'drug' and 'setid', but the schema already describes those fields, so the description is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with 'drug' and 'setid' already documented in the schema and 'topic' fully enumerated. The description adds little parameter-level meaning beyond saying 'one topic' and the missing-section behavior, so the schema carries most of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies the exact resource: one topic of the official FDA label, rendered as the label's own text under its headings. It also names the metadata cited (set id, version, date), which makes the tool's function unambiguous and distinguishes it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: fetch a specific labeled section from an FDA label and get the label's own wording. However, it does not explicitly state when to use this tool versus alternatives like search_label or find_drug, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FDA drug recalls (class, reason, status, date, product) and shortage records (status, company, reason) for a drug, newest first, from openFDA.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Drug name or NDC |
| Name | Required | Description |
|---|---|---|
| drug | Yes | |
| recalls_total | Yes | |
| shortages_total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a behavioral detail: results are 'newest first' and sourced from openFDA. It does not discuss rate limits or authentication, but given the annotations cover the read-only nature, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core function and includes the key fields returned and the ordering. No filler or redundant phrasing; it is appropriately sized for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (per context signals), so the description does not need to explain return values. It covers the data source, the type of records (recalls and shortages), the fields, and the ordering. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the parameter 'drug' is described as 'Drug name or NDC'. The description merely repeats that it is 'for a drug' and adds no additional syntax or format details. Since the schema carries the full semantic load, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it retrieves FDA drug recalls (with class, reason, status, date, product) and shortage records (status, company, reason) for a given drug, ordered newest first. It uses a specific verb ('recalls' and 'shortages') and resource (drug), and distinguishes it from sibling tools like find_drug or label_section by specifying the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for a specific drug, and it returns both recalls and shortages. It implies when to use it (when you need recall or shortage information for a drug), but it does not explicitly mention alternatives or when not to use it. This is a minor gap, as the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds every paragraph of the official FDA label that mentions a term (another drug, grapefruit, alcohol, a condition), with its section heading and topic.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Drug name, NDC or label setid | |
| term | Yes | ||
| setid | No |
| Name | Required | Description |
|---|---|---|
| term | Yes | |
| label | Yes | |
| total | Yes | |
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds modest context beyond that—the exhaustive scope ('every paragraph') and the return shape (section heading and topic)—but with an output schema present, some of this is redundant. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of roughly 25 words that is fully front-loaded with the core action and adds helpful parenthetical examples without waste. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and safety annotations, the return values and safety profile are already covered, so the description need not restate them. The main gap is that only one of three parameters is semantically explained and there is no usage routing versus the three siblings, leaving the drug/setid relationship ambiguous for a tool that has multiple identifier options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'drug' is described). The description compensates for the required 'term' parameter by giving concrete examples of what a term can be (another drug, grapefruit, alcohol, a condition), but it does not clarify 'setid' beyond what is referenced in the 'drug' description, leaving that parameter under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Finds every paragraph of the official FDA label') with a well-defined scope (every paragraph mentioning a term) and states the output (section heading and topic). It is implicitly distinct from siblings find_drug and label_section, though it never names them, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the siblings find_drug, label_section, or recalls_shortages. No exclusions, prerequisites, or routing conditions are given; usage is only implied by the tool's nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_druglabel_sectionrecalls_shortagessearch_labelScored across 4 tools
Each tool targets a distinct concern: drug name/NDC resolution (find_drug), retrieving a specific label section (label_section), obtaining recalls/shortages (recalls_shortages), and full-text label searching (search_label). There is no overlap or ambiguity about which tool to use for a given task.
All names use lowercase snake_case and are descriptive, but they mix verb-first (find_drug, search_label) and noun-first (label_section, recalls_shortages) patterns. This is a minor deviation from a strictly consistent verb_noun convention, but the naming remains predictable and readable.
With only 4 tools, the server is tightly scoped to the core needs of FDA drug label information: identification, label access, searching, and safety alerts. This is well within the 3–15 tool range and each tool earns its place without redundancy.
The tool surface covers the essential lifecycle: find a drug, retrieve a section, search across the label, and check recalls/shortages. A minor gap is the lack of a way to list all available sections or retrieve the full label at once, but the existing tools combined can achieve most user needs without failure.
Official FDA recalls, drug labels, adverse events and clinical trials, with cited sources.
Search and export FDA drug labels by brand name, generic ingredient, or UNII code.
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
Search FDA safety data: drug adverse events, recalls, and device events.
