The MedData MCP Server provides tools to search and retrieve drug and supplement information, check interactions, and monitor API usage.
Search Drugs (search_drugs): Find drugs by brand or generic name (e.g., "aspirin" or "Lipitor"), returning RxCUI identifiers, generic/brand names, and dosage form/strength.
Get Drug Profile (get_drug): Retrieve a full drug profile by RxCUI, including names, dosage forms, NDC codes, and label sections.
Get Drug by NDC (get_drug_by_ndc): Look up a drug profile using its NDC (National Drug Code) package code — useful when you have a code from a label or packaging.
Search Supplements (search_supplements): Search for dietary supplements by name (e.g., "Vitamin D" or "Fish Oil"), returning supplement IDs and summary info.
Get Supplement Fact Sheet (get_supplement): Retrieve a full supplement fact sheet by ID, including ingredients, recommended intake, and NIH reference data.
Check Interactions (check_interactions): Check known interactions across a mixed list of 2–10 drugs and/or supplements using established medical databases (not AI-generated).
Get API Usage (get_usage): View the current billing period's API call usage and plan limits for your API key.
Allows LangChain agents to access MedData tools for drug and supplement lookup and interaction checks, enabling pharmaceutical research and medication safety analysis.
Enables LangGraph agents to use MedData tools for drug and supplement lookup and interaction checks, supporting complex multi-step reasoning about medications.
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., "@MedData MCP Server check interaction between ibuprofen and aspirin"
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.
mcp-name: io.github.anthesiallc/meddata
A Model Context Protocol server that exposes the MedData API as tools, so any MCP client (Claude Desktop, Cursor, ChatGPT connectors, or an agent framework) can look up drug and supplement data and check interactions conversationally.
It's a thin wrapper: each tool maps to one MedData REST endpoint. All the data work happens in the API.
Tool | What it does |
| Search drugs by brand or generic name; returns RxCUI + details |
| Full drug profile by RxCUI |
| Drug profile by NDC package code |
| Search supplements by name; returns supplement IDs |
| Full supplement fact sheet by ID |
| Interactions across a mixed list of 2-10 drugs/supplements |
| Full assessment of a routine: per-pair coverage, sources, timing and food conditions |
| Current billing period usage and plan limit |
check_interactions returns a flat list of interactions. assess_routine
returns the reasoning: what each submitted name resolved to, what was consulted
for every pair, and the document behind each finding. Reach for it when the
answer will be explained or acted on rather than just displayed.
The distinction that matters most is in pairs_checked[].status:
status | means |
| one or more grounded findings, listed in |
| a source covering this kind of pair was consulted and had nothing. Absence of a finding is not evidence of safety |
| no source covers this kind of pair, so it was not assessed. Most supplement-supplement pairs land here |
| an item did not resolve, so nothing could be checked |
not_covered and no_finding_in_sources are different answers, and a flat
empty list cannot tell them apart.
assess_routine also takes class_matching (default off). With it on, a drug
matches the therapeutic classes a supplement record names, not only the drug
names it lists; those findings carry basis.level: "class" and name the class,
so an inferred match stays distinguishable from an explicit one. Findings also carry basis.level
(formulation / ingredient / class) saying how closely the source matches
what was submitted, three-state timing and food conditions where silence is
not_documented rather than "no effect", and references[] with the document
version and the verbatim passage.
Related MCP server: openfda-mcp-server
Free tier is 250 calls/month, no credit card:
curl -X POST https://meddata.anthesia.io/api/v1/signup \
-H 'Content-Type: application/json' \
-d '{"email":"you@example.com"}'The key comes back in the api_key field of the response.
The easiest way is with uv (no manual venv needed):
# stdio transport (default — for Claude Desktop, Cursor, most local clients)
MEDDATA_API_KEY=md_your_key uvx meddata-mcp
# streamable-HTTP transport (for remote / web clients)
MEDDATA_API_KEY=md_your_key uvx meddata-mcp --httpOr install with pip into its own environment:
pip install meddata-mcp
MEDDATA_API_KEY=md_your_key meddata-mcpNote: install into a dedicated environment. The
mcpSDK requires a newerstarlettethan the MedData API app pins, so the two will conflict if installed together.
Environment variables:
MEDDATA_API_KEY (required) — your MedData API key.
MEDDATA_BASE_URL (optional) — defaults to https://meddata.anthesia.io.
MEDDATA_TIMEOUT (optional) — request timeout in seconds, default 30.
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"meddata": {
"command": "uvx",
"args": ["meddata-mcp"],
"env": { "MEDDATA_API_KEY": "md_your_key" }
}
}
}Add the same block to ~/.cursor/mcp.json (or the project .cursor/mcp.json).
The server is hosted on Smithery, so MCP clients that support Smithery can connect without installing anything. You provide your MedData API key in the Smithery config and it routes to the server.
Any LangChain or LangGraph agent can use these tools through
langchain-mcp-adapters:
# pip install langchain-mcp-adapters langgraph "langchain[anthropic]"
from langchain_mcp_adapters.client import MultiServerMCPClient
client = MultiServerMCPClient(
{
"meddata": {
"transport": "stdio",
"command": "uvx",
"args": ["meddata-mcp"],
"env": {"MEDDATA_API_KEY": "md_your_key"},
}
}
)
tools = await client.get_tools()
# hand `tools` to a LangGraph/LangChain agent, e.g.
# from langgraph.prebuilt import create_react_agent
# agent = create_react_agent("anthropic:claude-opus-4-8", tools)LlamaIndex works the same way via its MCP tool spec.
git clone https://github.com/anthesiallc/meddata-mcp && cd meddata-mcp
python -m venv .venv
.venv/Scripts/python -m pip install -e ".[http]" # Windows; [http] adds uvicorn for --http
# .venv/bin/pip install -e ".[http]" # macOS/Linux
MEDDATA_API_KEY=md_your_key .venv/Scripts/python -m meddata_mcp.serverData is for informational purposes only and is not medical advice.
Interaction data comes from established medical databases; an empty result means none were found in those sources, not that a combination is proven safe.
Check interactions across a mixed list of drugs and supplements.
Accepts 2-10 items (drug names, supplement names, or both) and returns known interactions among them. Interaction data comes from established medical databases; it is never generated or inferred, so an empty result means none were found in those sources, not that the combination is proven safe.
Args: items: 2-10 drug and/or supplement names, e.g. ["warfarin", "aspirin", "Fish Oil"].
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that interaction data comes from established databases and is never generated or inferred, which is critical for understanding reliability. It does not cover potential side effects like rate limits, but those are less relevant here.
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 concise with two paragraphs, no filler. The first sentence states the purpose, followed by clear constraints and interpretation. Every sentence serves a purpose.
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 tool's complexity (interaction checking with 2-10 items, medical data source), the description covers input constraints, data source, and result interpretation. An output schema exists (though not shown), which likely covers return values, so the description is complete for agent decision-making.
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 description adds substantial meaning beyond the bare input schema: it specifies the accepted count (2-10), types (drug names, supplement names, or both), and provides an example. Schema coverage is 0%, so this compensation is essential and well-executed.
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: 'Check interactions across a mixed list of drugs and supplements.' It specifies the verb (check) and resource (interactions), and distinguishes from sibling tools like get_drug and search_drugs which handle individual lookups.
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 explains the input range (2-10 items) and the implication of an empty result (not found in databases, not proven safe). It does not explicitly state when to avoid using this tool or suggest alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full profile for a drug by its RxCUI.
Returns names, dosage forms, NDC codes, label sections, and related data. Get the RxCUI from search_drugs first if you only have a name.
Args: rxcui: RxNorm Concept Unique Identifier, e.g. "1191" for aspirin.
| Name | Required | Description | Default |
|---|---|---|---|
| rxcui | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description lists return content (names, dosage forms, NDC codes, label sections). Adequately discloses output without contradicting any 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?
Four sentences with no extraneous content; purpose, returns, usage guidance, and parameter details are front-loaded and concise.
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 tool simplicity (one param, output schema exists), description covers purpose, input semantics, and procedure to obtain RxCUI. No gaps for this use case.
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 coverage is 0%, but description fully explains the 'rxcui' parameter with definition and example, adding significant semantic value beyond the schema.
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 it gets the full profile for a drug by its RxCUI. It distinguishes from siblings like search_drugs (for name search) and get_drug_by_ndc (by NDC).
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?
Explicitly advises to use search_drugs first if only a name is available, providing clear context. Does not explicitly exclude other siblings but the narrow scope makes it appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a drug profile by its NDC (National Drug Code) package code.
Use when you have an NDC from a label or packaging rather than a name.
Args: ndc_code: NDC code, e.g. "0363-0160".
| Name | Required | Description | Default |
|---|---|---|---|
| ndc_code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get a drug profile' without disclosing any behavioral traits such as read-only nature, authorization requirements, rate limits, or what the output includes. The existence of an output schema might cover return values, but the description itself lacks transparency.
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 concise and front-loaded with purpose. The 'Args' section is a bit repetitive but acceptable. Every sentence serves a purpose, though the 'Args' section could be integrated more elegantly.
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 tool's simplicity (one parameter) and presence of an output schema, the description is adequate. It explains when to use and what the parameter is. However, it could enhance completeness by briefly describing what a 'drug profile' contains (e.g., name, dosage, manufacturer) to set expectations.
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 description adds value beyond the input schema by providing an example NDC format ('0363-0160'). However, it does not explain constraints like required format (e.g., digits, hyphen) or any restrictions. With 0% schema description coverage, the description partially compensates but is minimal.
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 action 'Get a drug profile' and the resource 'by its NDC (National Drug Code) package code'. It distinguishes from sibling tools by specifying the input type (NDC vs. name).
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 explicitly advises 'Use when you have an NDC from a label or packaging rather than a name', providing clear context for when to use. It does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full fact sheet for a supplement by its ID.
Returns ingredients, recommended intake, and NIH reference data. Get the ID from search_supplements first.
Args: supplement_id: Numeric supplement ID from search_supplements.
| Name | Required | Description | Default |
|---|---|---|---|
| supplement_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes return content but does not explicitly state it is a read-only operation or discuss any behavioral traits like idempotency. Adequate but could be more transparent.
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?
Very concise: states purpose, returns, parameter doc. No unnecessary words. Front-loaded with the action.
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 low complexity (1 param, no nested objects) and presence of output schema, the description covers all needed context: purpose, input source, and what the output contains.
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 0%, but the description adds crucial meaning: 'supplement_id: Numeric supplement ID from search_supplements.' This compensates fully, specifying type and source.
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?
Clearly states 'Get the full fact sheet for a supplement by its ID.' Verb and resource are specific, and it distinguishes from siblings like search_supplements or get_drug.
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?
Explicitly instructs to get ID from search_supplements first, providing clear prerequisite context. Does not explicitly mention when not to use, but the guidance is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this API key's current billing period usage and plan limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'show' (a read operation) but omits details like auth requirements, rate limits, or whether it resets data. Basic disclosure is missing.
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, clear sentence with no wasted words. However, it lacks additional context that could be added without sacrificing brevity.
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?
For a zero-parameter tool with an output schema, the description is minimally complete. It identifies the resource (API key usage) but could clarify scope (current billing period) and response format. No significant gaps given simplicity.
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 tool has zero parameters, so the description does not need to add parameter semantics. Baseline 4 is appropriate as the schema fully covers the empty parameter list.
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 shows billing period usage and plan limits for the API key, distinguishing it from sibling tools that focus on stores, apps, or adoption.
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?
No guidance on when to use this tool over alternatives. It does not exclude any contexts or mention prerequisites, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for drugs by brand or generic name.
Returns matching drugs with their RxCUI (the identifier you pass to get_drug), generic and brand names, and dosage form/strength when known. Use this first when you have a drug name but need its details or RxCUI.
Args: name: Brand or generic drug name, e.g. "aspirin" or "Lipitor". limit: Max results to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool returns matching drugs with identifiers and names. It does not explicitly state read-only behavior, but it is implied by 'search' and the return description. Lacks mention of edge cases like empty results.
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?
Very concise: three short sentences for purpose and return, then usage guidance, then parameter descriptions. Every sentence adds value, no fluff.
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?
With an output schema present, the description does not need to detail return format, but it does mention key fields. It covers input parameters well. Missing error handling or pagination details, but adequate for a search tool.
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 coverage is 0%, but the description includes an 'Args' section that explains the 'name' parameter with examples and 'limit' with range. This adds substantial meaning beyond the schema, though it could be slightly more detailed (e.g., format of name).
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 action ('Search for drugs by brand or generic name') and what it returns (RxCUI, names, dosage). It distinguishes itself from siblings like get_drug and search_supplements by positioning itself as the first step when you have a drug name.
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?
Explicitly advises to use this tool first when you have a drug name but need details or RxCUI, implying that get_drug is the next step. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for dietary supplements by name.
Returns matching supplements with their IDs (pass to get_supplement) and summary info. Use first when you have a supplement name like "Vitamin D" or "Fish Oil".
Args: name: Supplement name, e.g. "Vitamin D" or "magnesium". limit: Max results to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses it's a search operation returning IDs and summary info. Lacks details on search behavior like case sensitivity or fuzzy matching, but adequate for a simple search.
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?
Very concise: two sentences for purpose, then clearly formatted Args. Every sentence adds value, no fluff.
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 it has an output schema, description doesn't need to detail return fields. It mentions returning IDs and summary info, which is sufficient. Covers all parameters and usage context.
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 0%, so description compensates fully. Explains name with examples and limit with range. Adds meaning beyond the schema.
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 it searches for dietary supplements by name and returns IDs and summary info. It mentions passing ID to get_supplement, which differentiates it from search_drugs, though not explicitly.
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?
Explicitly says to use first when you have a supplement name like 'Vitamin D', providing clear context. Does not explicitly state when not to use, but implies one should search for supplements not drugs.
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.1check_interactionsget_drugget_drug_by_ndcget_supplementget_usagesearch_drugssearch_supplementsScored across 7 tools
Each tool has a clearly distinct purpose: check_interactions for interactions, get_drug and get_drug_by_ndc for drug profiles by different identifiers, get_supplement for supplement profiles, search tools for lookup, and get_usage for billing. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., search_drugs, get_drug_by_ndc, check_interactions). The naming style is uniform and predictable.
With 7 tools, the server is well-scoped for its purpose of drug and supplement information retrieval and interaction checking. Each tool earns its place without overcomplicating the surface.
The tool set covers search and retrieval for both drugs and supplements, plus interaction checking. A minor gap is the lack of a direct way to check interactions involving a single drug or supplement against a broader set, but the core workflows are supported.
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
DrugBank MCP — wraps the DrugBank Clinical API (api.drugbank.com)
Food-drug interaction and nutrient depletion checks for 30+ common medications.
Link compounds to protein targets, rank bioactivity, and look up drug mechanisms and indications.