MCPmed: MCP-Enabled Systems for Medicine
- MCPmed is an emerging paradigm that adapts Model Context Protocols for medicine, enabling stateful, tool-mediated, and auditable clinical and bioinformatics workflows.
- MCPmed architectures decouple natural-language reasoning from external data actions, using modular systems like MCP-AI, EHR-MCP, and CARIS for secure clinical oversight.
- Research in MCPmed demonstrates improved biomedical tool integration and standardized terminology mapping, enhancing data retrieval, decision-making, and research orchestration.
Searching arXiv for papers on “MCPmed” and closely related MCP-in-medicine work. MCPmed denotes an emerging MCP-for-medicine paradigm: the adaptation of the Model Context Protocol (MCP) to biomedical research, clinical informatics, and healthcare AI workflows. In the current literature, the term is most explicitly introduced as a community framework for MCP-enabled bioinformatics web services, but closely related work uses adjacent labels—such as “MCP-AI,” “EHR-MCP,” “MedMCP-Calc,” and “BioinfoMCP”—to describe domain-specialized MCP systems for clinical reasoning, EHR retrieval, medical calculators, and biomedical tool integration (Flotho et al., 10 Jul 2025). The literature does not define a single, universally adopted standard named “MCPmed.” Instead, it presents a family resemblance: MCP becomes a machine-actionable interface or protocol layer through which LLMs and agentic systems can discover tools, preserve context, invoke external resources, and operate within auditable, domain-constrained medical or biomedical workflows (ElSayed et al., 5 Dec 2025).
1. Terminological scope and conceptual definition
The most literal use of “MCPmed” appears in “MCPmed: A Call for MCP-Enabled Bioinformatics Web Services for LLM-Driven Discovery,” where it is proposed as a community effort, implementation hub, and migration strategy for making bioinformatics web services natively usable by LLMs and autonomous research agents (Flotho et al., 10 Jul 2025). In that formulation, MCPmed is not a replacement for existing databases, APIs, FAIR principles, or GA4GH standards; it is a practical bioinformatics-specific adaptation of MCP that adds a machine-actionable semantic layer over existing web-service backends.
A broader medical interpretation is supported by “MCP-AI: Protocol-Driven Intelligence Framework for Autonomous Reasoning in Healthcare,” which does not define a separate standard called MCPmed but explicitly proposes a healthcare-specific instantiation of MCP (ElSayed et al., 5 Dec 2025). In that work, MCP is described as a structured, version-controlled file-based interface or structured, version-controlled file format that captures task context, execution logic, model orchestration, and decision metadata. MCP-AI then specializes that protocol object into a persistent, auditable clinical reasoning artifact that stores patient state, clinical objectives, diagnostic hypotheses, execution procedures, fallback scenarios, confidence annotations, and reasoning history.
This suggests that “MCPmed” is best understood as an umbrella designation for MCP-based medical and biomedical systems rather than as a finalized protocol specification. A plausible implication is that the literature currently treats MCPmed as a design space: MCP as clinical cognitive middleware, MCP as medical terminology-grounding infrastructure, MCP as privacy-preserving research orchestration, and MCP as an interoperability layer for biomedical tools (Ahn et al., 4 Sep 2025).
2. Architectural pattern: MCP as memory, orchestration, and interface layer
Across the literature, MCPmed systems share a common architectural idea: the separation of natural-language reasoning from external action through structured protocol-mediated access to tools, data sources, and workflow state. In “MCP-AI,” this is made explicit as a five-layer modular system consisting of an Input and Perception Layer, an MCP Engine, AI Reasoning Modules, Task and Procedure Agents, and a Verification Module and Physician Interface (ElSayed et al., 5 Dec 2025). The workflow is temporal and stateful rather than one-shot: data are ingested, normalized into a versioned MCP file, processed by generative and descriptive modules, reviewed by physicians, and then converted into validated downstream tasks.
Other systems instantiate the same pattern more narrowly. “EHR-MCP” uses custom MCP tools integrated with a hospital EHR-derived data warehouse, so that a LangGraph ReAct agent can retrieve clinically relevant information through deterministic hospital-approved functions rather than arbitrary SQL (Masayoshi et al., 19 Sep 2025). “CARIS,” presented as a coding-free and privacy-preserving clinical research intelligence system, uses MCP servers as a secure tool gateway through which an LLM orchestrates database metadata lookup, SQL execution, PubMed search, IRB drafting, machine-learning analysis, and document generation while databases remain behind the tool interface (Kim et al., 14 Apr 2026). “MedMCP-Calc” applies the same principle to realistic medical calculator scenarios by exposing a PostgreSQL Executor server, a Google Search server, and a Python Executor server through MCP, thereby forcing models to combine database retrieval, external reference lookup, and exact computation in a clinically plausible workflow (Zhu et al., 30 Jan 2026).
The bioinformatics literature generalizes this interface-layer view. “BioinfoMCP” describes an MCP-enablement platform that converts heterogeneous bioinformatics tools into MCP-compliant servers so that AI agents can call them reliably, while “Experiences with Model Context Protocol Servers for Science and High Performance Computing” argues for thin MCP servers over mature services such as Globus Transfer, Compute, Search, Octopus, Garden, and Galaxy (Widjaja et al., 2 Oct 2025). Although these papers are not healthcare-specific in the clinical sense, they reinforce the same architectural doctrine: MCP should make services discoverable, invokable, and composable without replacing mature backend systems (Pan et al., 25 Aug 2025).
3. Major functional domains within MCPmed
The present literature supports at least four distinct MCPmed subdomains.
First, there is clinical reasoning and care coordination. MCP-AI presents explainable medical decision-making built upon MCP, with longitudinal state, physician-in-the-loop validation, Handoff Agents, and explicit support for adaptive, longitudinal, and collaborative reasoning across care settings (ElSayed et al., 5 Dec 2025).
Second, there is clinical information retrieval and EHR mediation. EHR-MCP demonstrates that an LLM connected to an EHR database via MCP can retrieve clinically relevant information in a real hospital setting, with deterministic tools such as patient_basic_info, lab_results, bacteria_results, antibiotics_treatment, and calculate_cockcroft_gault (Masayoshi et al., 19 Sep 2025). The contribution is infrastructural: MCP becomes the hospital-approved access layer between the model and the data warehouse.
Third, there is medical informatics standardization and terminology grounding. “An Agentic Model Context Protocol Framework for Medical Concept Standardization” uses MCP resources and an Athena querying tool to map messy source terms to OMOP standard concepts through a two-step reasoning process and tool-calling under the guidance of contextual resources provided by MCP (Ahn et al., 4 Sep 2025). In that design, the model is not allowed to invent concept IDs and must use the tool to look them up, making MCP a hallucination-preventive control layer.
Fourth, there is clinical research orchestration and biomedical tool integration. CARIS uses MCP to automate research planning, literature search, cohort construction, IRB documentation, Vibe Machine Learning, and report generation without direct raw-data access (Kim et al., 14 Apr 2026). BioinfoMCP and MCPmed in the bioinformatics sense extend this logic outward to sequence analysis tools, web servers, and scientific workflows, aiming at natural-language-driven orchestration of complex biomedical software (Widjaja et al., 2 Oct 2025).
| Domain | Representative system | Primary role of MCP |
|---|---|---|
| Clinical reasoning | MCP-AI | Persistent clinical context and workflow control |
| EHR retrieval | EHR-MCP | Deterministic hospital-approved tool access |
| Terminology mapping | OMOP mapping framework | Grounded lookup and structured reasoning |
| Research orchestration | CARIS / BioinfoMCP | Tool chaining across data, literature, ML, and reporting |
4. Representation, workflow, and statefulness
A defining feature of MCPmed systems is statefulness. MCP-AI repeatedly characterizes the MCP file as both executable workflow specification and audit trail, and as a reusable and auditable memory object (ElSayed et al., 5 Dec 2025). The stored elements include patient information or context, clinical goals, diagnostic hypotheses, module orchestration logic, execution procedures, fallback scenarios, reasoning history, task progress, confidence annotations or scores, explanatory notes, uncertainty flags, and provenance regarding which module contributed which step. Memory is longitudinal: the MCP object persists over time, survives across care episodes, and carries reasoning continuity across provider transitions.
This same stateful tendency appears in more operational systems, though sometimes in narrower form. In EHR-MCP, the structured output and execution logs preserve prompt, tool call, arguments, tool output, and final answer, making failure analysis possible at the level of exact tool interactions (Masayoshi et al., 19 Sep 2025). In MedMCP-Calc, the benchmark treats task execution as a partially observable sequential process with planning actions and tool actions, and evaluates not only task fulfillment but also calculator selection, evidence acquisition, and quantitative precision (Zhu et al., 30 Jan 2026). In CARIS, the orchestration prompt instructs the agent to document everything, save intermediate CSVs, and keep a clear audit trail while moving from hypothesis formulation to final report (Kim et al., 14 Apr 2026).
By contrast, prompt-only systems are repeatedly described in the literature as stateless functions. MCPmed systems are intended to replace isolated prompts with persistent protocol context that outlives any single model invocation (ElSayed et al., 5 Dec 2025). This suggests that state persistence is not an implementation detail but one of the central conceptual commitments of MCPmed.
5. Safety, governance, privacy, and physician oversight
Safety-oriented design is among the most consistent themes across MCPmed-related work. In MCP-AI, safety is layered: generative output is checked by descriptive validators and then by the physician before execution, and no action is confirmed before the system records reasoning steps, assigns confidence scores, and allows physician verification (ElSayed et al., 5 Dec 2025). The clinician is therefore the authorizing entity for task execution, while the AI performs recommendation generation, validation, logging, and downstream task preparation.
Several papers extend this into privacy and compliance engineering. “Agentic-AI Healthcare” places a dedicated Privacy & Compliance Layer around MCP agents, with RBAC, AES-GCM field-level encryption, tamper-evident audit logging, and consent mediation, while explicitly framing the system as a research prototype rather than a certified medical device (Shehab, 25 Sep 2025). CARIS emphasizes that databases remain securely within the MCP server and users access only outputs and final research reports, which lowers barriers while preserving data privacy (Kim et al., 14 Apr 2026). “Secure Multi-Modal Data Fusion in Federated Digital Health Systems via MCP” places MCP around federated multimodal pipelines and combines multi-modal feature alignment, secure aggregation with differential privacy, and energy-aware scheduling (Aueawatthanaphisut, 2 Oct 2025).
At the same time, the literature repeatedly warns that MCP itself does not solve security. “We Urgently Need Privilege Management in MCP” reports that network and system resource APIs dominate usage patterns across 2,562 real-world MCP applications, and argues that MCP urgently needs privilege management because plugins can inherit broad system privileges with minimal isolation or oversight (Li et al., 5 Jul 2025). “A Measurement Study of Model Context Protocol” similarly finds that more than half of listed projects are invalid or low-value, that servers face structural risks including dependency monocultures and uneven maintenance, and that clients remain in a transitional phase in protocol and connection patterns (Guo et al., 29 Sep 2025). For MCPmed, these findings imply that healthcare deployment cannot rely on protocol branding alone; it requires provenance checks, maintenance thresholds, transport hardening, and explicit privilege boundaries.
6. Evidence base, limitations, and open problems
The MCPmed literature is stronger on architecture and systems design than on rigorous clinical validation. MCP-AI provides no formal experimental evaluation, benchmark, quantitative study, ablation, statistical comparison, or prospective trial result; its two use cases are design demonstrations or narrative simulations rather than validation studies (ElSayed et al., 5 Dec 2025). Agentic-AI Healthcare likewise provides no benchmark datasets, accuracy metrics, user studies, or ablations, and is best understood as a feasibility prototype (Shehab, 25 Sep 2025). EHR-MCP is more empirically grounded, but remains a single-center retrospective study with eight patients and six tasks, showing near-perfect performance for simple retrieval tasks while highlighting difficulty in complex time-dependent calculations (Masayoshi et al., 19 Sep 2025).
The strongest quantitative results come from narrower or infrastructural tasks. The OMOP standardization system reports 100% retrieval success with MCP versus 0% without MCP on a 48-term medication evaluation, and 100% retrieval success on 150 curated medical terms with mean relevance score 1.61 versus 1.39 for human experts in shared-retrieval cases (Ahn et al., 4 Sep 2025). CARIS reports final-report completeness of 96% in LLM evaluation and 82% in human evaluation using a TRIPOD+AI-derived checklist (Kim et al., 14 Apr 2026). MedMCP-Calc provides the most benchmark-like agentic evaluation, showing that even top performers such as Claude Opus 4.5 remain weak on realistic calculator workflows, particularly in calculator selection, SQL-based evidence acquisition, and tool-mediated quantitative precision (Zhu et al., 30 Jan 2026). BioinfoMCP reports that 94.7% of 38 MCP-converted bioinformatics tools were validated successfully at the tool level across three AI-agent platforms (Widjaja et al., 2 Oct 2025).
Several open problems recur. Formal specification is often absent: MCP-AI provides no machine-readable schema, canonical fields, serialization example, or state-transition formalism (ElSayed et al., 5 Dec 2025). Real-world interoperability remains under-specified: many papers mention HL7/FHIR, APIs, or hospital systems, but operational details such as identity and access management, consent handling, quality documentation, failover design, and medico-legal accountability are rarely fully defined (ElSayed et al., 5 Dec 2025). Tool-use behavior is also an unresolved weakness: MedMCP-Calc shows marked reluctance by current LLMs to leverage external tools for numerical computation and poor performance in iterative SQL-based database interactions (Zhu et al., 30 Jan 2026). A plausible implication is that the central challenge for MCPmed is no longer whether tools can be attached to models, but whether models can reliably choose, sequence, constrain, and justify those tool calls under real medical conditions.
7. Historical position and likely trajectory
The present literature positions MCPmed as an early-stage but increasingly diversified field. In bioinformatics, MCPmed is framed as a call for community transition, lightweight breadcrumbs for legacy services, packaging templates, and eventually a curated MCP app store (Flotho et al., 10 Jul 2025). In healthcare AI, MCP-AI functions as an architectural manifesto for using a persistent protocol artifact to unify memory, orchestration, explainability, and human oversight (ElSayed et al., 5 Dec 2025). In medical informatics and research operations, specialized systems such as OMOP mapping, CARIS, EHR-MCP, and MedMCP-Calc show how MCP can constrain hallucination, mediate EHR access, automate research workflows, and benchmark realistic clinical tool use (Ahn et al., 4 Sep 2025).
This suggests that MCPmed is developing along two complementary trajectories. One is domain-wide infrastructure: community standards, converters, registries, and semantically annotated services for biomedical tools and data sources (Flotho et al., 10 Jul 2025). The other is workflow-specialized systems: narrowly scoped but concrete MCP applications for EHR retrieval, terminology grounding, research intelligence, calculator use, and longitudinal reasoning (Masayoshi et al., 19 Sep 2025). The literature’s strongest shared claim is conceptual rather than settled: medical AI may be better organized around persistent, inspectable, tool-mediated protocol objects than around isolated prompts or opaque end-to-end generations.
The weakest point remains validation. The literature repeatedly presents clinically plausible architectures and promising subsystem results, but often without prospective studies, formal schemas, or deployment-grade governance. Accordingly, MCPmed is best characterized not as a finalized standard or mature product category, but as an emerging research and engineering program for making medical and biomedical AI systems modular, stateful, tool-grounded, and auditable across heterogeneous environments (ElSayed et al., 5 Dec 2025).