Michael Rowe

Model Context Protocol

note6 min read

Universal connector, not universal solution

MCP solves a real problem: every AI application used to need its own custom integration with every data source. It replaces those with one standard interface. Standardisation isn’t transformation, though: a cleaner connection isn’t automatically a pedagogically sound, ethically robust, or strategically wise one.

Model Context Protocol

One-sentence definition: The Model Context Protocol (MCP) is an open standard that lets any compliant AI application connect to any compliant data source or tool through the same interface.

Before MCP, connecting an AI assistant to your files meant building an integration for that assistant and that source. Querying a database took another one, and moving to a different assistant meant starting again. MCP replaces these point-to-point connections with a single protocol, much as USB replaced a drawer of proprietary cables. Anthropic released it as an open standard in November 2024, and it’s since been taken up by AI applications from several other companies.

How it works

The protocol names three roles. The host is the AI application you work in: a chat assistant, Claude Code, or a code editor. Inside the host, a client holds the connection to each server, a small program that makes one source or service available: a folder of notes, a reference library, a calendar. The host decides which servers to connect to and asks for your permission; the client and server exchange messages in a standard format1. Because every server speaks the same protocol, you can swap the source, add a new one, or change the assistant without rebuilding anything.

A server can offer three kinds of thing: tools the model can call, resources it can read, and prompts, ready-made instructions for common tasks. What that looks like in practice, and why the list of tools sets a firmer limit on the AI than any instruction, is the subject of the MCP server note. Traffic in the other direction is limited: the one feature a client offers servers is elicitation, which lets a server ask you, through the host, for information it needs to finish a task.

Messages travel between client and server in one of two standard ways. With stdio2, the host starts the server as a program on your own computer and they exchange messages directly. With Streamable HTTP3, the server runs as a web service, which lets it live elsewhere and be shared by a team or an institution. Earlier versions of the specification used a different web transport, and older guides still describe it.

A specification that moves

MCP has been revised often since its launch, and each revision is published as a dated version of the specification; this note follows the version dated 28 July 2026. Earlier versions let servers ask the model to generate text for them (a feature called sampling), and that is gone from the current core. Articles written a year ago describe a protocol that differs in several details, so it’s worth checking the date on anything you read about it, including this note.

Switching on a supplier’s server

Most educators will meet MCP as a governance question. Suppose the company behind the e-portfolio a diagnostic radiography programme uses for placement records announces an MCP server. Once it’s switched on, any compliant assistant a student or practice educator uses can reach those records, within whatever the server allows. The questions a programme team needs answered first are which tools the server offers, whether any of them write or delete, and whose model receives the data they return. The protocol makes the connection possible and leaves those decisions to whoever switches it on.

Used with that care, MCP supports context sovereignty. You keep your material in your own systems and let a model reach the part a task needs, for as long as the task takes, and nothing has to be uploaded to an AI provider in advance. Deciding which part that is, and when the model gets it, is the work of context engineering, and MCP is one of the main ways of doing it. It separates where the intelligence lives from where your data lives, which is the arrangement intelligence as a service depends on.

What the protocol can’t guarantee

The protocol’s own specification says hosts must get your explicit consent before calling a tool or exposing your data, and then concedes that it can’t enforce this. Protection depends on the application’s design and on whether you read the approval prompt before clicking through it. Consent also does nothing about content: whatever a server returns reaches the model as text it may treat as instructions, which is how prompt injection gets in.

Standardisation has costs of its own. Early design decisions become hard to change once widely adopted, and a protocol shaped around one set of assumptions about how AI and data interact may not suit uses nobody has thought of yet. The frequent revisions are partly the protocol’s designers finding that out as people use it.

None of this makes MCP good or bad in itself. What matters is whether the connections it makes easy get used to support human-centred goals, or only to make existing problematic patterns run more smoothly.

Sources

Footnotes

  1. JSON-RPC: a simple, widely used format for one program to ask another to do something and get a reply, written as structured text. MCP uses it so that every client and server phrases requests the same way. Wikipedia ↩

  2. stdio (standard input and output): the channels every program on a computer has for receiving text and sending it back, the same ones you use when typing into a terminal. Using them means the server needs no network connection at all. Wikipedia ↩

  3. HTTP: the set of rules web browsers and web servers use to exchange pages and data; it’s the “http” at the start of a web address. A transport built on it lets an AI application reach a server anywhere on the internet, the same way a browser reaches your institution’s virtual learning environment. Wikipedia ↩

Continue reading

  • MCP server

    An MCP server is a small program that connects an AI assistant to one data source or service, such as a reference library, a folder of notes, or a calendar, through the Model Context Protocol. What the server offers sets the limit of what the assistant can see and do there.

  • Context sovereignty

    What is context sovereignty? The idea that people should own and author the context they bring to AI (their values, commitments, and ways of making sense of things) so that AI adapts to their thinking. How it differs from data sovereignty and model memory, its three principles, and what it means for students and educators.

  • Contextual interoperability

    Contextual interoperability is what lets you use your own notes, frameworks, and commitments with any AI model, local or hosted. It has two halves: the context has to be legible, with relationships a model can follow, and portable, held by you instead of inside one provider's system. With a curriculum mapping example from a pharmacy programme.