Model Context Protocol (MCP)
The open standard that lets an AI application connect to external data and tools over JSON-RPC, and what its three roles and three server features actually do.
Karl-Gustav Kallasmaa, Founder & CEOLast updated The Model Context Protocol is an open standard for connecting AI applications to external systems — data sources, tools and workflows — over a defined wire protocol instead of a bespoke integration per pair. The project's own introduction offers the analogy that MCP is like a USB-C port for AI applications: just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.
The shape of the protocol
The specification — current revision 2026-07-28 — names three roles and one message format. Hosts are the LLM applications that initiate connections. Clients are the connectors living inside a host application. Servers are the services that provide context and capabilities. They talk to each other in JSON-RPC 2.0 messages. The current revision lists the base protocol as stateless, self-contained requests with per-request capability negotiation — a change from earlier revisions, which specified stateful connections and a single negotiation at the start of a session.
The design lineage is stated in the spec itself: MCP takes some inspiration from the Language Server Protocol, which standardised how support for a programming language is added across a whole ecosystem of development tools. The bet is the same one — that N editors times M languages is unworkable, and N plus M is not.
What a server offers, and what a client offers back
A server may expose any of three features:
- Resources — context and data, for the user or the model to use.
- Prompts — templated messages and workflows for users.
- Tools — functions for the model to execute.
The direction most people forget is the other one. A client may offer a feature to a server: elicitation, meaning server-initiated requests for additional information from the user. Alongside it sit utilities for configuration, progress tracking, cancellation and error reporting. Earlier revisions also listed sampling and roots as client features; the current revision's client-features list names elicitation alone.
Beyond the core protocol the specification defines opt-in extensions, negotiated during initialization and requiring explicit support from both client and server. The ones it calls out are Tasks, for asynchronous execution of long-running operations with polling, mid-flight input and durable handles; Skills over MCP, for structured agent-workflow instructions discovered and consumed through MCP; and MCP Apps, for interactive UI elements rendered inline within conversations.
That two-way arrangement is why an MCP server is not simply a REST API with a different envelope: a server can interrupt its own call to ask the person on the other end for something it needs.
The security section is the important one
MCP enables powerful capabilities through arbitrary data access and code execution paths, and the specification spends a section on what follows from that. Its key principles are worth reading as design constraints rather than boilerplate:
- User consent and control. Users must explicitly consent to and understand all data access and operations, and must retain control over what data is shared and what actions are taken.
- Data privacy. Hosts must obtain explicit user consent before exposing user data to servers, and must not transmit resource data elsewhere without consent.
- Tool safety. Tools represent arbitrary code execution. Descriptions of tool behaviour, such as annotations, should be considered untrusted unless they come from a trusted server, and hosts must obtain explicit user consent before invoking any tool.
The crucial admission is that the protocol cannot enforce any of this at the protocol level; these are obligations on implementors. An untrusted server's tool description is text that reaches a model, which makes it an indirect prompt injection surface by construction.
Why it matters outside engineering
For anyone thinking about how a brand shows up in AI answers, MCP changes where the surface is. A model with no connectors can only work from training data and whatever a search tool retrieves. A model with connectors reads systems directly, on demand, in whatever structure those systems expose.
That makes the quality of a machine-readable interface a distribution question and not only an engineering one — the same shift in reasoning that llms.txt applies to documentation, applied to live data. It also makes the consent boundary a product decision: an integration that asks for broad access and offers vague tool descriptions is asking a user to approve something they cannot evaluate.
The ecosystem is broad enough that the standard is worth treating as settled infrastructure rather than a bet: the protocol's introduction lists assistants including Claude and ChatGPT and development tools including Visual Studio Code and Cursor among the clients that support it.
Terms related to Model Context Protocol (MCP)
A neural network with many parameters, trained on large amounts of text to predict the next token — and the reason an answer about your product can be fluent, confident and wrong.
The AI safety company that builds the Claude models, and the three separately-named web crawlers a publisher has to answer if they want Claude to read their pages.
Structuring the text given to a language model so its output meets a stated success criterion — and, for anyone measuring AI answers, the variable that decides what the measurement is of.
The token budget a model can reference in one request, what counts against it, and why a bigger window does not remove the need to retrieve selectively.