MCP — Model Context Protocol — gives a model client structured access to tools and data sources. For healthcare operations, the capability is enormous and the risk surface is real. Picking the right starter set is a governance decision as much as a tooling decision.
The pattern that goes wrong: a team turns on every MCP server they can find in week one, hands the model a wide-open toolbox, and discovers in week three that an automation drafted an email containing PHI to the wrong address. The pattern that works: a deliberately small starter set with hard scopes, expanded only when the controls catch up to the capability.
Here is the starter set I default to for a first 30 days of healthcare ops automation, plus what I deliberately leave off until later.
The safe starter set
1. Web search (Tavily, Exa, or equivalent)
Read-only, no PHI exposure, gives the model fresh external information. This is the lowest-risk capability you can grant and it expands the model's competence noticeably for ops work: pulling vendor pricing, looking up regulatory updates, finding precedent for a coverage decision.
The configuration that matters: the search tool returns text only, not URLs that the model can navigate to. Browsing capability is a separate decision with a higher risk profile, and most ops use cases do not need it.
2. Shared drive or document store, read-only
Scoped to specific folders. Operations playbooks, templates, internal documentation, training material. No patient files, no clinical notes, no anything with PHI.
The scoping is where this either works cleanly or fails. The MCP server should be configured to expose only the specific folder IDs the workflow needs, not the whole drive. The principle of minimum necessary applies to documents the way it applies to data fields — the model should have access to what it needs to do the task, not to everything that exists.
3. Email, drafts only
The model can compose. Only humans send. The "drafts only" constraint is enforced server-side, not in the prompt. Prompt-level constraints are advisory; server-level constraints are load-bearing.
This is the capability that produces the highest visible value in the first 30 days. Drafting member communication, drafting clinician outreach, drafting vendor follow-ups. Human review stays in the loop because the workflow is structured around it, not because the model was told to be careful.
4. A custom internal-data MCP
The one server you build, rather than install. Scoped to the specific operational data the workflow needs: schedule data, claims status, member roster, whatever the operations team is currently looking up by hand. The scope is hard-coded, the queries are parameterized, and every call is logged.
This is the highest-leverage capability in the starter set because it is custom-fit to your workflow. It also has the highest engineering cost. Plan for a week of build per data domain, including the hard scoping and the audit logging.
What I leave off the starter set
General-purpose database access
Too easy to over-scope. Even with a read-only role, a model with SQL access can pull data shapes that violate minimum-necessary. Build the custom internal-data MCP instead — it is more work but the result is auditable.
EHR access via MCP
Possible. Not in the first 30 days. EHR access is its own engagement with its own safety story: BAA review with the EHR vendor, scope definition that maps to clinical roles, audit logging that meets the EHR vendor's standards. See the EHR field guide for what that integration looks like when it is ready to happen.
Slack with full read and write
Too much organizational context, too easy to expose. A narrower Slack capability — post to a specific channel, drafts only, read a specific channel — can be a fit. Full read and write should wait.
Anything that takes irreversible action
No "send the email" power. No "approve the claim" power. No "schedule the appointment" power without a human gate. The model is good at composing, summarizing, and proposing. It is not yet good at being trusted with one-way doors in a regulated workflow.
How to think about scope expansion
Once the starter set is running and the team has watched it for two to four weeks, the question becomes "what to add next." The rule I use:
A new capability is ready to add when the audit log for the existing capabilities is being reviewed regularly and no one would be surprised by what is in it.
If the log review is not happening, more capability is not the answer. The problem is observability, not scope.
The expansion order I usually recommend, in priority:
- A second internal-data MCP for a different operational domain. Same pattern, new scope.
- EHR read with a narrow, named set of fields. Months 2–3 typically.
- Calendar write for appointment scheduling, with a human-in-the-loop confirmation step.
- Slack write for a specific channel.
- Browsing for tasks that require it, with rate limiting and content filtering.
The audit log is the load-bearing part
Every MCP server in the starter set has to write to an audit log that the operations team and the compliance team can review. The log records the call, the parameters, the response, the user context, and the human action taken on whatever the model produced.
For a first 30-day deployment, a structured log going to your existing SIEM or to a dedicated table is fine. What matters is that the log exists, is queryable, and is reviewed.
The audit log is also what makes the SOC 2 and HIPAA story work for MCP-based automation. See SOC 2 and AI governance for how the log feeds into the Trust Services Criteria controls, and HIPAA-compliant AI automation for the auditor's view of the same log.
A common failure mode worth naming
I have seen teams spin up MCP servers in a "playground" environment, get to a useful demo, and then deploy the same configuration to production with the audit logging and scoping added later. The result is a working system that no one can defend in an audit.
Reverse the order. Build the audit logging and scoping first. Wire one capability through it. Demo from that. Expand from there. The result is slower to first demo and faster to production.
If your team is in the first 30 days of a healthcare ops AI engagement and the MCP picture is fuzzy, book a call. The starter set above is a reasonable default for most use cases; the customization is in the internal-data MCP and the scope of the workflows you want to automate first. Both of those decisions move faster with someone who has watched a few of these go right and a few go wrong.