Every explanation of MCP hits the term "MCP server", and that is where many readers stall. This article treats it on its own.
For MCP overall see What Is MCP?; for the EMR application see Using MCP with an EMR.
Disclaimer: General information. Specifications evolve; consult the current official specification when implementing.
An MCP Server Is Not a Machine
An MCP server is not a box in a rack.
It is a software component that exposes counters usable by AI over some data or system. It may run on a laptop, an on-premise server, or in the cloud. "Server" names the role—the side that offers the counter.
A reception desk is the closest analogy. Business systems sit behind it, but visitors (the AI) only see the procedures listed at the counter. Anything not on the list cannot be requested.
The Three Things an MCP Server Offers
| Kind | Meaning | Medical example |
|---|---|---|
| Tools | Operations the AI can execute | Patient lookup, retrieve lab values, check open slots, fetch a document template |
| Resources | Data the AI can read | Internal manuals, billing rule tables, public-funding masters, case documents |
| Prompts | Reusable instruction templates | "Build an initial-visit summary", "draft a referral letter" |
Tools matter most in practice: what you list there is the ceiling on what the AI can do.
Each tool carries a description the AI can read—"takes a patient ID, returns recent lab values." The AI reads these and decides which to use. That is the decisive break from conventional APIs: no developer has to script the procedure.
See What Is an API? and MCP vs. API vs. FHIR.
Who Builds One
① The EMR vendor. An official counter over their own data. Most realistic for providers, with a clear division of responsibility—operation, updates, and security sit with the vendor.
② SaaS and external service providers. Booking systems, web questionnaires, payment services. Expect this category to grow around the chart.
③ In-house IT or a contracted integrator. Where an API exists but no MCP server, a translation layer is built. Realistic for mid-to-large hospitals, but whoever builds it owns maintenance.
④ Public bodies and industry groups. For high-public-value data such as fee schedules and drug information, shared counters may emerge—adjacent to the direction of the national medical information platform.
At clinic scale it is effectively ① and ②. You almost never need to build one. The practical involvement is making "does this vendor provide one?" part of your selection criteria.
What a Provider Might Expose, by Risk
| Counter | Kind | Impact | Reasonable initial setting |
|---|---|---|---|
| Search internal manuals and policies | Read | Low | Open early |
| Reference billing rules, public-funding masters | Read | Low | Open early |
| Check open booking slots | Read | Low | Open early |
| Reference a patient's labs and prescriptions | Read | Medium | Open within the user's rights |
| Reference chart notes and findings | Read | Medium–High | Scope-limited; audit logs mandatory |
| Draft documents (referrals, certificates) | Write (draft) | Medium | Human commit mandatory |
| Create or change a booking | Write | Medium | Allow behind a confirmation step |
| Committed writes to the chart | Write | High | Keep closed for now |
| Issuing prescriptions or orders | Write | High | Keep closed |
The principle: open reads first, stop writes at drafts, and let humans commit.
Designing Scope—Least Privilege at Counter Granularity
Coarse counters are dangerous. One big "fetch chart data" counter tends to mean access to the whole chart even when only lab values were needed.
Split them finely. "Get recent labs", "get allergies", "get prescription history" lets you grant per purpose—and audit logs then record specifically what was seen.
Never let AI exceed a human's rights. This is decisive in medicine. AI acting on a receptionist's instruction must not read what that receptionist cannot see on screen. That is a broken permission model. See Permission Design and Security Checks for MCP in Healthcare.
On-Premise or Cloud
On-premise. Inside the same network as the EMR. More stays internal and the exits are easier to narrow—at the cost of owning maintenance and incident response.
Cloud. Lighter operational burden, but you must design by what route internal data reaches it.
With an AI-native design the question shrinks: AI and chart share a foundation, so paths that carry internal data outward are minimal, and MCP is used only to pull external specialist information. See What Is an AI-Native EMR?, Cloud vs. On-Premise EMR, and Cloud Security for Healthcare Providers.
Should You Build Your Own?
Probably not, if: the vendor offers one (or plans to); you lack staff to maintain it; or the data includes patient information.
Worth considering if: you limit it to non-patient internal documents (manuals, policies, procedures); you are a mid-to-large hospital with an IT department that can maintain it; or an API already exists and only a translation layer is needed.
The commonly missed factor is maintenance liability. When the EMR is upgraded, when the integration breaks, when a vulnerability is found—the builder responds. Whether you can carry that is the deciding question.
What to Verify
- What counters (tools) exist? May we see the list?
- Can each counter be enabled or disabled by us?
- Are read-only counters separated from write-capable ones?
- Is the AI constrained to the logged-in user's rights?
- Are counter invocations written to audit logs?
- Where does the MCP server run (on-premise / vendor environment / third-party cloud)?
- If it fails, does clinical work on the EMR continue?
Conclusion
- An MCP server is not a machine—it is the component exposing counters to AI
- It offers tools, resources, and prompts
- Each tool carries an AI-readable description, letting the AI choose—the decisive break from conventional APIs
- Builders are mainly EMR vendors and external service providers; clinics rarely need to build one
- Scope principle: reads first, writes stop at drafts, humans commit
- Finer counters make least privilege achievable and audit logs specific
- AI must never exceed a human's rights—decisive in healthcare
- If you build one, maintenance liability is the deciding factor
For details on AI Karte or to request a demo, please contact us.