Skip to main content
Glama
anthesiallc

MedData MCP Server

by anthesiallc
README.md
# MedData MCP Server

mcp-name: io.github.anthesiallc/meddata

A [Model Context Protocol](https://modelcontextprotocol.io) server that exposes the
[MedData API](https://meddata.anthesia.io) 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.

## Tools

| Tool | What it does |
|------|--------------|
| `search_drugs` | Search drugs by brand or generic name; returns RxCUI + details |
| `get_drug` | Full drug profile by RxCUI |
| `get_drug_by_ndc` | Drug profile by NDC package code |
| `search_supplements` | Search supplements by name; returns supplement IDs |
| `get_supplement` | Full supplement fact sheet by ID |
| `check_interactions` | Interactions across a mixed list of 2-10 drugs/supplements |
| `assess_routine` | Full assessment of a routine: per-pair coverage, sources, timing and food conditions |
| `get_usage` | Current billing period usage and plan limit |

### check_interactions vs assess_routine

`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 |
|--------|-------|
| `finding` | one or more grounded findings, listed in `findings[]` |
| `no_finding_in_sources` | a source covering this kind of pair was consulted and had nothing. Absence of a finding is not evidence of safety |
| `not_covered` | **no** source covers this kind of pair, so it was not assessed. Most supplement-supplement pairs land here |
| `unresolved` | 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.

## Get an API key

Free tier is 250 calls/month, no credit card:

```bash
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.

## Install and run

The easiest way is with [uv](https://docs.astral.sh/uv/) (no manual venv needed):

```bash
# 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 --http
```

Or install with pip into its own environment:

```bash
pip install meddata-mcp
MEDDATA_API_KEY=md_your_key meddata-mcp
```

> Note: install into a dedicated environment. The `mcp` SDK requires a newer
> `starlette` than 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`.

## Client configuration

### Claude Desktop

Add to `claude_desktop_config.json` (Settings → Developer → Edit Config):

```json
{
  "mcpServers": {
    "meddata": {
      "command": "uvx",
      "args": ["meddata-mcp"],
      "env": { "MEDDATA_API_KEY": "md_your_key" }
    }
  }
}
```

### Cursor

Add the same block to `~/.cursor/mcp.json` (or the project `.cursor/mcp.json`).

### Smithery (hosted, no install)

The server is hosted on [Smithery](https://smithery.ai/server/anthesiallc/meddata),
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.

### LangChain / LangGraph

Any LangChain or LangGraph agent can use these tools through
[`langchain-mcp-adapters`](https://github.com/langchain-ai/langchain-mcp-adapters):

```python
# 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.

## Develop from source

```bash
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.server
```

## Notes

- Data 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.

TDQS

A4.2/5.0

Scored across 7 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues