What is MCP? The Model Context Protocol explained (2026 edition)

The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need: files, databases, ticket trackers, browsers, internal APIs. Instead of every chatbot and coding agent writing its own GitHub integration, a developer writes one MCP server and any MCP-capable app can use it. That is the whole pitch, and two years in, it has largely worked. MCP is now supported by the major assistants and developer tools, it is governed by a Linux Foundation body rather than a single company, and its latest revision, dated July 28, 2026, rewrote the protocol's core to make it stateless.

This explainer covers where MCP came from, how it works, what changed in 2026, who supports it, and where it can hurt you. If you want to build a server, go to our step-by-step TypeScript guide. If you want the difference between tools, resources and prompts in detail, read MCP resources vs tools vs prompts.

Where MCP came from

Anthropic announced MCP on November 25, 2024. The launch included the specification, SDKs, support for local MCP servers in the Claude desktop apps, and an open-source repository of reference servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Anthropic named Block and Apollo as early adopters and said Zed, Replit, Codeium and Sourcegraph were working with the protocol.

The problem MCP targets is integration sprawl. Each AI app needs connectors, and each data source needs a connector for each app. MCP's own docs compare it to "a USB-C port for AI applications": one standard plug on both sides.

Who controls it now

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, with Google, Microsoft, AWS, Cloudflare and Bloomberg named as supporters. Anthropic said at the time that MCP's governance model "will remain unchanged."

Day-to-day technical decisions sit with the project itself, which is set up as "Model Context Protocol a Series of LF Projects, LLC." Its governance page lists two Lead Maintainers with final decision authority (David Soria Parra and Den Delimarsky) and six Core Maintainers. Membership is individual, not per company, and spec changes go through public Specification Enhancement Proposals (SEPs). Code and specs are Apache 2.0 licensed.

How MCP works: hosts, clients, servers

MCP has three roles:

• Host: the AI application the user sees, such as Claude Desktop, ChatGPT, VS Code or Cursor.
• Client: a connector inside the host. The host creates one client per server connection.
• Server: a program that exposes capabilities. It can run locally on your machine or remotely as a web service.

Messages are JSON-RPC 2.0. The spec defines two standard transports:

• stdio: the host launches the server as a subprocess and exchanges newline-delimited JSON over stdin and stdout. This is how most local servers run. Anything the server prints to stdout that isn't protocol traffic breaks the connection, which is why server logs must go to stderr.
• Streamable HTTP: every message is an HTTP POST to a single endpoint, and replies come back as JSON or as a request-scoped server-sent-events stream. This is how remote servers run. The older HTTP+SSE transport is formally deprecated.

Authorization applies to HTTP transports only. A protected MCP server acts as an OAuth 2.1 resource server: it must publish OAuth Protected Resource Metadata (RFC 9728), clients must send a resource indicator (RFC 8707) so tokens are bound to that server, and servers must reject tokens issued for anyone else. "Token passthrough," where a server forwards a client's token to a downstream API, is explicitly forbidden. For stdio servers, the spec says to read credentials from the environment instead.

The building blocks (primitives)

Servers offer three kinds of things, each with a different "who decides" model:

Clients can also offer features to servers: elicitation (the server asks the user for input through the client, either via a form or by sending them to a URL), sampling (the server asks the client's model to generate text) and roots (the client tells the server which directories it may work in). As of the 2026-07-28 revision, sampling, roots and logging are deprecated; more on that below. Our primitives explainer walks through each one with JSON captured from a working example server.

What changed in the 2026-07-28 spec

MCP versions its spec by date. The current revision is 2026-07-28, published that day alongside updated SDKs. Earlier revisions include 2024-11-05, 2025-03-26, 2025-06-18 and 2025-11-25. The 2026 release is the biggest change since launch. According to the official changelog:

• No more sessions or handshake. The initialize/initialized exchange and the Mcp-Session-Id header are gone. Every request now carries its protocol version and client capabilities in a _meta field, so any server instance behind a load balancer can answer any request.
• server/discover is a new mandatory method that lets a client ask a server which versions and capabilities it supports.
• Multi round-trip requests (MRTR) replace server-initiated requests. When a server needs user input mid-call, it returns an input_required result; the client gathers the answer and retries the original request.
• Tasks moved out of the core into an official extension (io.modelcontextprotocol/tasks) for long-running jobs.
• Cacheable lists: list and read results now carry ttlMs and cacheScope hints.
• Deprecations: Roots, Sampling and Logging are deprecated. They still work, and the earliest they can be removed is the first spec revision released on or after July 28, 2027. OAuth Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.

The MCP blog says all four "Tier 1" SDKs (TypeScript, Python, Go, C#) supported 2026-07-28 on release day. In practice, servers and clients negotiate: a 2026-era client can still talk to a 2025-era server and vice versa. When we compiled and ran the example server from our TypeScript guide with the official SDK (v2.3.1) on Node.js 22 to check the code, it answered both a 2025-era client (which negotiated 2025-11-25) and a client pinned to 2026-07-28 from the same code, using the SDK's era-aware serveStdio() entry point.

The project also now has official extensions, opt-in add-ons negotiated per request. The best known is MCP Apps (io.modelcontextprotocol/ui), which lets a tool return an interactive HTML interface that the host renders in a sandboxed iframe.

Who supports MCP

Last verified: October 9, 2026

Support is uneven below the headline. Nearly everyone supports tools; resources, prompts and elicitation vary; and the extension matrix on modelcontextprotocol.io (community-maintained) shows MCP Apps widely adopted but auth extensions rare. Anthropic's December 2025 post also named Gemini among products that had adopted MCP; the table lists only Gemini CLI, whose documentation describes its MCP support.

On scale, the numbers are self-reported. Anthropic said in December 2025 that there were more than 10,000 active public MCP servers and 97 million monthly SDK downloads. The MCP blog said in July 2026 that the Tier 1 SDKs were at "close to half-a-billion downloads a month." We have not independently verified either figure.

The registry

The MCP Registry is the project's official metadata catalog for publicly accessible servers. It stores a server.json description (name, package location, how to run it), not the code itself, and ties names to verified namespaces such as io.github.username/server. As of October 9, 2026, the registry describes itself as in preview, with "breaking changes or data resets" possible before general availability. It is aimed at downstream marketplaces and aggregators rather than at end users, and it delegates security scanning to package registries like npm and PyPI. A listing is not a security review.

The security problem

MCP makes it easy to give a model new powers. That is also the risk.

• Prompt injection. Anything a tool returns, such as a web page, an email or a GitHub issue, goes into the model's context. If that content contains instructions, the model may follow them. Claude Code's docs warn that "servers that fetch external content can expose you to prompt injection risk."
• Tool poisoning. On April 1, 2025, Invariant Labs showed that a malicious server can hide instructions in a tool's description, which the model reads but the user typically doesn't. In their demo against Cursor, a harmless-looking "add" tool steered the agent into reading SSH keys and an MCP config file and sending them to the attacker. They also described a "rug pull": a server changing its tool descriptions after the user approved it.
• Annotations aren't guarantees. Tools can declare hints like readOnlyHint. The MCP blog's own March 16, 2026 post is blunt: "A server can claim readOnlyHint: true and delete your files anyway."
• Local servers are code execution. A stdio server is a program running with your user's privileges. The spec's security guidance says clients offering one-click installs must show the full command and get explicit consent, and should sandbox servers.

The spec's answer is a human in the loop: clients "SHOULD" show which tools are exposed, flag when they run, and ask for confirmation on sensitive operations. The practical answer is to install fewer servers, prefer ones from vendors you already trust, read what a server's tools do, and run risky ones sandboxed. Our analysis of unattended agents goes deeper on why "approve all" is the dangerous default.

What MCP is not

• Not a model or an agent. MCP doesn't decide anything. It's plumbing between an app and external capabilities. The agent behavior comes from the host and the model (see what "agentic" really means).
• Not a security boundary. It defines how to ask for permission, not whether a server is trustworthy.
• Not a replacement for APIs. Most MCP servers wrap existing REST or GraphQL APIs. MCP standardizes how a model discovers and calls them.
• Not required for tool use. Every major model API has native function calling. MCP matters when you want one integration to work across many hosts.
• Not an app store. The registry is metadata in preview, not a vetted marketplace.

What to do next

If you're a user, check which MCP servers or connectors your AI apps have enabled and remove the ones you don't use. If you're a developer, start with a local stdio server, test it with the MCP Inspector, and only then think about remote hosting and OAuth. Our TypeScript walkthrough does exactly that, with example code we compiled and ran to check that it works.