Model Context Protocol

Model Context Protocol for Connecting AI Tools to Health Data

The Model Context Protocol is an interoperability standard whose specification fixes the messages that pass between an AI application, such as a chat assistant built on a language model, and the servers that give it data and functions. Each data source or function is wrapped once in an MCP server, and any application that implements the protocol can then use it. For health economists this is the layer through which an assistant might query a de-identified electronic health record database, look up a unit cost or read the terms of an ontology while building a model. The protocol governs how a request is framed and who must approve it, and says nothing about whether the answer that comes back is correct.

Hosts, clients and servers

The specification describes a client-host-server architecture built on JSON-RPC 2.0 messages. The host is the language model application that starts connections, a client is a connector inside the host, and a server is a service that provides context and capabilities. Each client talks to exactly one server, so a host connected to three servers runs three clients.

The designers say the protocol takes some inspiration from the Language Server Protocol, which standardised how programming languages are supported across development tools. Anthropic released the protocol as open source on 25 November 2024. One design principle matters for health data. Servers should not be able to read the whole conversation or see into other servers, the full conversation history stays with the host, and the host enforces the security boundaries between servers. A server holding hospital episode data is therefore meant to receive only the information its task needs, not the rest of the analyst's session.

Servers can be local processes on the analyst's computer or remote services. In the MedCP application in health research, the server ran on the user's machine inside the health system network, so protected health information was not transferred outside the institution.

Resources, prompts and tools

A server offers its content as three kinds of primitive, which differ in who decides when each is used. The specification calls prompts user-controlled, resources application-controlled and tools model-controlled.

Resources are data that give the model context, such as files or database schemas, and each is identified by a URI. A server over a SKOS concept scheme such as the HealthEconomics.wiki ontology HEO could, for example, offer each concept as a resource under its own URI. Prompts are templated messages that a user selects, typically as a command in the interface.

Tools are functions the model can call. Each tool has a unique name, a description and an input schema written in JSON Schema, and may also declare an output schema, in which case the server must return structured results that conform to it. A client finds the tools with a list request and runs one with a call request.

Clients can offer features back to servers. Elicitation lets a server ask the user for more information in the middle of a task. The 2026-07-28 revision deprecated two other client features, sampling and roots, and suggests that new implementations pass files through tool parameters instead and call language model provider interfaces directly.

Messages, transports and versions

Every message follows JSON-RPC 2.0. A request carries an identifier and a method name, and the reply carries either a result with the same identifier or an error with an integer code. Two standard transports carry the messages. Under stdio the client launches the server as a subprocess and they exchange newline-delimited messages over its standard input and output, while under Streamable HTTP each message is an HTTP POST to a single endpoint.

Version identifiers take the form of a date, which marks the last time a backwards incompatible change was made. The current revision is 2026-07-28, which removed the opening handshake and protocol-level sessions, so every request now carries its own protocol version and client capabilities. Servers must implement a discovery call that reports the versions and capabilities they support, and revisions up to 2025-11-25, which open with that handshake, are now called legacy. A server built in 2025 and a host built in 2026 can therefore disagree, and the specification defines how a server rejects a request in a version it does not support.

Worked example with an illustrative unit cost server

All numbers and names in this example are hypothetical and illustrative. Suppose a team has three AI applications and four data sources, namely a trial database, an electronic health record extract, a unit cost schedule and an ontology.

Step 1. Without a shared protocol, each application needs its own connector to each source.

$$C_{\text{bespoke}} = m \times n = 3 \times 4 = 12$$

where $C_{\text{bespoke}}$ is the number of separate connectors, $m$ is the number of applications and $n$ is the number of data sources. With the protocol, each application implements a client once and each source is wrapped in a server once.

$$C_{\text{MCP}} = m + n = 3 + 4 = 7$$

where $C_{\text{MCP}}$ is the number of implementations, and $m$ and $n$ are as before. Adding a fifth source adds one server, not three connectors.

Step 2. The unit cost server lists a tool named get_unit_cost, whose input schema requires a service code and a price year. Asked for the cost of three outpatient attendances, the model calls the tool, and the server returns a structured result giving GBP 150 per attendance in the requested price year. The analyst's cost is then

$$C = q \times p = 3 \times 150 = 450$$

where $C$ is the total cost in GBP, $q$ is the number of attendances and $p$ is the unit cost per attendance in GBP. The multiplication is ordinary arithmetic and can be checked by hand. The unit cost is only as good as the schedule behind the server, and the price year must match the model's.

Step 3. Suppose the model asks for a price year that the schedule does not hold. The specification separates two kinds of error. A tool execution error comes back as a normal result marked as an error, with text the model can use to correct its request and try again, while a call to a tool that does not exist returns a protocol error. Clients should pass the first kind to the model so that it can correct the request, and may pass the second.

Step 4. The specification's own example of a tool list carries a freshness hint of 300000 milliseconds.

$$t = \frac{300000}{1000 \times 60} = 5$$

where $t$ is the time in minutes for which a client may reuse the cached list. A tool added to the server within that window may not yet be visible to the model unless the server sends a list-changed notification, which matters when servers change during a project.

Consent, security and audit

The specification states that the protocol cannot enforce its security principles itself, and leaves them to implementers. Its principles are that users must consent to and understand all data access and operations, that hosts must obtain consent before exposing user data to servers, and that hosts must obtain consent before invoking any tool. Tools represent arbitrary code execution, and descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server.

Duties fall on both sides. Servers must validate tool inputs, apply access controls, rate limit calls and sanitise outputs. Clients should ask for confirmation of sensitive operations, show tool inputs to the user before calling the server, validate results before passing them to the model and log tool use for audit. The project's security guidance adds that a local server from an untrusted source, run without proper sandboxing or consent checks, can let an attacker execute any command with the client's privileges.

These duties map onto existing data governance for patient-level data. In MedCP, the server worked only on records already processed by de-identification, read-only access was enforced at three layers, and only de-identified or aggregate results were returned to the model. The protocol supplied the channel, and the server's own checks and the institution's systems supplied the controls.

Published uses in health research

Bellucci and colleagues built MedCP, an MCP server that gave one agent read-only access to an OMOP-standardised electronic health record database at an academic medical centre and to SPOKE, a curated biomedical knowledge graph. On 100 benchmark clinical research tasks, access to the knowledge graph improved mean scores overall for both language models tested, though the pattern differed between them. Every query appeared as an explicit SQL or Cypher statement that experts could re-run and check, which the authors call procedural auditability. Lower-scoring benchmark runs showed temporal misalignment, denominator errors and misclassification of exposure or outcome, all familiar from cohort studies.

In the same paper the team applied a standard protocol to replicate published observational studies, a form of real-world evidence generation. The authors list as limits a single site, results specific to the models used and the data quality of the underlying records.

In a perspective for bioinformaticians, Sheffield describes MCP as a standard way for AI to plug into tools and databases, and notes servers already covering PubMed, UniProt and ClinicalTrials.gov. He also notes that the protocol is evolving rapidly, with a 2026 revision that made its core stateless and deprecated sampling shortly after it was introduced.

MCP beside retrieval and health data standards

MCP and retrieval-augmented generation both bring outside information into a language model's context, and Bellucci and colleagues argue they differ less in accuracy than in scope. Retrieval systems search a text collection through embeddings and a vector store, whereas an MCP tool can run a native query with exact filters, aggregations and time windows against a structured database. Retrieval-augmented generation, AI agents and large language models are treated as separate concepts.

MCP is also distinct from the standards that give health data a shared meaning, which are covered under digital interoperability. FHIR standardises the exchange of individual patient records between clinical systems, and OMOP harmonises records for population analysis, while MCP sits a layer above and lets an AI application reach either. Regulation and evidence standards for AI in general are covered under artificial intelligence in health.

Limits and common misreadings

Most misreadings treat a connection as if it were a guarantee of quality. Four recur.

1. A connected answer is a correct answer. MCP fixes the message format, not the reasoning, and in the MedCP benchmark, lower-scoring runs still showed denominator and timing errors, which expert graders identified.
2. The protocol keeps data safe. The specification says it cannot enforce its own security principles, so consent, access control and logging depend on the host, the server and the institution's governance rules.
3. Tool descriptions can be trusted. A server describes its own tools, and the specification treats those descriptions as untrusted unless the server is trusted.
4. A server built once keeps working. The 2026-07-28 revision removed the handshake that earlier revisions required and deprecated sampling, which had been part of the protocol since its first revision in 2024, so the protocol version belongs in the methods of any analysis that relied on it.

Sources

• Anthropic. Introducing the Model Context Protocol. Published 25 November 2024. https://www.anthropic.com/news/model-context-protocol
• Bellucci G, Gu W, Rose PW, Baranzini SE. An agentic AI framework connecting language models to electronic health records and a biomedical knowledge graph for real-world evidence. Frontiers in Artificial Intelligence. 2026;9:1883853. https://doi.org/10.3389/frai.2026.1883853
• Model Context Protocol. Specification, revision 2026-07-28 (overview, architecture, base protocol, versioning, transports, server features, client features, key changes). https://modelcontextprotocol.io/specification/2026-07-28
• Model Context Protocol. Versioning. Current revision 2026-07-28, accessed 2 November 2026. https://modelcontextprotocol.io/specification/versioning
• Model Context Protocol. Security best practices. Accessed 2 November 2026. https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
• Sheffield NC. Model Context Protocol: the unexpected catalyst of a bioinformatics interoperability revolution. PLOS Computational Biology. 2026;22(8):e1014543. https://doi.org/10.1371/journal.pcbi.1014543