MCP Servers for Healthcare Data

TL;DR

• Most "healthcare MCP servers" don't touch patient data. The official ones mostly serve public reference data (CMS coverage rules, ICD-10, NPI, PubMed) or admin functions. Very few give an agent delegated, per-user access to identified clinical records.
• The auth model is the whole question. Healthcare MCP servers fall into four tiers: no auth (public data), admin plane, shared organization credential, and per-user delegated access. Only the last tier gives you EHR audit attribution and minimum-necessary access per user.
• The MCP spec already says how to do it right. The 2026-07-28 revision requires audience-bound tokens, forbids token passthrough, and routes third-party authorization (like a SMART on FHIR login) through URL elicitation so upstream credentials never touch the MCP client.
• Model BAAs stop at the MCP boundary. Anthropic's BAA says data sent to third parties through MCP connectors isn't covered. Any MCP server that carries PHI needs its own place in your BAA chain, and ideally runs inside your or your customer's boundary.
• Scalekit's view: in healthcare, the MCP server isn't a thin wrapper. It's a credential store and a PHI broker. Treat it with the same controls as the EHR integration itself.

Why healthcare teams are adopting MCP

The Model Context Protocol (MCP) is the standard way AI agents discover and call tools. A client (Claude, ChatGPT, Cursor, your own agent) connects to an MCP server, lists its tools, and calls them.

Healthcare adoption accelerated in 2026:

• Anthropic's Claude for Healthcare (January 2026) shipped connectors for the CMS Coverage Database, ICD-10 and the NPI Registry, plus FHIR and prior-auth skills.
• OpenAI's ChatGPT for Healthcare added an Epic plugin that connects to Epic through per-user SMART on FHIR login.
• Redox, Stedi, Medplum, Aidbox, AWS HealthLake, Keragon and others published MCP servers for their platforms.
• Community directories list around 95 healthcare MCP servers, most of them community-built.

The appeal is obvious: one protocol for every tool the agent needs. The risk is also obvious: in healthcare, a tool call can return PHI.

The four tiers of healthcare MCP servers

Sorting servers by data type isn't enough. Sort them by how they authenticate, because that decides whether they can pass a healthcare security review.

The gap: almost no vendor offers tier 4 as a managed service across many EHR tenants. That's the part teams end up building.

Healthcare MCP server inventory

Official and vendor-published

No official MCP server for third-party agents was found from Epic, Oracle Health, Veradigm, Particle, Metriport or Health Gorilla. Epic's agent work (Art, Emmie, Penny, Agent Factory) is on-platform. "Epic MCP servers" in community lists appear to be third-party wrappers over Epic's FHIR API.

Open source worth knowing

• wso2/fhir-mcp-server: SMART on FHIR authorization-code flow, FHIR CRUD, Epic and HAPI demos. Apache-2.0.
• jmandel/health-record-mcp: from one of SMART's co-creators. Patient-side SMART standalone launch; its MCP OAuth mode is marked experimental.
• Innovaccer HMCP: a proposed healthcare extension to MCP. Early (v0.0.6), with several security features specified but not yet implemented.

What the MCP spec requires, mapped to healthcare

‍

The current MCP revision is 2026-07-28. Its authorization rules line up closely with what healthcare security reviews ask for.

For workforce agents, the enterprise-managed authorization extension lets a health system's identity provider (Entra, Okta) grant clinicians access to approved MCP servers through token exchange. It doesn't replace SMART on FHIR: the EHR remains a separate authorization server, and the MCP server still needs its own delegated EHR token. Scalekit supports enterprise-managed authorization through Cross App Access (XAA).

The spec doesn't set a healthcare scope grammar. SMART does, and it's the one to reuse inside your FHIR tools. We compared the two protocols in MCP security risks in the enterprise.

Is MCP HIPAA compliant? The BAA gap

MCP is a protocol, so it isn't "HIPAA compliant" or not. What matters is whether every system in the data path is covered by your BAA chain and has the right safeguards.

• Anthropic says data sent to third parties through MCP connectors, Enterprise Search, Claude in Chrome and external MCP "isn't covered under Anthropic's BAA."
• OpenAI lists workspace apps and connectors as HIPAA eligible under its BAA, but says "features not listed here are not automatically covered." Neither provider's BAA covers the third-party server itself.
• MCP server vendors put the burden on you. Stedi tells customers to check with security and legal. Keragon says customers govern PHI use across the workflow. Healthie's developer MCP says not to connect it to production.

What it means: the model provider's BAA covers the model. The MCP server that fetches the chart is a separate business associate or subcontractor in your chain. Choose one you can put under a BAA, that doesn't persist payloads, and ideally that runs inside your or your customer's boundary.

Security risks specific to MCP and PHI

There's no publicly reported PHI breach attributed to an MCP server yet. The general MCP incident record shows exactly where one would come from:

• Prompt injection through tool results. A malicious instruction in a patient portal message, a faxed referral or a payer web page steers an agent with EHR access. In healthcare, patient-entered text is attacker-controlled input.
• Tool poisoning. A malicious tool description in one server redirects data from another. Don't co-install unvetted servers alongside PHI-bearing ones.
• Supply chain. Malicious packages impersonating legitimate servers, including a cloned health-data MCP server in 2026 that spread malware. Most healthcare MCP servers are community-built.
• Cross-tenant exposure. A multi-tenant MCP gateway that mixes practices or health systems can leak PHI across customers.
• Credential concentration. A server holding EHR refresh tokens for many users is a high-value target. Stored connection credentials were what was potentially exposed in Composio's May 2026 incident: about 5,001 GitHub connections and 5,241 API keys, per Composio. See our analysis of MCP security risks.

Healthcare governance bodies are catching up. The Health Sector Coordinating Council's third-party AI risk guide (April 2026) calls for supply-chain transparency, and CHAI's agentic AI work group is defining healthcare extensions on top of agent protocols including MCP.

How to run a FHIR MCP server safely

The following architecture keeps PHI within safe boundaries while maintaining full audit attribution:

1. Authenticate the MCP client with OAuth 2.1, audience-bound to your server. Reject everything else.
2. Run a per-user SMART on FHIR login for the EHR through URL elicitation. The clinician authorizes the EHR directly.
3. Keep EHR tokens server-side, encrypted per customer, bound to the issuing health system's FHIR base URL. Never pass the MCP token upstream, and never return the EHR token to the client.
4. Expose scoped tool bundles, not the whole FHIR API. Separate read and write tools, and mark them with tool annotations (read-only, destructive) so clients can gate them.
5. Build the tool list from granted SMART scopes, so agents don't plan around calls that will fail.
6. Bind any handle you return (patient, encounter, task) to the caller, with a short expiry.
7. Process payloads in memory. Don't write FHIR responses to disk, caches or logs.
8. Log metadata only: who authorized, which agent, which tool, which scope, resource reference, status, latency. Stream to the customer's SIEM.
9. Deploy inside the boundary when the customer requires it: their VPC, their infrastructure, or air-gapped. Understanding how the MCP authorization layer works is essential before deploying at scale.

Checklist: evaluating any healthcare MCP server

• Which auth tier is it: none, admin, shared credential, or per-user delegated?
• Does it hold its own upstream tokens, or pass the client's token through?
• Are tokens audience-bound per tenant?
• Where are upstream credentials stored, and who holds the encryption key?
• Are tool payloads written to disk or logs?
• Can you restrict the tool surface per agent and role?
• Are write tools separated and annotated?
• Will the vendor sign a BAA, and which subprocessors does it cover?
• Can it run in your or your customer's cloud?
• Who maintains it, and how are releases signed and vetted?

How Scalekit fits

Scalekit gives healthcare agents the tier-4 model without building it yourself:

• SMART on FHIR as an MCP-ready connector. The generic SMART on FHIR connector discovers any EHR's OAuth configuration from its FHIR base URL, runs per-user authorization, and exposes FHIR tools your agent can call over MCP or the SDK.
• Virtual MCP Servers bundle exactly the tools each agent or role needs across EHR, SaaS and healthcare connectors (500+ connectors and 20K+ actions), with one server definition serving every user.
• Auth for your own MCP servers. If you're publishing an MCP server, Scalekit MCP Auth adds drop-in OAuth 2.1 authorization to it, including Client ID Metadata Documents for client registration, the method the current spec recommends.
• Enterprise-managed authorization through Cross App Access (XAA), so a health system's identity provider can govern which clinicians reach which MCP servers.
• PHI stays out: payloads are processed in memory, credentials are encrypted per customer with bring-your-own-key support, and audit logs carry metadata only.
• Deploys inside the boundary, with a HIPAA BAA on Enterprise, SOC 2 Type II and ISO 27001.

For the auth patterns, see OAuth for AI Agents: Production Architecture and Practical Implementation Guide. For a broader look at how credential ownership works across agent tool-calling patterns, that post covers the tradeoffs in detail.

Frequently asked questions

Is MCP HIPAA compliant?

MCP is a protocol, so compliance depends on how each server in the path is operated. Every MCP server that handles PHI must be covered by your BAA chain and have appropriate safeguards. Model-provider BAAs generally don't cover third-party MCP servers: Anthropic's explicitly excludes data sent through MCP connectors.

Does Epic have an MCP server?

Epic hasn't published an MCP server for third-party agents. Its agents (Art, Emmie, Penny and Agent Factory) run on-platform. Third-party agents reach Epic through its certified FHIR API with SMART on FHIR. OpenAI's Epic plugin uses that route with per-user SMART login. "Epic MCP servers" in community lists appear to be third-party wrappers.

What is a FHIR MCP server?

A FHIR MCP server exposes FHIR API operations (read, search, create, update) as MCP tools so AI agents can work with clinical data. The important design choice is authentication: a well-built FHIR MCP server authorizes each user through SMART on FHIR and holds EHR tokens server-side, rather than using one shared credential.

Can Claude or ChatGPT connect to an EHR?

Yes, through connectors or MCP servers. OpenAI's Epic plugin connects ChatGPT to Epic with per-user SMART on FHIR login under a BAA. Claude can connect through MCP servers, but Anthropic's BAA doesn't cover data sent to third-party MCP servers, so the server itself needs its own BAA coverage.

What's the safest way to give an agent EHR access over MCP?

Use per-user delegated authorization. The MCP server authenticates the client with OAuth 2.1, runs a SMART on FHIR login for each user through URL elicitation, keeps EHR tokens server-side and audience-bound, exposes only scoped tools, processes payloads in memory and logs metadata only.

What changed in the 2026-07-28 MCP spec for healthcare?

It made the protocol stateless, deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, required clients to validate the authorization server's issuer, and added security guidance that state handles must not act as authorization. For healthcare, that last rule means patient or encounter handles returned by tools must be caller-bound and short-lived. Learn more about Client ID Metadata and how MCP clients authenticate without registration.