MCP is a standardised way to connect a model to external data sources and tools. Open-sourced by Anthropic, and now the closest thing the ecosystem has to a common port.

Before, every integration was a bespoke adapter living inside the app. After, the app speaks one protocol and every integration is a server behind it — swappable, reusable, written once by whoever owns the system.

The problem underneath is simple. A model's knowledge is a fixed store, and it is isolated from live systems — so every integration needs a bespoke bridge.

N × M

N models, M tools, every pair speaking its own protocol. That is chaos with two costs: wasted build effort and, worse, wasted maintenance effort — M integrations that each break on their own schedule.

One protocol in the middle collapses it to N + M:

Three roles, and they are easy to blur. The host is the application. It holds one client per connection. Each client talks to one server.

The server is the only piece most people write. It exposes capabilities and does the talking to whatever sits behind it — a local database, a web API, a filesystem.

Two transports in practice, and the choice is really "same machine or not".

Why the shift away from SSE

The original remote transport held a long-lived server-sent-events stream open so the server could push requests back. That made every connection sticky — you could not put a plain load balancer in front of it, and a dropped stream lost the session.

What actually happens when a user asks something the model cannot answer alone.

The two halves

• Discovery. The client asks the server what it offers and gets back a described list. The model reads those descriptions like documentation.
• Invocation. The model picks one, the client calls it, the server does the real work and returns something the model can read.

A server exposes three things. The difference that matters is who decides to use them.

The wire methods

Discovery and use are separate calls, and each has a list side and an act side: tools/list then tools/call, resources/list then resources/read, prompts/list then prompts/get.

The protocol was originally two-way: a server could call back into the client to borrow the model, ask the user something, or read the workspace roots.

All of these needed a held-open bidirectional stream, which is exactly what the stateless core removed.

What replaced elicitation

Multi Round-Trip Requests. Instead of pushing a question down an open stream, the server returns resultType: "input_required" along with what it needs. The client collects the answers and retries the original call with them attached.

The model never sees your code. It sees a name, a description and a schema — so that is where quality lives.

The failure modes

• Tool soup. Forty tools with terse names. The model picks wrong, and no amount of prompt engineering above it fixes a bad menu.
• Swallowed errors. A tool that returns an empty result on failure teaches the model that the answer is "nothing".
• Unpaginated returns. One tool dumping a full JSON document is the most common cause of a blown context window.

The loop consuming these tools is its own subject — see an agent is a loop in the AI garden.

A server is smaller than it sounds. It declares what it can do, then answers two kinds of call for each primitive: list them and do one.

The shape of one tool

A common confusion: MCP does not replace function calling. It sits above it.

The model still emits a tool call the same way it always did. MCP answers the question one level up: where did that list of tools come from, and who else can use it?

Every MCP server is a new piece of untrusted text entering the model's context and a new set of privileges the model can reach. Both are attack surface.

The one that surprises people

Tool descriptions are context. A server can put instructions in a description, and the model reads them the same way it reads yours. Invariant Labs demonstrated this concretely: a poisoned description on a second server was enough to get a model to exfiltrate a user's entire WhatsApp history through an innocuous-looking call.

Confused deputy, concretely

An agent legitimately holds a broad database credential. A prompt injection persuades it to use that credential for something the deployer never intended. The server was not hacked — it did exactly what it was asked.

For remote servers, authorization is the whole game. The spec settles on OAuth 2.1, and the details it tightens are the ones that get exploited.

Two hardening changes worth knowing

• Issuer validation (RFC 9207). Credentials are bound to the issuer that minted them, which closes a class of mix-up attacks between authorization servers.
• CIMD replaces Dynamic Client Registration. Client ID Metadata Documents are now the supported path; DCR is formally deprecated.

The 2026-07-28 spec is the largest change since MCP shipped, and it is mostly one idea: make the protocol stateless so it can be operated like a normal HTTP service.

Why statelessness was the blocker

With a handshake and a session id, every request had to land on the instance that started the conversation. That means sticky sessions, no plain round-robin, and a lost stream losing the session.