What is the Model Context Protocol?

The Model Context Protocol (MCP) is an open protocol that standardises how an AI application discovers and uses tools and data that live outside it. You write an MCP server once and any compatible client can consume it, with no bespoke connector. It answers the N×M problem: N applications times M systems gives you N×M integrations to maintain.

Anthropic published MCP on 25 November 2024 and donated it to the Agentic AI Foundation, a directed fund of the Linux Foundation, on 9 December 2025. As of 30 July 2026, the date this article was checked, the current spec revision is 2026-07-28, published two days earlier¹. It rewrote the core of the protocol, and most of what is written about MCP describes the revision before it.

Two structural facts before any detail. The architecture has three roles: host, client and server. And a server exposes exactly three kinds of thing, tools, resources and prompts, each driven by a different actor.

What actually goes over the wire

MCP is JSON-RPC 2.0 over a transport. When the model decides to use a tool, the client builds a tools/call request with the tool name and its arguments, sends it to the server, and gets back a result that lands in the context of the next call to the model.

That sentence hides three things people trip over.

The model executes nothing. It returns the request; the client decides whether to send it; the server runs it. Three processes, and it is that separation that gives you somewhere to put permissions, argument validation and human confirmation.

Each client talks to exactly one server. A host with four connected servers has four clients, isolated from one another. No server sees what another received, and none of them sees the whole conversation — the host does the aggregating.

Server does not mean remote service. Most of the servers you will install in 2026 start as a subprocess on your own machine and talk over stdin and stdout.

The three primitives, and who drives each

The most underrated part of MCP’s design is that the primitives are not just three data shapes. Each has a different owner¹.

Primitive	Who triggers it	Example
Tools	the model	create_issue, run_query
Resources	the application	file contents, git history
Prompts	the user	slash command, menu item

Tools are what nearly everyone uses, and they carry the risk, because they are the only primitive the model fires on its own. Resources are data the client attaches to the context by the application’s decision, without the model asking. Prompts are instruction templates the user picks deliberately.

If you are sizing up a third-party server, the useful question is not how many tools it ships. It is which of them write somewhere.

The two transports, and what happened to SSE

Revision 2026-07-28 defines two standard transports¹:

stdio. The client launches the server as a subprocess and exchanges newline-delimited JSON-RPC over the standard streams. This is what runs when you add a server to your editor’s config file.

Streamable HTTP. Each message is a POST to a single endpoint. The reply comes back either as a JSON object or as an SSE stream scoped to that one request.

Here is where writing about MCP goes wrong most often. “SSE” was the name of an older, two-endpoint transport introduced in revision 2024-11-05. That transport has been deprecated since 2025-03-26 and, in 2026-07-28, it was reclassified as Deprecated in the formal feature registry, eligible for removal three months after the matching policy reaches Final¹. SSE itself did not die: Streamable HTTP still uses SSE for the response stream. “MCP dropped SSE” is wrong; “the two-endpoint HTTP+SSE transport is on its way out” is right.

The same revision removed stream resumability, meaning the Last-Event-ID header and SSE event IDs. If the connection drops mid-call, the request is lost and the client has to re-issue it under a new ID.

The problem it solves

The arithmetic in the figure is the whole argument, and it deserves some suspicion. The protocol does not make integration vanish: somebody still writes the code that calls your API, handles its errors and decides what to expose. What changes is that this code exists once per system rather than once per pair.

The payoff starts at the second consumer. If you have one agent and one API, MCP adds a process, a transport and a message format for nothing. If you have three applications that all need the same database, it pays for itself on the first one.

Who already speaks MCP

The question that decides adoption is not a technical one. It is whether there is anything on the other end.

In December 2025, when the protocol was donated to the Agentic AI Foundation, the maintainers reported 97 million monthly SDK downloads and roughly 10,000 active servers, with first-class support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code². The foundation launched with Anthropic, OpenAI and Block, and MCP’s maintainers kept autonomy over the project’s technical direction.

That is the strongest argument for MCP and the shakiest one to quote. The numbers move monthly, and “how many servers exist” measures far less than it appears to, for the reason the limits section covers. What matters here is the shape of the data, not its size: the protocol stopped belonging to one vendor, and that is what makes writing a server sensible instead of writing a connector.

MCP does not replace function calling

This mix-up burns meeting time, and the answer is short: they sit at different layers.

Function calling is the mechanism inside the model provider’s API call. You declare tools in the request body, the model returns an intent to use one, your code runs it. That is between you and the provider.

MCP is the mechanism by which your application finds out which tools exist and talks to whatever runs them. The tools an MCP server advertises become function calling declarations in the call to the model. The detailed comparison lives in MCP or function calling, but the working rule fits on one line: MCP solves distribution, function calling solves invocation.

What changed on 28 July 2026

Revision 2026-07-28 is the largest change since launch, and it invalidates a good share of existing tutorials¹. The changes that hit running code hardest:

1. The protocol went stateless. The initialize and notifications/initialized handshake is gone. Every request now carries its own protocol version and the client’s capabilities in _meta.
2. Transport sessions are out. The Mcp-Session-Id header was removed from Streamable HTTP. A server that needs state across calls now mints an explicit handle and receives it back as an ordinary tool argument.
3. server/discover is in. A mandatory RPC returning the server’s supported versions, capabilities and identity in a single request.
4. Sampling, roots and logging were deprecated. They still work, but the feature registry sets their earliest removal at the first revision released on or after 28 July 2027.
5. Tasks became an official extension, outside the core, alongside an extensions framework and a formal deprecation policy with a twelve-month minimum window.

The practical effect in August 2026 is a mismatch. The four Tier 1 SDKs (TypeScript, Python, Go and C#) shipped updated alongside the spec, and the Rust one is in beta. But the servers installed on your machine and the hosts you use still speak 2025-11-25 or older, and will keep speaking it for a while.

Where MCP fails

Four concrete limits, each with evidence behind it.

The catalogue is inflated. A 2025 survey crawled six MCP server marketplaces over 14 days, collected 17,630 entries and found that 8,401 of them corresponded to valid projects — 8,060 servers and 341 clients. More than half of what was listed was a placeholder, an abandoned prototype or a duplicate³. Server counts in a marketplace are not a measure of ecosystem maturity.

A tool description is untrusted input. The text describing a tool enters the model’s context and shapes what it decides to do. A 2025 study analysed 67,057 servers across six public registries and found widespread conditions for server hijacking and invocation manipulation; the authors’ analysis tool flagged 833 vulnerable servers and 18 with misleading descriptions⁴. Earlier work had already mapped an MCP server’s lifecycle into four phases and catalogued 16 matching threat scenarios⁵.

Human approval is mostly absent. A 2026 study mined 1,723 applications that consume MCP servers from GitHub. 90.8% log, and 77.2% offer controls to enable and disable servers, but only 37.2% put a blocking approval in front of tool execution⁶. In most of them the model fires any enabled tool without passing by anyone.

The spec moves fast. Five revisions in twenty months, and the latest one removed the handshake every tutorial teaches. If you depend on MCP in production, that is a recurring maintenance line, not a one-off integration cost.

The official server registry at registry.modelcontextprotocol.io was still in preview as of 30 July 2026, carrying an explicit warning that breaking changes and data resets may happen before general availability.

What it costs

MCP’s direct cost is context. Every tool a server advertises becomes a declaration in the prompt: name, description and a JSON Schema for the arguments. As an order of magnitude, a modest tool takes somewhere between 100 and 400 tokens, and that bill repeats on every call to the model, not once per session.

Three servers with ten tools each put roughly 3,000 to 12,000 tokens of prefix in place before the user types anything. Treat that as an order of magnitude rather than a measurement: count your own with your provider’s token counting endpoint before deciding anything.

The consequence is that “connect every server available” is an expensive and quiet decision. It also degrades the model’s choices, since it now picks from dozens of similar-looking tools.

Where to start

1. Use a finished server before writing anything. Connect a filesystem or database server to the editor you already use and watch the calls go by. Half an hour here beats any explanation, and the list of essential MCP servers is a reasonable starting point.
2. Read a server’s tools before enabling it. Descriptions and schemas are what enters your context and steers the model. Treat them as third-party code with execute permission, because that is what they are.
3. Start on stdio. Local server, no auth, no network. Authentication and Streamable HTTP are the next problem, not the first one.
4. Pin the protocol revision you support. With 2026-07-28 freshly published and most of the ecosystem sitting on 2025-11-25, code that assumes a revision without checking is the likeliest source of bugs over the coming months.
5. Enable few tools. Start with read-only ones. Add the writing ones one at a time, and only once a blocking approval sits in the path.

Step 5 is what separates a demo from a system, and it is the one the data says almost nobody does.

Footnotes

1. Revision 2026-07-28 of the specification is the source for the primitives, the two transports, the deprecation state of HTTP+SSE and the stateless protocol changes described here. Checked on 30 July 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. The donation announcement of 9 December 2025 is where the monthly SDK download and active server figures quoted here come from, along with the list of hosts with first-class support. ↩

3. Guo et al. (2025) crawled six marketplaces over 14 days, collected 17,630 entries and validated 8,401 projects, of which 8,060 servers and 341 clients. ↩

4. Li et al. (2025) analysed 67,057 servers across six public registries and identified 833 servers with an exploitable vulnerability and 18 carrying misleading tool descriptions. ↩

5. Hou et al. (2025) broke an MCP server’s lifecycle into four phases and 16 activities, and derived a taxonomy of 16 threat scenarios by attacker type. ↩

6. Majeed et al. (2026) mined 1,723 MCP-consuming applications on GitHub: 85.2% configure servers through files, 81.1% use an official SDK, and 37.2% require a blocking approval before executing a tool. ↩