What Is MCP (Model Context Protocol)? A Plain-English Guide for 2026

Most of the agents that call my sandboxes now arrive through MCP. An assistant lists the tools a server offers, a model picks one, and a request lands on infrastructure I run. I am asked "what is MCP, actually?" more often than any other question this year, usually by engineers who have configured three MCP servers in their editor and still could not draw the protocol on a whiteboard. This post is that whiteboard session: what the Model Context Protocol is in plain English, the three roles and three primitives that make it up, how messages move, what each spec version changed up to the stateless 2026-07-28 release, who governs it, who supports it, and where it can hurt you. For the hands-on half, the companion guide to building an MCP server in Python and TypeScript walks through code I ran this morning.

What is the Model Context Protocol, in one paragraph?

MCP is an open protocol that lets an AI application discover and use external tools and data through one standard interface instead of a custom integration per tool. Anthropic open-sourced it on 25 November 2024 with a spec, SDKs, local server support in Claude Desktop and a set of reference servers for systems like GitHub, Slack and Postgres. The specification says it takes inspiration from the Language Server Protocol, and that comparison is the most useful one I know. Before LSP, every editor needed its own plugin for every language. After it, a language team wrote one server and every editor could use it. MCP does the same for AI: a team writes one MCP server for their database, ticketing system or cloud API, and any MCP-capable assistant can use it. Under the hood it is JSON-RPC 2.0 messages with a defined set of methods. There is no model inside the protocol, and MCP says nothing about which LLM you use or how it reasons.

How does MCP work? Hosts, clients and servers

The architecture overview defines three participants, and most confusion clears up once you separate them.

The host is the AI application the user sees: Claude Desktop, Claude Code, VS Code, Cursor, ChatGPT. It owns the model, the conversation and the user's consent.

The client is a component inside the host that holds one connection to one server. A host connected to five servers runs five clients. You rarely see clients directly; they are what the SDKs implement.

The server is a program that exposes capabilities: a GitHub server, a Kubernetes server, the little runbook server in my guide. It can run locally as a child process of the host, or remotely as a web service shared by many users.

The flow is short. The host starts or connects to a server, the client asks what it offers, the host puts those tool descriptions in front of the model, and when the model decides to use one, the client sends a tools/call request and passes the result back into the conversation. The model never talks to the server directly. That separation matters for security, because the host is the only place that can enforce "ask the user first".

What can an MCP server offer? Tools, resources and prompts

Servers expose three primitives, and they differ in who decides to use them.

Tools are functions the model can call: create_issue, query_metrics, restart_deployment. Each has a name, a description and a JSON Schema for its inputs, and optionally an output schema for structured results. Tools are model-controlled, which is why they carry most of the risk.

Resources are read-only data addressed by URI, such as a file, a database schema or runbook://payments. They are typically application-controlled: the host or user decides what to attach as context.

Prompts are reusable templates a server publishes, like "triage this incident", that the user picks from a menu. They are user-controlled.

Clients can offer features back to servers too. Elicitation lets a server ask the user for input or confirmation mid-call. The 2026-07-28 revision deprecated three older client features, sampling (a server asking the host's model for a completion), roots and logging: they still work and stay supported for at least twelve months, but new servers should call LLM APIs directly and log to stderr or OpenTelemetry. Long-running work moved into an official Tasks extension, where the server returns a handle and the client polls for the result.

How do MCP messages travel? stdio and Streamable HTTP

There are two standard transports. With stdio, the host launches the server as a subprocess and they exchange newline-delimited JSON-RPC over stdin and stdout. It is the default for local servers, needs no network or auth, and acts with the user's own permissions. The classic first-server bug lives here: anything the server prints to stdout corrupts the channel.

With Streamable HTTP, the server is a web endpoint, typically /mcp, and each request is an HTTP POST answered with JSON or a short-lived Server-Sent Events stream. It replaced the original HTTP+SSE transport in the 2025-03-26 revision, alongside an OAuth 2.1 authorization framework. Since 2026-07-28 it is stateless: there is no session ID and no initialize handshake, and every request carries its protocol version and the client's capabilities in a _meta field, per the versioning page. New Mcp-Method and Mcp-Name headers let a gateway route or block a call without parsing the body. Here is what that looks like on the wire, against the Python server from my guide:

# A 2026-07-28 tools/call over Streamable HTTP. Server: Python SDK mcp==2.3.0 on 127.0.0.1:8000.
# No handshake and no session header: version and capabilities ride in _meta on every request.
curl -s -X POST http://127.0.0.1:8000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/call' \
  -H 'Mcp-Name: http_status' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"http_status","arguments":{"code":502},
                 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28",
                          "io.modelcontextprotocol/clientCapabilities":{}}}}'
# Response (trimmed): "structuredContent":{"code":502,"meaning":"Bad Gateway","retryable":true}

When I left out clientCapabilities, the server rejected the request with JSON-RPC error -32602 naming the missing key. The same server still answered an old-style initialize from a 2025-11-25 client, so one binary can serve both eras during the transition.

MCP spec versions from 2024-11-05 to 2026-07-28

MCP versions are dates, and a new date means a backwards-incompatible change; compatible additions land in the current version without a bump. There have been five dated revisions. People still quote a "2026-03-26" version; it does not exist.

Revision	What changed, in plain terms	Source
2024-11-05	Launch: tools, resources, prompts, sampling, stdio and HTTP+SSE	Anthropic announcement
2025-03-26	Streamable HTTP replaces HTTP+SSE; OAuth 2.1 authorization; tool annotations such as read-only or destructive	changelog
2025-06-18	Structured tool output, elicitation, servers become OAuth resource servers	changelog
2025-11-25	Experimental tasks, URL-mode elicitation, Client ID Metadata Documents, SDK tiers	changelog
2026-07-28	Stateless core: handshake and sessions removed, server/discover, routing headers, cacheable lists, tasks as an extension, sampling, roots and logging deprecated	release post

The deprecation policy is now written down: a deprecated feature stays in the spec for at least twelve months before it can be removed. That is the kind of boring promise you need before building a business on a protocol.

Who owns MCP now? The Agentic AI Foundation

Anthropic no longer controls it. On 9 December 2025 the Linux Foundation formed the Agentic AI Foundation (AAIF) with MCP, Block's goose and OpenAI's AGENTS.md as founding projects, and AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as platinum members. The spec is developed in the open through numbered proposals (SEPs), working groups and a published roadmap. Google's A2A protocol joined the same foundation in August 2026, which I covered in the agent-to-agent protocols post. Practically, this means MCP is no longer "Anthropic's thing" that competitors adopt reluctantly. It is a neutral standard with the big model vendors and clouds paying for its upkeep.

Who supports MCP in 2026?

Nearly every assistant that calls tools. The Linux Foundation's announcement listed Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT as adopters, and VS Code declared MCP support generally available in version 1.102 in July 2025. The release post for 2026-07-28 claimed close to half a billion SDK downloads a month across the Tier 1 SDKs (TypeScript, Python, Go and C#, with Rust in beta). I checked the two biggest registries myself today: the TypeScript v1 package did 256.8 million downloads in the 30 days to 18 October on the npm API, and the Python mcp package 235.2 million on pypistats. Download counts are inflated by CI, so read them as "this is infrastructure now", not as a user count.

On the server side, the official MCP Registry has been in preview since September 2025 and still is. It stores metadata, verifies who published a server through GitHub or DNS namespaces, and points at packages on npm, PyPI or container registries. It does not vet the code. My MCP ecosystem post counted the registry, the unofficial directories and the gateways in detail.

Is MCP secure? The risks that actually bite

The protocol has improved a great deal, and the spec is blunt about where responsibility lies: tools "represent arbitrary code execution", tool annotations should be treated as untrusted unless the server is trusted, and hosts must get explicit user consent before invoking any tool. The incidents of the last eighteen months were rarely protocol bugs. They were these:

Tool poisoning. Invariant Labs showed in April 2025 that a malicious server can hide instructions in a tool description the user never sees but the model reads, steering it to leak files such as SSH keys through tool arguments.

The lethal trifecta. Simon Willison's write-up of the Supabase MCP case describes an agent with private data access, exposure to untrusted text and an outbound channel: a crafted support ticket got a coding agent with elevated database access to copy a token table somewhere the attacker could read it.

Supply chain. JFrog found CVE-2025-6514, CVSS 9.6, in mcp-remote versions 0.0.5 to 0.1.15: connecting to a malicious server could run arbitrary OS commands on the client machine. Most local MCP servers are installed with a one-line npx or uvx command from a README, which is the same habit that keeps feeding npm worms.

None of this needs a new discipline. Pin and review servers like any dependency, prefer read-only modes, give remote servers short-lived scoped tokens rather than your personal ones, and run anything that executes model-written code in a real sandbox. I went through the controls in MCP Security in 2026.

FAQ

Is MCP the same as function calling?

No. Function calling is how a model API lets a model request a tool call within one application. MCP standardises how an application discovers tools from external servers and invokes them, so the same server works across many hosts. In practice a host turns MCP tool listings into function-calling definitions for its model.

Is MCP just an API?

It wraps APIs rather than replacing them. A REST API is designed for programmers who read docs; an MCP server packages a few operations with descriptions and schemas a model can use without docs, plus a standard way to discover them. Many MCP servers are thin layers over an existing REST API.

What is the difference between MCP and A2A?

MCP connects an agent to tools and data. A2A, Google's protocol now also at the Linux Foundation, connects agents to other agents that have their own reasoning and long-running tasks. The overlap has grown, but if the thing on the other end is a function, use MCP.

Do I need the 2026-07-28 version?

For new servers, use an SDK that speaks it: Python mcp 2.x or the TypeScript v2 packages. Older clients still work because current SDKs fall back to the 2025-11-25 handshake, so there is no need to wait for every host to upgrade.

What I would do this quarter

If I were a platform team starting with MCP this quarter, I would do three things. Write one internal server in-house, read-only, over something your engineers query every day, so the team learns the protocol from the inside rather than from vendor demos. Put every remote MCP server behind the same gateway, identity provider and audit logging you already use for APIs, because MCP traffic is API traffic with a model as the caller. And treat the list of approved servers as a dependency manifest that gets reviewed, pinned and scanned. Disclosure, since it is relevant: I run PandaStack, a microVM sandbox platform that agents reach mostly through MCP, so I see the consequences of the third point more often than most. The protocol is in good shape. Whether your use of it is depends on the same boring operational habits as everything else you run.

Related: MCP in 2026: 475M SDK Downloads a Month, 39,492 Servers in a Registry Still in Preview, and 12 Gateways Selling the Same 3 Features, MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't. and Agent-to-Agent Protocols in 2026: A2A Reached 1.0, Three ACPs Died or Merged, and MCP Learned to Do Most of the Same Job.