FHIR MCP Server Vs Traditional FHIR Integration: What Actually Changes for AI Agents

Teams adding AI agents to a healthcare product keep asking me a version of the same question: if we put an MCP server in front of FHIR, do we still need our FHIR integration? Yes. MCP changes how the agent asks for data. It doesn’t change what the EHR requires before it answers.

Two layers that get mixed up

I think the confusion starts because “FHIR MCP server” sounds like a new kind of FHIR integration. It’s a layer on top of one.

FHIR integration is how your software reaches an electronic health record’s (EHR’s) data through FHIR (Fast Healthcare Interoperability Resources), the HL7 standard behind modern health-data APIs. It covers four things. Signing in: SMART on FHIR, the standard way apps launch and sign in to an EHR, and backend services for server-to-server work. The FHIR endpoints and resources each EHR exposes. The vendor’s developer registration. And each hospital’s decision to switch your app on.

MCP, the Model Context Protocol, is “an open-source standard for connecting AI applications to external systems” (MCP documentation, October 2026). It defines how an AI client discovers the tools a server offers and calls them.

A FHIR MCP server sits between the two. The agent talks MCP to the server, and the server talks FHIR to the EHR. If you want to see one built in code, our MCP and FHIR tutorial walks through it, and our primer on MCP for LLM integration covers the protocol itself.

What changes when an agent calls tools instead of endpoints?

Here’s how I’d show the difference: the same job, done both ways, with synthetic data.

Through FHIR directly. To find open appointment slots, your code searches the Schedule resource for the right practitioner and location. Then it searches Slot for free slots in a date range, handles paging and filters the results. Every step uses FHIR search parameters, and each EHR supports them a little differently.

Through an MCP tool. The agent calls find open slots with a practitioner, a location and a date range. The server runs the FHIR searches and returns a short list.

What changes is who works out the FHIR. With raw endpoints, your engineers do it once and test it. With MCP, it depends on how the tools are shaped:

• Resource-level tools expose FHIR more or less as it is: search Patient, read Observation, create Appointment. The agent has to work out the parameters each time, and that’s where models guess. I’d avoid that shape for anything a clinician relies on.
• Task-level tools expose one job each: find open slots, check coverage, book a visit. The FHIR work lives inside the tool, written and tested by your team, and the agent picks the job.

My view: the first agent you put near a real EHR should be read-only and task-level. I’d add writes one approved action at a time, once I’d seen how it behaves.

What traditional integration still does

This is where most of the work stays. And it’s the part that decides whether an agent ever reaches production data. As I see it, a FHIR MCP server inherits every one of these:

• Signing in to each EHR. Each vendor has its own registration and its own sign-in rules. The MCP server has to hold credentials the EHR accepts, through SMART on FHIR or backend services. If SMART is new to you, start with how SMART on FHIR works.
• Vendor registration and hospital approval. The EHR vendor reviews your app, and each health system decides whether to switch it on. An MCP layer doesn’t change either step.
• Write access. The certified FHIR API criterion from ONC, the federal Office of the National Coordinator for Health IT, is read-focused: “These services specifically exclude ‘write’ capabilities” (healthit.gov, updated May 2026). Writes depend on what each vendor offers and approves, so check FHIR read and write by EHR before you design an agent that saves anything.
• Data that isn’t FHIR. Hospitals still send admissions, results and orders as HL7 v2 messages, the older hospital messaging standard. An agent that needs that data needs an HL7 v2 integration behind it.
• Population-scale reads. An agent asking questions across thousands of patients shouldn’t page through FHIR searches. That’s a job for bulk FHIR export, with the agent working on the extracted data.
• Mapping between formats. When data arrives as HL7 v2, X12 (the insurance transaction standard) or a vendor’s own JSON, someone has to map it to the shape your tools return.

I’ll put it bluntly. An MCP server in front of a weak integration gives you the same weak integration, now answering in chat.

What does MCP add to your security picture?

Here’s how I think about MCP security. It adds a new hop between the agent and the EHR, and that hop needs its own controls. The protocol’s security best practices (October 2026) name the ones that matter most for a FHIR server:

• No token passthrough. The guidance says “MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.” A server that forwards whatever token the client sends breaks the audit trail and the EHR’s trust boundary.
• Least-privilege scopes. “Poor scope design increases token compromise impact,” the same page says. A server that asks the EHR for every scope up front turns one leaked token into access to everything.
• Tell agents apart in the audit. This is the one I’d check first. If every agent call reaches the EHR under one identity, nobody can say later which agent read which record. Log each tool call with who made it.
• PHI in prompts and outputs. Tool results, including protected health information (PHI), flow into a model’s context. Decide which fields a tool may return, redact what the model doesn’t need, and know where your model runs. I’d decide on purpose whether AI steps stay in your own cloud account (see HIPAA-compliant integration).

Three architectures, compared

Most teams I talk to end up choosing between three shapes. The first and third look alike until you count the agents. What the protocol buys over your own function wrappers:

• Discovery. Any MCP client can list your tools and what they accept, so you don’t re-wire each agent or assistant by hand.
• One server, many callers. The same tools serve your own agents, AI assistants and developer tools.
• One place for the rules. Sign-in, scopes and audit sit at the server instead of being repeated in every agent.

But with one agent, one model and one product, your own wrappers do the job. MCP earns the extra hop when several callers need the same governed actions.

Where I’d use each:

• Direct calls suit a single, well-defined agent feature, where your team already owns the FHIR code.
• A resource-level server suits exploration on a sandbox, or read-only internal analytics where people check the answers.
• Task-level tools suit agents that patients or clinicians rely on, where every action has to be predictable, permitted and logged.

For AI that works inside clinical workflows, see AI EHR integration, and for the wider picture of agents in care, read about agentic AI in healthcare.

Questions to answer before you choose

These are the questions I’d want answered first.

1. Which EHRs does the agent need, and which sign-in flow does each allow?
2. Is it read-only, or does it need writes the vendor has approved?
3. Which actions may the agent take, and which must a person confirm?
4. Who can see, per call, what each agent read or changed?
5. Where does PHI go during AI steps, and which model runs them?
6. Does the agent need HL7 v2 data or population-scale reads?
7. Who owns the vendor registration and each hospital’s approval?
8. Who maintains the tools when an EHR changes its API?
9. If you adopt an existing FHIR MCP server, does it accept only tokens issued to it, and which write or delete tools does it expose by default?
10. Can you filter what each tool returns, so the model sees only the fields it needs?

If the answers point to task-level tools with tight permissions, the MCP part is the easy part. The integration underneath is the project.

The question I don’t have a settled answer to yet: when two agents need the same action with different permissions, is that one tool with two scopes, or two tools? One tool keeps the logic in one place. Two tools keep each agent’s permissions obvious in the audit.

Where ConnectHealth fits

ConnectHealth is our EHR integration platform, and it takes the task-level route. With ConnectHealth v0.4.0 you can publish any workflow as an MCP tool. AI assistants and agents can then check coverage or book a visit through your governed integrations, protected by your API key, with every call audited. The workflows sit on the integration layer this article describes, and the platform runs in your own cloud account. See how it works on our FHIR MCP server page.

If you’d rather not build it yourselves, Mindbowser engineers build the agent workflows and the integration underneath with you.

Before you put an MCP server in front of your EHR

I’d start from the integration. Settle which EHRs, which sign-in flow, which scopes and which actions each tool may take, and the MCP layer becomes a thin, testable surface on top. MCP itself keeps moving. Its documentation is versioned by date, and the current set is 2026-07-28. Pin the version you build against and re-read the security guidance when it changes.

Next reads

• Build a FHIR MCP server in code, if you want to see the moving parts.
• FHIR read and write by EHR, before you design any write tool.
• AI EHR integration, for AI that works inside clinical workflows.