What Is MCP? The Model Context Protocol Explained (2026)

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems: files, databases, SaaS apps, search engines and internal tools. An MCP server exposes tools (actions), resources (data) and prompts (templates), and any MCP-capable host, such as Claude, ChatGPT, VS Code or Cursor, can discover and use them without custom glue code. The official docs describe it as "a USB-C port for AI applications". The current specification is version 2026-07-28.

Quick answer

• What it is: a protocol, not a product. Messages are JSON-RPC 2.0, defined by a public TypeScript schema.
• Who is involved: a host (the AI app) runs one client per server it connects to.
• What servers offer: tools the model can call, resources the app can read, prompts the user can pick.
• How it travels: stdio for local servers, Streamable HTTP for remote ones.
• What changed in 2026: the 2026-07-28 revision made MCP stateless (no initialize handshake, no sessions) and deprecated Sampling, Roots and Logging.
• Who runs it: Anthropic created it in November 2024 and donated it to the Agentic AI Foundation (Linux Foundation) in December 2025.
• Biggest risk: a server is code with your permissions. Treat every one like a dependency you install.

Why MCP exists

Before MCP, every AI app needed its own integration for every service. Ten apps and fifty services meant hundreds of one-off connectors, each with its own way of describing functions to the model. MCP turns that into a single contract: a service team writes one MCP server, and every host that speaks MCP can use it.

The specification says it takes inspiration from the Language Server Protocol, which did the same for programming languages and code editors. The analogy holds well. Before LSP, every editor had to implement Go or Rust support itself; after it, one language server worked everywhere.

Anthropic's launch post on 25 November 2024 shipped pre-built servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Adoption came quickly. When Anthropic donated MCP to the new Agentic AI Foundation on 9 December 2025, it reported more than 10,000 active public MCP servers and 97 million monthly SDK downloads across Python and TypeScript, with MCP adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. The foundation was co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg.

MCP architecture: hosts, clients and servers

The architecture overview defines three participants:

A "local" server is usually launched by the host as a subprocess and talks over stdio, so it serves one client. A "remote" server runs on someone's infrastructure, talks over Streamable HTTP and typically serves many clients.

MCP has two layers. The data layer is the JSON-RPC protocol itself: discovery, the primitives and notifications. The transport layer carries those messages and handles framing and authorization.

The three server primitives

A database server is the classic example from the docs: tools to run queries, a resource that holds the schema, and a prompt with few-shot examples of good queries.

On the client side, the remaining active feature in the 2026-07-28 spec is Elicitation: a server can ask the user for more information or confirmation mid-request. Sampling (a server asking the host's model for a completion), Roots and Logging are now deprecated. They still work during a deprecation window of at least twelve months, but new implementations should not adopt them.

Transports

The spec defines two standard transports:

1. stdio: newline-delimited JSON-RPC over the standard input and output of a subprocess the client launched. Best for local tools, and the safest choice for a server that only you should reach.
2. Streamable HTTP: each message is an HTTP POST to one MCP endpoint, and replies come back as JSON or a request-scoped Server-Sent Events stream. This is how remote servers work, usually with OAuth.

The older HTTP+SSE transport, deprecated since 2025-03-26, is formally on the removal path. If a vendor still gives you a URL ending in /sse, look for its /mcp endpoint.

What changed in the 2026-07-28 specification

Many explainers, and some top search results, still describe the 2025-06-18 spec. The 2026-07-28 changelog changes the mental model in several ways:

• MCP is stateless. The initialize / notifications/initialized handshake is gone. Every request carries its protocol version and client capabilities in _meta.
• No protocol sessions. The Mcp-Session-Id header is removed. Servers that need state across calls mint their own handles and receive them back as ordinary tool arguments.
• New server/discover method. Servers must implement it to advertise supported versions, capabilities and identity.
• subscriptions/listen replaces the old GET stream and resource subscribe calls for change notifications.
• Multi Round-Trip Requests (MRTR). Instead of servers sending requests to clients, a server returns an input_required result and the client retries with the answers. Elicitation now works this way.
• Tasks moved to an extension. Long-running work uses the official io.modelcontextprotocol/tasks extension. Other extensions include MCP Apps (interactive UI inside the chat) and Skills over MCP.
• Caching hints. List and read results carry ttlMs and cacheScope, and servers should return tools in a deterministic order to help prompt caching.

The official SDKs handle the compatibility work. The TypeScript quickstart notes that its serveStdio helper answers both 2026-07-28 clients and older clients that still open with initialize.

Build a minimal MCP server (Python)

The official Python SDK (package mcp, version 2.3.0 on PyPI at the time of writing) now uses an MCPServer class. Older tutorials import FastMCP; follow the current docs instead. You need a recent Python (the SDK README lists 3.11+) and uv.

uv init notes-server
cd notes-server
uv add "mcp[cli]"

Create server.py:

from mcp.server import MCPServer

mcp = MCPServer("notes")

NOTES: dict[str, str] = {}


@mcp.tool()
def add_note(title: str, body: str) -> str:
    """Save a note under a title."""
    NOTES[title] = body
    return f"Saved note '{title}'."


@mcp.resource("notes://{title}")
def read_note(title: str) -> str:
    """Return the body of a saved note."""
    return NOTES.get(title, "No note with that title.")


if __name__ == "__main__":
    mcp.run(transport="stdio")

The type hints and docstrings become the JSON Schema and descriptions the model sees, so write them as carefully as you would write an API's documentation. Test it in the MCP Inspector:

uv run mcp dev server.py

Then register it with Claude Desktop by adding it to claude_desktop_config.json (on macOS, ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": ["--directory", "/ABSOLUTE/PATH/TO/notes-server", "run", "server.py"]
    }
  }
}

Or, in Claude Code: claude mcp add --transport stdio notes -- uv --directory /ABSOLUTE/PATH/TO/notes-server run server.py.

One rule catches almost everyone: never write to stdout in a stdio server. A stray print() corrupts the JSON-RPC stream. Log to stderr.

The same idea in TypeScript

The TypeScript SDK's server package is @modelcontextprotocol/server, used with zod for schemas:

import { McpServer } from "@modelcontextprotocol/server";
import { serveStdio } from "@modelcontextprotocol/server/stdio";
import { z } from "zod";

function createServer() {
  const server = new McpServer({ name: "notes", version: "1.0.0" });
  server.registerTool(
    "shout",
    {
      description: "Return the text in upper case",
      inputSchema: z.object({ text: z.string() }),
    },
    async ({ text }) => ({ content: [{ type: "text", text: text.toUpperCase() }] }),
  );
  return server;
}

serveStdio(createServer, {
  onerror: (error) => console.error("Server error:", error),
});

serveStdio takes a factory because it may create a fresh server for a discovery probe. For a full walkthrough with a remote server and auth, see our guide on how to build an AI agent.

Who supports MCP

Hosts listed on the official intro page include Claude, ChatGPT, Visual Studio Code, Cursor and MCPJam, and Anthropic's December 2025 announcement adds Gemini and Microsoft Copilot. In practice:

• Claude (web and Desktop) connects to remote servers as "custom connectors", and Claude Desktop runs local servers through the config file or MCPB desktop extensions.
• Claude Code adds servers with claude mcp add and loads tool definitions on demand with tool search.
• VS Code and Cursor read JSON config files per workspace or per user.
• The MCP Registry at registry.modelcontextprotocol.io lists published servers. The reference servers repo now points there instead of keeping its own list.

For a vetted shortlist by job, read our guide to the best MCP servers.

MCP security: what can go wrong

The spec is blunt: tools "represent arbitrary code execution and must be treated with appropriate caution", and tool descriptions should be treated as untrusted unless they come from a trusted server. The protocol cannot enforce safety; hosts and server authors must. The official security best practices cover these attacks:

My own working rules: prefer the vendor's official remote server over a random community wrapper; give each server a token with the narrowest scope; keep write tools behind approval; never click "always allow" on a server that reads untrusted content and can also send data out. Our AI agent security guide goes further.

MCP vs RAG, API and function calling

MCP vs RAG. Retrieval-augmented generation is a technique for grounding answers in retrieved text. MCP is a transport for capabilities. A RAG search can be exposed as an MCP tool, so the real question is usually how you combine them. Full comparison: MCP vs RAG.

MCP vs API. An API is a service's own interface. MCP is a common protocol on top that lets AI apps discover capabilities at runtime. Most servers wrap a REST or GraphQL API. Full comparison: MCP vs API.

MCP vs function calling. Function calling is how a model emits a structured tool call inside one provider's API. MCP is how the host finds those tools and runs them. The host turns MCP tool definitions into function definitions for whichever model it uses.

Is MCP outdated or "dead"?

Autocomplete shows people searching "mcp is dead". The criticism is real but specific: connecting many servers loads many tool definitions into the context window, and passing large tool results through the model is slow and expensive. Anthropic's own engineering post on code execution with MCP describes one workflow dropping from about 150,000 tokens to about 2,000 when the agent writes code against MCP servers instead of calling every tool directly.

The ecosystem's response has been to fix the costs, not drop the protocol: tool search in Claude Code, progressive tool discovery in the client guidance, deterministic tool ordering for caching, and the stateless 2026-07-28 spec that is easier to scale behind load balancers. MCP is the integration layer; how much of it you load into context is a context engineering decision.

When to use MCP (and when not to)

Use MCP when you want an AI app to work with a system, especially if more than one AI app or model will use it, or when a vendor already ships an official server. Skip it for a fixed, deterministic integration in your own code: if your program always calls the same endpoint with the same parameters, call the API directly. MCP earns its place when a model decides what to call.