The Agent-Tool Problem Healthcare Never Solved
Healthcare AI agents are stuck. Not because the models are bad — they're shockingly capable. The problem is plumbing. Every agent prototype I see in health systems follows the same pattern: a capable LLM wired to a bespoke spaghetti of API calls, each hand-coded, each with its own auth flow, each one a PHI leak waiting to happen.
Model Context Protocol just landed in the enterprise conversation with real momentum this week. Dock Labs shipped an MCP server for digital identity with least-privilege agent access. eZintegrations is converting no-code integration flows into MCP servers callable by any agent. The pattern is unmistakable: MCP is becoming the universal tool-access layer for AI agents.
Healthcare needs to pay attention. Now.
What MCP Actually Is (And Isn't)
MCP is a protocol — a standardized contract between an AI agent and external tools. Instead of every agent implementation hand-rolling its own function-calling integration with your EHR, your claims engine, your lab system, MCP defines a uniform interface: here are the tools available, here are their schemas, here's how to call them.
It's not an API gateway. It's not middleware in the traditional sense. It's a discovery and invocation layer that sits between the LLM and your existing APIs, making your services callable by any MCP-compatible agent without custom integration code.
The architecture: Agent → MCP Client → MCP Server → your existing FHIR API / Snowflake query / dbt job / clinical workflow.
If you've been building healthcare AI agents, you've already built half of this — badly. Every custom tool definition you wrote for your LangChain or CrewAI agent is a proprietary, non-portable version of what MCP standardizes.
Why Healthcare Data Engineers Should Care
1. Tool sprawl is killing agent reliability. The average health system AI pilot touches 4–7 backend systems. Each integration is a one-off. When your agent needs to query patient labs, check formulary status, and pull prior auth requirements, that's three different auth models, three different error handling patterns, three different data contracts. MCP collapses this into a single protocol with consistent tool discovery and invocation.
2. PHI scoping becomes architecturally enforceable. This is the big one. Dock Labs' framing is exactly right: "tightly scoped identity functions supporting least-privilege access." In healthcare, this isn't optional — it's regulatory. An MCP server can expose a get_patient_labs tool that accepts a patient ID and returns only the labs the requesting context is authorized to see. The PHI boundary isn't in the prompt engineering — it's in the server definition. Your data team controls what the agent can touch, not the prompt.
3. Your Snowflake and dbt assets become agent-callable. This is where it gets interesting for data engineers specifically. Imagine wrapping a dbt model — say, your mart_readmission_risk — as an MCP tool. An agent can discover it, understand its schema, call it with parameters, and get structured results. Your analytics layer becomes an agent's toolkit. No custom connectors. No middleware team bottleneck.
The PHI Trap Nobody's Talking About
Here's where the industry is about to make a catastrophic mistake.
MCP servers are designed to be reusable across agents. That's the point — build once, use everywhere. But in healthcare, "everywhere" means crossing consent boundaries, department boundaries, covered entity boundaries.
A generic MCP server that exposes query_patient_data is a compliance violation waiting to happen. The server must encode:
- Role-based access tied to the agent's operating context, not just the user's session
- Minimum necessary data filtering at the tool level — not the prompt level
- Audit logging that captures which agent, which user context, which patient, which data elements were returned
- Consent verification before any data leaves the server boundary
If you ship MCP servers for healthcare AI agents without these constraints baked into the server implementation, you've built a HIPAA breach factory with a nice protocol on top.
The Architecture You Should Be Building
Here's the stack that actually works:
- MCP servers per data domain: clinical, claims, operational, genomic. Each server owned by the team that owns the data. Domain ownership prevents scope creep.
- FHIR-native where possible: Your clinical MCP server should be a thin layer over your FHIR API, not a parallel access path that bypasses existing authorization.
- Snowflake Cortex as compute backend: For analytical tools, let the MCP server dispatch to Cortex functions. The data never leaves Snowflake's governance perimeter. Access History gives you the audit trail for free.
- dbt contracts as tool schemas: Your dbt model contracts already define the shape of your data. Use them to auto-generate MCP tool definitions. The mapping is almost 1:1 — column names, types, descriptions all carry over.
- Centralized audit through your existing data platform: Every MCP tool invocation should land in your audit tables alongside your existing access logs. One lineage graph, not two.
Own This Layer or Lose It
MCP will become the default integration pattern for enterprise AI agents within 18 months. The healthcare organizations that build PHI-aware MCP servers now — with proper scoping, audit, and governance — will have a massive head start when agent-driven workflows move from pilot to production.
The ones that bolt MCP onto existing APIs without rethinking access control will be the next wave of breach headlines.
Data engineers: this is your layer to own. Not the AI team's. Not the app team's. The tool-access layer for agents is a data infrastructure problem — it's about controlling what data flows where, under what authority, with what audit trail. That's your job description. Treat it like one.