Model Context Protocol

In plain words

Any AI application that does something useful has to reach outside the model: read a file, query a database, call an API, pull a ticket. Before MCP, each of those connections was bespoke. A team wrote custom glue for every tool, and that glue only worked inside their own app.

MCP replaces the glue with a protocol. A server wraps a capability, such as your database, your filesystem, or a SaaS API, and any MCP-compatible client can connect to it and use it. The spec's own analogy is a USB-C port for AI applications: one standard plug instead of a drawer full of adapters.

How it works

MCP runs on JSON-RPC 2.0 over a host-client-server architecture. The host is the AI application a person actually uses: Claude Desktop, an IDE like VS Code or Cursor, or a custom agent. Inside the host, one or more clients each hold a 1:1 connection to a server. The server is the program that exposes context and actions.

Servers expose three primitives:

• Tools are functions the model can call, like searchFlights or send_email. Model-controlled.
• Resources are read-only data identified by a URI, like file:///report.md. Application-controlled.
• Prompts are reusable templates a user invokes deliberately. User-controlled.

Clients can expose three capabilities of their own back to the server: sampling lets the server ask the model to generate text, roots scope which files or URIs the server may touch, and elicitation lets the server ask the user for input mid-task.

A connection is stateful. It opens with an initialize handshake where client and server negotiate which capabilities each side supports, then stays open for the session. Once connected, the model invokes a tool with a plain JSON-RPC request:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

Two transports carry these messages. stdio launches the server as a local subprocess and talks over standard input and output, the usual choice for a server on your own machine. Streamable HTTP handles remote servers over HTTP POST and GET, with optional Server-Sent Events for streaming. It replaced the older HTTP+SSE transport from the original 2024-11-05 revision, and that shift toward remote-first servers is recent.

Why it matters

The problem MCP solves is combinatorial. With N AI clients and M tools, bespoke integrations scale as N×M. A shared protocol collapses that to N+M: write a server once and every compliant client can use it, build a client once and it reaches every server.

Portability is the point. A tool you expose over MCP works in Claude, in ChatGPT, in an IDE, or in your own agent harness without reimplementing it per provider. Multi-agent setups, like a team of Claude Code agents, lean on MCP so every agent reaches the same tools, and which SDKs and providers wire it up is worth tracking on its own.

Origin

Anthropic introduced MCP on November 25, 2024, created by engineers David Soria Parra and Justin Spahr-Summers. The design borrows from the Language Server Protocol (LSP), which solved the same N×M problem for code editors: instead of every editor implementing every language, a language server speaks one protocol that every editor understands. MCP applies that idea to models and tools, and OpenAI and others adopted it through 2025.

The spec versions by date. The current revision is 2025-11-25, and the version string (YYYY-MM-DD) marks the last backwards-incompatible change rather than a semantic version. A recent experimental primitive, Tasks, wraps long-running requests in durable execution so results can be retrieved later.

Common confusions