What is MCP?

Every time you wanted to give an LLM access to your data (Gmail, your database, your file system), you wrote a bespoke integration. Every time. For every model. For every app. Model Context Protocol (MCP) is Anthropic's answer to that mess. Released as open source in November 2024, it gives LLM apps and external systems a single standard language to speak. Think of it as the USB-C of AI tooling.

The problem MCP solves

Before MCP, every AI app shipped its own custom plumbing. Cursor had one way to talk to your file system, Claude Desktop had another, ChatGPT had a third, and your homemade agent had a fourth. If you built a Postgres connector for Claude, it was useless to anyone using Cursor. And vice versa.

MCP says: let's standardize the wire format and the verbs. Once a service speaks MCP, any MCP-capable host can use it. Build the connector once, plug it into any host.

The three primitives

MCP servers expose three kinds of things. Memorize these. They show up in every spec doc and SDK.

• Tools are functions the model can call. send_email, query_db, create_issue. They take typed input and return a result. The model decides when to invoke them.
• Resources are data the model can read. Files, database rows, log entries, API responses. Each has a URI like file:///home/me/notes.md or postgres://db/users/42. The host (or model) chooses which to load into context.
• Prompts are templates users can invoke intentionally. Slash commands, basically. /summarize-pr on a server might expand to a curated system + user message about how to summarize.

Host, client, server: the architecture

MCP has three roles. Get these straight and the docs stop being confusing.

• Host: the user-facing app. Claude Desktop, Cursor, Zed, Windsurf, your custom agent. The host wraps the LLM and the UI.
• Client: an instance inside the host that connects to exactly one server. A host typically runs many clients in parallel, one per server.
• Server: the thing exposing tools, resources, and prompts. Could be a local Node process reading your file system, or a remote HTTP endpoint serving GitHub-on-MCP.

# Conceptually, a host like Claude Desktop runs something like:
#
#   Host (Claude Desktop)
#   ├── Client A ── stdio ──> filesystem MCP server (local)
#   ├── Client B ── stdio ──> postgres MCP server   (local)
#   └── Client C ── HTTP  ──> github MCP server     (remote)
#
# Each client talks to exactly one server. The host orchestrates them all
# and feeds their tools/resources to the model.

Two transports: stdio and Streamable HTTP

MCP defines two ways for client and server to communicate:

• stdio: the server is a subprocess. Messages are JSON-RPC over stdin / stdout. Zero network. Perfect for local tools that need access to your filesystem or local DB.
• Streamable HTTP: the server is a remote endpoint. The client posts JSON-RPC requests and the server responds. This replaced the older SSE-only transport in the March 2025 spec. Used for hosted services like GitHub MCP, Notion MCP, etc.

What a real exchange looks like

MCP is JSON-RPC 2.0 over one of those two transports. The 2026-07-28 revision made the protocol stateless, which changed the shape of every request. There is no longer an initialize / initialized handshake and no Mcp-Session-Id. Each request carries its own protocol version, client identity, and capabilities, so any request can land on any server instance behind a round-robin load balancer with no shared storage.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_repos

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_repos",
    "arguments": { "query": "rust embedded", "language": "Rust" },
    "_meta": {
      "io.modelcontextprotocol/clientInfo": {
        "name": "claude-desktop",
        "version": "0.9.0"
      }
    }
  }
}

The two Mcp- headers are required on Streamable HTTP now. They duplicate the method and tool name from the JSON body so a gateway, rate limiter, or WAF can route and meter requests without parsing the body. If a client wants a server's capabilities up front it calls server/discover, but that call is optional rather than a mandatory first step.

The server replies with a list of content items (text, images, embedded resources). The host hands those to the model, which decides whether to call again or to answer the user. Responses to tools/list, prompts/list, resources/list and resources/read also carry ttlMs and cacheScope, so a client can cache your tool catalogue instead of refetching it on every reconnect.

What got deprecated in 2026-07-28

This revision came with a formal deprecation policy: anything marked deprecated keeps working for at least twelve months. Worth knowing before you copy an older tutorial.

• Roots, Sampling, and Logging are deprecated. They still work. Do not build new servers on them.
• The legacy HTTP+SSE transport is deprecated, with a year-long offramp. Streamable HTTP is the target.
• Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. DCR still works for backward compatibility and will be removed in a later revision.
• Server-initiated requests for elicitation and sampling no longer need a held-open stream. A server that needs a confirmation mid-call returns resultType: "input_required" and the client retries the original call with answers attached in inputResponses. The spec calls this Multi Round-Trip Requests.

Why web developers should care

MCP started in the AI tooling world, but it is already crossing into backend engineering. Companies that ship REST or GraphQL APIs are now shipping MCP servers alongside them. GitHub, Stripe, Cloudflare, Sentry, Notion, Linear and Figma all run official MCP servers. Across the four Tier 1 SDKs the project reported close to half a billion downloads a month in July 2026. The implication for you:

• Your future backend may expose POST /api/... for browsers and /mcp for AI agents. Two interfaces, one set of business logic.
• When you build internal tools, exposing them as MCP servers makes them instantly usable by every AI agent in your org.
• When you build an LLM app, you can consume any MCP server in the ecosystem instead of writing yet another bespoke integration.

Quick quiz

Recap

• MCP is an open protocol from Anthropic for connecting LLM apps to external tools, data, and prompts.
• Three primitives: tools (functions), resources (data), prompts (templates).
• Architecture: host (the app), client (one connection), server (the integration).
• Two transports: stdio for local subprocess servers, Streamable HTTP for remote ones.
• The current revision is 2026-07-28. It is stateless: no handshake, no session id, and Mcp-Method / Mcp-Name headers on every Streamable HTTP request.
• Web devs increasingly ship MCP servers alongside REST APIs so AI agents and humans can both use the same backend.