Model Context Protocol

MCP lets any AI application connect to any data source the same way.

Model Context Protocol. Anthropic introduced it in 2024, and since December 2025 it has not been Anthropic's — the protocol was donated to the Agentic AI Foundation (Linux Foundation, co-founded with Block and OpenAI), and is now governed by the community.

Four AI applications, and five things to connect them to: Google Drive, GitHub, a database, Slack, an internal API.

This is the N×M problem, and MCP's entire value is one sentence: any MCP client can talk to any MCP server. USB is the same story — before it, every peripheral brought its own connector.

Three roles, and the first two are what everyone conflates. When people say "MCP client" they usually mean Claude Desktop — which is the host.

Host

The AI application itself. Claude Desktop, VS Code, Claude Code. It holds the model, the conversation and the permissions. The host is the application.

Client

A connector inside the host, one per server. Not an application — a part of one. VS Code talking to two servers has two clients.

Server

The program offering tools and data. It may run on your machine or somewhere else. It cannot see your conversation, and cannot see other servers — that isolation is deliberate.

Three things, and the difference between them is not read versus write. That is the intuition almost everyone arrives with, and it is wrong.

The real difference is who decides to use it. Three situations, three different answers:

├─ One difference across all three: who presses the button.

Two standard transports. stdio: the server is a subprocess, talking over standard input and output. Streamable HTTP: each message is an HTTP POST. This is a difference in how, not in where: a server running on your own machine can speak Streamable HTTP just as well.

Worth knowing that their security properties differ completely: stdio inherits your user permissions and has no auth layer at all; the HTTP path wants OAuth and origin validation. And "local server" means "runs on your machine" — it says nothing about whether it reaches the internet. A local server can call a remote API perfectly happily.

Servers no longer remember anything.

2026-07-28 is the largest revision since MCP appeared, and it breaks things. A client used to handshake with a server to establish a connection, after which both remembered each other. There is now no handshake and no connection phase — every request carries its own version and identity, and the server forgets it as soon as it has answered.

The direction changed too: a server does not ask you a question. It returns "I need this" and ends the request; the client gets the answer and sends a fresh one.

The third one needs spelling out, because it reads as "servers can no longer ask for anything". What went is the mechanism for initiating a request, not the ability to ask. A server used to push a request across; now it can only say "I need this" in a response and stop, and the client picks it up from there.

So the features where a server asks a client for something are all still there, just routed differently — including Elicitation (asking the user for a piece of information) and Sampling (borrowing the host's model; the direction is the opposite of the intuitive one, so it trips people up more than anything else here).

Separately: Roots (telling a server which directories are in scope), Sampling and Logging are marked deprecated. They still work today, but do not treat them as the architecture to learn. Deprecation and the mechanism change above are separate things: one is about how a message travels, the other about whether the feature stays at all.

An MCP version is a date. It marks the last day a breaking change was made, not a release cadence. So for any MCP material you come across, the date tells you how current it is — which is the single most useful thing on this page.

2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28