Here is MCP in three sentences. The Model Context Protocol is an open protocol for connecting LLM clients to external tools, resources, and prompt templates. A client (Claude Desktop, Cursor, Zed, your own agent) connects to one or more servers, each of which exposes capabilities the model can use. It is the USB-C moment for AI integrations: one connector shape, any device on either end.

That is the whole idea. The rest of this article is what the pieces actually are, why the protocol exists at all, and what changed between the November 2024 announcement and mid-2026, when MCP quietly became the assumed default.

This cluster goes deeper. Five articles: this one covers the protocol itself; MCP vs function calling untangles the two layers people constantly conflate; MCP server design basics covers the practical decisions when you build one; MCP security considerations is the honest risk rundown; and the MCP servers worth knowing walks through what people actually run. There is also a shorter first-pass intro elsewhere on this site at the Model Context Protocol explained; this cluster is the deeper dive.

Where it came from

Anthropic published MCP in November 2024 as an open specification with SDKs and a set of reference servers. Two things about that launch mattered more than the protocol details.

First, it was genuinely open. The spec, the schema, and the SDKs went up under the modelcontextprotocol GitHub org, not behind an Anthropic API key. That meant Cursor, Zed, and dozens of other clients could adopt it without signing anything, and they did — adoption snowballed through 2025, and by mid-2026 shipping an "AI-native" tool without MCP support reads as an omission.

Second, the timing hit a real pain point. By late 2024, every serious LLM application had accumulated a pile of bespoke integrations: one for the filesystem, one for GitHub, one for the database, one for Slack. Every new client rebuilt the same pile from scratch. That is an M-times-N problem — M clients, N services, M×N integrations — and MCP collapses it to M+N: each client implements the protocol once, each service gets one server, and everything interoperates.

The architecture: client, server, transport

At the core of MCP are two roles.

The client is the LLM application. Claude Desktop was the first mainstream one; Cursor, Zed, Claude Code, and a long tail of custom agents followed. The client owns the model conversation, decides which servers to connect, and mediates everything the model does with them.

The server is a separate process that exposes capabilities. It might wrap a database, a SaaS API, your filesystem, or a browser. Critically, the server knows nothing about models. It answers protocol messages: here are my tools, here is the result of that call, here is that resource's content. A server written for Claude Desktop works unmodified in Cursor, because neither side is coupled to the other.

Between them sits a transport carrying JSON-RPC messages. Two options matter in practice:

  • stdio — the client launches the server as a local subprocess and talks over stdin/stdout. Zero network setup, and still how most local servers run in 2026.
  • HTTP — for remote servers. The original 2024 spec paired HTTP with server-sent events (SSE) for the server-to-client direction; the spec revisions since, through the 2026-07 release candidate, replaced that with streamable HTTP, a single-endpoint design that is simpler to deploy behind ordinary infrastructure. As of the 2026-07 spec release candidate, streamable HTTP is the remote transport, with the older SSE flavor lingering in legacy servers.

A connection starts with a capability handshake, and the server can send notifications — "my tool list changed," "this resource updated" — while it is handling a client request. (As of the 2026-07 spec release candidate the protocol layer itself is stateless; session state lives at the application level.) That two-way channel is one of the real differences from plain function calling, which the comparison article covers properly.

The three primitives

Everything a server offers falls into three buckets.

Tools are functions the model can call. create_issue, query_database, take_screenshot. The client fetches the server's tool list — each with a name, a description, and a JSON Schema for arguments — and presents them to the model through the provider's ordinary function-calling API. When the model emits a call, the client routes it to the server and returns the result. Tools are the action side: they do things.

Resources are data the client can read. Files, database schemas, log streams, documents — each addressed by a URI like file:///project/readme.md or db://schema/users. Resources are passive; nothing happens when you read one. The intended pattern is that the client (often with the user picking) attaches resources to the conversation as context, rather than the model triggering side effects to get at data.

Prompts are pre-baked prompt templates the server ships. A GitHub server might offer a "summarize this PR for review" prompt that slots in the right context. These surface in client UIs as slash commands or menu entries. Prompts are the least used of the three in production, but they are how a server author encodes "here is how to use my tools well" instead of hoping every user rediscovers it.

The tools/resources split sounds pedantic until you build a server and have to decide which side something belongs on — that call, and the naming and error-handling conventions that follow from it, is the subject of server design basics.

Why the protocol shape matters

You could ask: why a protocol at all? Why not a library of integrations?

Because a protocol survives the parts churning. Models change every few months. Clients come and go. Services update their APIs. A protocol boundary means each part can churn independently: the Postgres server updated for a new driver does not require Cursor to ship a release, and a brand-new client gets the entire existing server ecosystem on day one. This is the same reason HTTP outlived every specific browser and web server of the 1990s.

It also concentrates the trust decisions in one visible place. Every server you connect is a process acting on the model's behalf, with whatever credentials and access you gave it. That is a real attack surface — malicious tool descriptions, over-broad permissions, look-alike packages on registries — and it deserves its own treatment, which security considerations gives it.

The state of play, mid-2026

As of July 2026, the honest summary: the core protocol is stable, the periphery is still moving. Tools, resources, prompts, stdio, and streamable HTTP are the current spec direction, with the 2026-07 release candidate still in its finalization window — solid enough to build against, not yet frozen. Authorization for remote servers (OAuth-based, tightened across the 2025 spec revisions) is standardized but unevenly implemented across clients. Server registries exist and are useful, but curation and supply-chain vetting are still maturing — treat installing a server more like adding a dependency than installing an app.

The ecosystem is large enough that the practical question has shifted from "should we support MCP" to "which servers do we actually trust and run" — the question the servers worth knowing tries to answer honestly.

The takeaway

MCP is a small protocol doing one job well: a standard way for LLM clients to discover and use external capabilities, so integrations are written once instead of once per client. Client, server, transport; tools, resources, prompts. Published open in November 2024, mainstream by mid-2026. If you learn one infrastructure-level piece of the LLM stack this year, this is the one with the best effort-to-payoff ratio — and it is small enough to actually finish learning.