ai-info

Guides & answers

What Is MCP? Model Context Protocol Explained (2026)

·

You have probably been told MCP is the USB-C port for AI apps. The analogy works, and it is also why most explanations of it are now out of date: they describe a protocol that opens a session and keeps it. As of 28 July 2026, MCP dropped sessions and the handshake that created them. Everything below is what the specification actually says today.

The short answer

  • MCP is a protocol, not a product. It defines how an AI application talks to something that gives it context or tools. Messages are JSON-RPC 2.0, and their meaning is the same no matter how they travel.
  • Three roles. A host is the application (an IDE, a chat client). A client is the connector inside it. A server is the service exposing context and capabilities.
  • A server offers three things — tools (functions the model can call), resources (data it can read), prompts (templated messages and workflows). That is the entire server-side surface.
  • It is stateless now. Version 2026-07-28 removed protocol-level sessions, the Mcp-Session-Id header, and the initialize handshake. Every request carries its own version and capabilities.
  • What it does not do: MCP does not choose your model, does not make an agent, and does not grant permissions. Those stay in the host application.

1. What the protocol actually defines

MCP exists to solve a combinatorial problem. If every AI application needs a bespoke integration for every data source, M apps times N sources means M×N integrations. Standardise the wire between them and it becomes M+N.

The specification is deliberately narrow. It says how to frame and deliver messages, and what those messages mean. Three roles, from the specification overview:

Role What it is Example
Host The LLM application that initiates connections An AI-powered IDE, a chat app
Client The connector living inside the host One client per server connection
Server A service providing context and capabilities A filesystem server, a database server

The design borrows from the Language Server Protocol — the same trick that let one language server serve every editor. MCP does the same for AI applications and their context sources.

2. The three things a server offers

Servers expose any of three primitives. Everything else in the feature list is plumbing around them.

Tools — functions the model can execute

This is the one people mean when they say MCP. A tool is a function with a schema, advertised by the server and callable by the model. The specification is blunt about what that means: tools are arbitrary code execution, and a host must obtain explicit user consent before invoking any tool. Tool descriptions should also be treated as untrusted input unless the server is trusted — they are text that goes into a model's context.

Resources — context and data

Resources are things to read rather than run: file contents, database rows, API responses. Unlike tools, they are not chosen by the model calling a function; they are data pulled into context for the user or the model to use.

Prompts — templated messages and workflows

Server-defined message templates and multi-step workflows, surfaced to users. The least discussed of the three, and the one most implementations skip.

On the client side there is elicitation: a server asking the user for more information. Note that two other client features — roots and sampling — were deprecated in the 2026-07-28 revision, along with logging. They still work, but new implementations are told not to adopt them.

3. What changed on 28 July 2026

This is the part most existing explanations get wrong, and it is not a footnote. Version 2026-07-28 is a rewrite of the base protocol. From the official key changes:

  • Sessions are gone. Protocol-level sessions and the Mcp-Session-Id header were removed from Streamable HTTP. List endpoints no longer vary per connection. A server that needs state across calls now uses explicit handles it mints itself, passed as ordinary tool arguments.
  • No handshake. The initialize / notifications/initialized exchange is removed. Each request carries its protocol version and client capabilities in _meta. Version mismatches now return UnsupportedProtocolVersionError.
  • Discovery is explicit. Every server must implement server/discover to advertise supported versions, capabilities and identity. A client may call it up front, or use it as a backward-compatibility probe on stdio.
  • Notifications moved. The HTTP GET endpoint and resources/subscribe are replaced by subscriptions/listen, one long-lived stream clients opt into by notification type.
  • SSE resumability removed. Last-Event-ID and SSE event IDs are gone. A broken stream loses the in-flight request and the client must re-issue it with a new request ID.
  • Tasks moved out of core. Long-running operations are now an official extension rather than part of the base protocol.
  • Every result has a resultType. Either complete or input_required — the latter powers the new multi-round-trip request pattern, where a server returns what it still needs and the client retries with it.

If you learned MCP from a 2025 tutorial, the connection model you learned no longer exists. The primitives are the same; the plumbing underneath is not.

The revision also formalised a feature lifecycle with a minimum twelve-month deprecation window, so removals now come with notice — HTTP+SSE, deprecated since 2025-03-26, is now formally in the Deprecated state.

4. How messages actually travel

The protocol is transport-agnostic, and the semantics are identical on every transport — a transport only decides framing and delivery. Two standard bindings ship with the spec:

  • stdio — newline-delimited JSON-RPC over the standard streams of a subprocess the client launches. This is why most MCP servers today are local processes.
  • Streamable HTTP — each message is an HTTP POST to a single MCP endpoint; the reply comes back as a JSON object or as a request-scoped SSE stream.

Custom transports are allowed over any bidirectional channel, and the spec advises reusing stdio framing for byte streams like Unix sockets or TCP rather than inventing a new one.

5. What MCP is not

Three things get bundled into MCP that do not belong to it:

  • It is not an agent framework. MCP carries messages. Planning, memory, loops and orchestration are the host application's job.
  • It does not pick your model. The protocol has no opinion about which LLM sits behind the host. Model choice is a separate decision — see our Flash vs Pro comparison for how that one actually breaks down.
  • It does not grant permissions. Consent and authorisation live in the host. The specification states the security principles it expects implementors to follow — user consent and control, data privacy, tool safety — while being explicit that the protocol itself cannot enforce them.

That last point is the honest answer to "is MCP safe": the protocol designs for consent, but every guarantee is a decision the host application makes. If a client auto-approves every tool call, MCP will not stop it.

6. FAQ

What does MCP stand for and who created it?

Model Context Protocol. It was released by Anthropic in November 2024 as an open protocol, and is now developed in the open on GitHub with a formal SEP (Specification Enhancement Proposal) process and a published changelog.

Is MCP the same as tool calling?

No. Tool calling is a model capability — the model emits a structured request for a function. MCP is the protocol that carries such requests between an application and an external server, and it also covers resources and prompts. You can do tool calling without MCP, and MCP without any tool support.

Do I need to rewrite my MCP server for 2026-07-28?

If you implemented the 2025-era session model, yes, the connection layer has to change: no session header, no initialize handshake, and list endpoints must not vary per connection. The primitives you expose stay the same. Clients and servers interoperating with older revisions detect the counterpart's era and fall back, and the specification publishes a compatibility matrix.

Why did MCP drop sessions?

The changelog frames it as making the protocol stateless: each request is self-describing, carrying its version and capabilities. Servers that genuinely need cross-call state now mint their own handles and pass them as tool arguments, which moves state out of the transport and into application code where it can be reasoned about.

Is MCP only for local servers?

No — that is just an artifact of stdio being the easiest binding to ship. Streamable HTTP exists for remote servers, and the specification includes an authorisation section covering OAuth-style flows.

What happened to sampling and roots?

Both were deprecated in 2026-07-28, along with logging. They remain functional through the deprecation window, but new implementations should not adopt them. The suggested migrations are to pass paths via tool parameters or configuration instead of roots, and to call LLM provider APIs directly instead of sampling.

Sources

Every structural claim on this page traces to these pages, all checked 10 Sep 2026:

MCP is a fast-moving specification; this page describes revision 2026-07-28 and will be re-checked when the next revision lands. We have no affiliation with Anthropic or the MCP project, and this page carries no affiliate links — it is a plain-language reading of the published specification.