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

MCP (Model Context Protocol) is an open standard that lets AI applications connect to external tools, data and services through one common interface. Instead of writing a custom integration for every app and every model, a developer builds an MCP server once (for GitHub, a database, a browser, Figma) and any MCP-compatible host, such as Claude, ChatGPT, Cursor or VS Code, can use it. People often call it "USB-C for AI": one plug shape, many devices.

Anthropic released MCP as an open-source project in November 2024. In December 2025 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, and today it is the default way agents reach the outside world. The current spec revision is 2026-07-28, which made the protocol stateless. This guide covers what MCP is, how the pieces fit, and what changed this year.

The problem MCP solves

A language model on its own can only read its prompt and write text. To be useful it needs context (your files, tickets, docs, database rows) and the ability to act (open a PR, run a query, send a message). Before MCP, every AI product built those connectors itself, in its own format. With M apps and N services you needed roughly M × N integrations, and none of them were reusable.

MCP turns that into M + N. Each service ships one MCP server, each AI app implements one MCP client, and they all speak the same JSON-RPC 2.0 messages. The design borrows openly from the Language Server Protocol, which did the same thing for programming languages and code editors.

MCP architecture: host, client, server

The spec defines three roles:

If you connect VS Code to a filesystem server and a Sentry server, VS Code (the host) creates two clients, one per server. The servers never see each other, and they never see the full conversation: the host decides what each one receives. That isolation is a deliberate security principle in the spec.

For a deeper look at the server side, see what is an MCP server. For the client side and a list of apps that support MCP, see the MCP client guide.

The building blocks: MCP primitives

MCP servers offer three kinds of capabilities, which the spec sorts by who is in control:

Tools are by far the most used primitive. Most hosts list a server's tools, hand their names and schemas to the model, and run the call when the model asks for it. Our resources vs tools guide goes into when to use which.

Clients can offer features back to servers too. The main one is elicitation: a server can ask the user for input mid-task (a missing parameter, a confirmation, or a URL to open for sign-in). Two older client features, sampling (the server borrows the host's model) and roots (the host tells the server which folders it may use), still work but were deprecated in 2026-07-28, along with protocol-level logging.

On top of the core, MCP has opt-in extensions. The best known are MCP Apps (interactive UI rendered inside the chat) and Tasks (long-running jobs with a durable handle you poll).

Transports: stdio and Streamable HTTP

The same messages can travel over two standard transports:

• stdio: the host launches the server as a local subprocess and exchanges newline-delimited JSON over stdin and stdout. This is how most local servers (filesystem, git, Playwright) run. Credentials usually come from environment variables.
• Streamable HTTP: the server lives at a URL such as https://example.com/mcp. Each message is an HTTP POST, and the server replies with JSON or a short Server-Sent Events stream. This is what "remote MCP server" means, and it uses OAuth for sign-in.

The older HTTP+SSE transport from 2024 is deprecated. If a guide tells you to point a client at an /sse endpoint, it is out of date; see SSE vs Streamable HTTP for the migration, and MCP authentication for how OAuth works on remote servers.

What an MCP exchange looks like

You rarely write raw MCP messages, because the SDKs do it for you, but seeing one makes the protocol concrete. Here a client calls a weather tool. In the 2026-07-28 revision every request carries its protocol version and client capabilities in _meta, so the server needs no prior handshake:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

And the server's answer:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Current weather in San Francisco: 68°F, partly cloudy"
      }
    ]
  }
}

That example is adapted from the official architecture guide. The full sequence (discovery, tools/list, calls, elicitation round trips and change notifications) is in how does MCP work.

A minimal MCP server

Building a server is short. This is the complete example from the official Python SDK README (uv add "mcp[cli]"):

from mcp.server import MCPServer

mcp = MCPServer("Demo")


@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b


@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

The type hints become the tool's JSON Schema and the docstring becomes its description. uv run mcp dev server.py opens it in the MCP Inspector so you can call add by hand. Official SDKs also exist for TypeScript, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin (SDK list). To go further, follow build an MCP server or the Python MCP server tutorial.

Using an existing server

Most people never write a server; they install one. In Claude Code, adding the hosted Notion server is a single command from the Claude Code docs:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Desktop apps use a JSON config instead. This is the filesystem server from the official quickstart, placed in claude_desktop_config.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop"
      ]
    }
  }
}

Popular starting points include the GitHub MCP server, Playwright MCP for browser automation, Context7 for up-to-date library docs and the Filesystem server. Client-specific steps are in our setup guides for Claude Code, Cursor, VS Code and ChatGPT.

Who supports MCP

When Anthropic handed MCP to the Linux Foundation, it reported more than 10,000 active public MCP servers and support in ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. Coding agents such as Claude Code, Codex and Cursor treat MCP as their main extension mechanism. On the server side, most major SaaS vendors now run a hosted MCP endpoint, and directories such as MCP.so and the official MCP Registry (still in preview) index them.

History and governance

Version strings are dates: each marks the last backwards-incompatible change. The project is formally "Model Context Protocol a Series of LF Projects, LLC", and technical governance runs through lead maintainers, core maintainers and working groups, with changes proposed as SEPs (Specification Enhancement Proposals). Membership is per person, not per company.

What changed in 2026-07-28

If you learned MCP in 2025, three things are different (changelog):

1. No more initialize handshake or sessions. Each request carries its version and capabilities, so remote servers can sit behind ordinary load balancers. A new server/discover call returns a server's versions and capabilities when a client wants them up front.
2. Servers no longer send requests to clients. When a server needs user input, it returns an input_required result and the client retries the call with the answer (the multi round-trip request, or MRTR, pattern).
3. Change notifications move to subscriptions/listen, a single long-lived stream the client opts into.

Older clients and servers keep working through a documented compatibility mode, and the official SDKs speak both eras.

MCP vs function calling, APIs and RAG

• Function calling is a model feature: the model emits a structured request to call a function you defined. MCP is the layer that supplies those functions from outside the app, discovered at runtime, from any vendor.
• REST APIs are built for programs. An MCP server usually wraps one, but adds descriptions and schemas written for a model, plus consent and auth flows written for a user.
• RAG retrieves passages to stuff into a prompt. MCP can serve as a retrieval path, but it also covers actions. See MCP vs RAG.
• A2A (Agent2Agent) connects agents to other agents, while MCP connects an agent to tools. They fit together; see A2A vs MCP.

Is MCP safe?

MCP is a protocol, so safety depends on the servers you trust and the host you run them in. The spec requires hosts to get explicit user consent before invoking tools and treats tool descriptions from untrusted servers as untrusted input. In practice: install servers from known publishers, prefer official hosted endpoints with OAuth over pasted tokens, keep write-capable tools behind approval prompts, and limit filesystem servers to the folders they need. Our MCP security best practices covers prompt injection, tool poisoning and token handling in detail.

Next steps

• Browse more than a thousand servers in the MCP.so directory, or start with the best MCP servers.
• Learn the wire protocol step by step in how does MCP work.
• Pick an app from the MCP clients list and follow its setup guide.