Healthcare MCP Servers Compared: What's Actually Production-Ready in 2026
There is no Epic, Oracle Health, or Particle Health MCP server yet. Here is what actually exists, and why the protocol alone will not make any of it compliant.
If you searched for this, you're probably trying to connect a large language model to your EHR, your FHIR API, or your claims data, and you want to know what's actually available before you build something yourself or hand a vendor your data. We ran that search for you. Here is what exists, what doesn't, and what the gap between them tells you about governance.
The short answer
There is no Epic MCP server. No Oracle Health or Cerner MCP server. No Health Gorilla, Particle Health, Metriport, Zus Health, Commure, or 1upHealth MCP server. If you've been searching for one of those names plus "MCP," the honest answer is that it doesn't exist yet, publicly, as of this writing.
What does exist: one EHR vendor pilot (athenahealth), one interoperability platform with a beta MCP server scoped to integration configuration rather than patient data (Redox), one vendor-authored healthcare-specific extension to the protocol (Innovaccer's HMCP), a handful of narrow-scope production tools built around specific workflows like prior authorization and e-prescribing, and a long tail of open-source FHIR connectors with real code and zero compliance attestations.
That's not a knock on the technology. Model Context Protocol is fifteen months old. It's exactly as mature as you'd expect a fifteen-month-old integration standard to be in a domain that took EHR vendors a decade to get FHIR right in. The point of this article is to save you the hour of searching we already did, and to flag the thing most comparisons won't tell you: MCP itself doesn't solve governance. It solves plumbing.
What "MCP server" means here
Model Context Protocol is Anthropic's open standard for connecting an LLM application (Claude Desktop, Claude Code, or any MCP-compatible client) to external tools and data sources. An MCP server exposes a defined set of tools and resources; the model calls them the way it would call any function. In healthcare, that means a tool like "search patient records" or "get medication list" that an AI assistant can invoke on your behalf.
The protocol says nothing about who's allowed to call those tools, what gets logged when they do, or how PHI is classified once it's in the model's context. That part is built by whoever stands up the server. Keep that distinction in mind as you read the comparison below, because it's the difference between "this vendor has an MCP server" and "this vendor has a governed MCP server."
Comparison: vendor and platform MCP servers
| Server | Connects to | Capabilities | Compliance claims | Status |
|---|---|---|---|---|
| athenahealth MCP pilot | athenaOne, athenaPatient, 500+ partner network APIs | Patient history summarization, eligibility checks, lab analysis, contextual insights | Company language on preserving data privacy and existing privacy standards; no independent SOC 2, HITRUST, or BAA claim specific to the MCP layer | Pilot, announced 2025, still described as piloting as of March 2026 |
| Redox MCP server | Redox integration platform (routing, mapping, monitoring) | Configure and troubleshoot integrations, detect schema drift, natural-language search over integration metrics. Not clinical record access. | Redox as a company holds HITRUST and SOC 2; no MCP-specific compliance statement found | Beta, opt-in, rolling out to select customers |
| Innovaccer HMCP | FHIR APIs, patient data stores, EMPI, third-party agents | OAuth2/OpenID aligned with SMART on FHIR, data segregation and encryption, audit trails, rate limiting, agent registration | Marketing language claims HIPAA-compliant access management; no independent SOC 2, HITRUST, or BAA attestation found for HMCP itself | [object Object] |
| AWS HealthLake MCP Server | AWS HealthLake managed FHIR datastore | Full FHIR resource CRUD, advanced search, import/export job management, optional read-only mode | HealthLake itself is a HIPAA-eligible AWS service; the MCP connector makes no independent compliance claim | Open source, AWS Labs maintained, active |
| EasyPA MCP server | FHIR R4 EHR data plus 3,000+ payer eligibility sources | Patient lookup, eligibility verification, prior-authorization status, denial intake, appeal generation | SOC 2 Type II certified, HIPAA-aligned, BAA available on request, states no PHI used for AI training, Vanta continuous monitoring | In production, scoped narrowly to prior authorization |
| Chia Health MCP server | Telehealth prescription intake and consent workflows | Intake, consent capture, provider review routing, checkout | Claims a HIPAA-compliant audit trail with 10-year retention; licensed providers make prescribing decisions, AI is an intermediary | Production, scoped narrowly to prescription commerce |
Two things jump out. First, the two strongest documented compliance postures we found, EasyPA and Chia Health, both work by scoping down to one narrow, revenue-cycle-adjacent workflow rather than broad chart access. Second, the platforms with the widest reach into clinical data (Innovaccer's spec, the community FHIR connectors below) are also the ones making the least formal compliance claims.
Comparison: open-source and community FHIR connectors
These connect to generic FHIR R4 servers, sandboxes, or self-hosted platforms like Medplum and HAPI FHIR. None of them carry a formal compliance certification. Treat them as prototyping tools, not vendor products.
| Server | Maintainer | Capabilities | Maturity signal |
|---|---|---|---|
| WSO2 FHIR MCP Server | WSO2 | Full FHIR CRUD, capability discovery, FHIRPath response filtering, SMART-on-FHIR OAuth2 | Apache 2.0, 128 GitHub stars, versioned releases |
| the-momentum/fhir-mcp-server | The Momentum | Full CRUD across core FHIR resources, document ingestion with vector search, LOINC lookups | MIT, 93 stars, 17 forks, active releases |
| health-record-mcp | Josh Mandel (SMART on FHIR co-architect) | Read-only query and search over a patient record via SMART App Launch | MIT, 81 stars, hosted demo; no compliance disclaimer in the repo despite the author's pedigree |
| AgentCare / langcare-mcp-fhir | Kartha-AI | Vitals, labs, medications via SMART on FHIR against Epic and Cerner sandboxes | Small, largely unmaintained; original repo relocated |
| xSoVx/fhir-mcp | Independent | Claims built-in PHI protection and audit logging | Unverified, 0 GitHub stars at time of research |
Worth naming separately: some projects that show up in "healthcare MCP server" searches don't touch patient data at all. Cicatriiz/healthcare-mcp-public wraps FDA, PubMed, and ClinicalTrials.gov lookups. openpharma-org/medicare-mcp wraps public, aggregate CMS spending data. Both are useful reference-data tools, neither is an EHR connector, and neither belongs in the same conversation as anything that touches a patient chart.
What we searched for and could not verify
- Epic: no official MCP server, no announced plans. Search results will surface an unrelated Unreal Engine "Epic Games" MCP plugin; different company, worth disambiguating for yourself if you land on it.
- Oracle Health / Cerner: no clinical-data MCP server. Oracle publishes generic MCP servers for its database products, unrelated to Oracle Health's clinical systems.
- Health Gorilla, Particle Health, Metriport, Zus Health, Commure, 1upHealth: no MCP server or announcement found for any of them.
- CMS Blue Button 2.0, the official authenticated Medicare beneficiary claims API: no official MCP server exists. The only related open-source project covers public aggregate data, a much lower-stakes data class than authenticated beneficiary claims.
- Anthropic's own official MCP server directory contains zero healthcare entries.
If you've heard a rumor about one of these, verify the source directly before you plan around it. This space moves fast enough that any of this could change within a quarter, and vendor pilots have a way of turning into press releases before they turn into GA products.
Why MCP alone doesn't solve compliance
This is the part a comparison table can't show you, and it's the reason this article exists on a governance site instead of a dev-tools blog.
The MCP specification states plainly that authorization is optional, and that implementations using a local stdio transport, which is how most desktop MCP servers run today, should not use the OAuth flow at all. Credentials come from the local environment instead. For the most common deployment pattern right now, that means there is no protocol-level access control. Whatever the local process can reach, the model can reach.
OAuth support was added to the spec later, not designed in from the start, and plenty of early tutorial-based MCP servers still run on shared bearer tokens distributed across a whole team. Shared credentials break the thing a healthcare compliance program actually needs: a per-user audit trail of who accessed what.
MCP defines tools, resources, and prompts. It does not define an audit log, a consent model, or a minimum-necessary-access rule. Every compliance control you saw in the tables above, EasyPA's SOC 2 attestation, Chia Health's audit trail, Innovaccer's access management layer, was built by the implementer on top of the protocol, not inherited from it. Independent security research has already documented real failure modes specific to this gap: tool descriptions that smuggle instructions into a model's context (sometimes called tool poisoning), authentication misconfigurations found in live remote MCP servers, and caller-identity confusion in multi-agent setups, which is exactly the kind of ambiguity a HIPAA audit will not tolerate. Anthropic is building enterprise-managed authorization on top of the base spec to close some of this, but it's new, and it's not yet the default for most deployments.
None of this means MCP is unsafe to use. It means MCP is a data-access protocol, and treating it as a compliance framework is a category error. The plumbing is standardized. The governance is still entirely on you and whichever vendor sits between the model and your patients' data.
What this means for your health system
If you're evaluating how to connect generative AI to clinical or administrative data, three questions matter more than which MCP server you pick:
Do you know what's already connected? Most health systems have unsanctioned AI tools in use before anyone formally evaluates an MCP server. Understanding what's already happening, including what's already been pasted into a consumer AI tool, comes before adding a new integration path.
Who's accountable for the audit trail? If the MCP server you're evaluating runs on shared credentials or a stdio transport with no protocol-level auth, ask directly who logs access, at what granularity, and where that log lives. If the answer is "the model's context window," that's not an audit trail.
Does a BAA actually cover the model provider, not just the connector? A compliance claim on the MCP server itself is not the same as a BAA that extends through the LLM provider it's calling. Verify both links in that chain before you connect anything to PHI, including the SOC 2 and HIPAA controls any platform in that chain should be able to show you.
This is the same governance-first approach behind our 6-week engagement: understand what's actually happening with AI in your organization, align people, process, and technology around it, then enable a path forward on a governed, multi-model AI platform built for regulated data, whether or not that path runs through MCP. If you want a clear picture of what's already connected in your organization before you add one more integration, the SAFE AI Adoption Assessment is a free place to start.
FAQ
Does Epic have an MCP server?
No. As of this writing, Epic has not published or announced an official MCP server for its EHR. Generative AI features Epic has discussed publicly, such as its Cosmos and CoMET work, are not confirmed to route through MCP.
Is there a HIPAA-compliant MCP server?
A small number of narrow-scope MCP servers make explicit HIPAA and SOC 2 claims, notably EasyPA (prior authorization) and Chia Health (prescription workflows). No broad, general-purpose EHR or FHIR MCP server we found carries an independent HIPAA or SOC 2 attestation. A compliance claim on the connector itself is different from a BAA that covers the model provider behind it.
Is MCP secure enough for healthcare data?
The protocol itself makes authorization optional and does not define audit logging or consent. Security researchers have documented real risks specific to MCP, including tool poisoning and misconfigured authentication on live remote servers. MCP can be deployed securely, but the access control, logging, and PHI handling have to be built by the implementer. Nothing about compliance comes from the protocol by default.
What's the difference between Redox's MCP server and an EHR MCP server?
Redox's MCP server, currently in beta, is scoped to Redox's own integration configuration layer, routing, mapping, and monitoring, not to reading or writing patient records directly. It's easy to see "Redox has an MCP server" and assume that means patient-data access through Redox via MCP. As of this research, it doesn't.