MCP explained: what the Model Context Protocol is, and a tiny server you can run

An AI app, such as Claude or ChatGPT, is most useful when it can reach your things: your files, your calendar, your company's database, your GitHub issues. Anthropic's launch post put the problem simply: before MCP, "every new data source requires its own custom implementation". Each app needed its own connecting code for each tool.

MCP fixes that with one shared set of rules, called a protocol. A protocol is an agreement about which messages two programs send and what each message means. USB-C is one plug shape that fits many devices; MCP is one way of connecting that fits many tools. If a tool speaks MCP, every app that speaks MCP can use it. The official docs put it this way: "Think of MCP like a USB-C port for AI applications."

Anthropic open-sourced MCP on 25 November 2024. The first version came with ready-made servers for Google Drive, Slack, GitHub, Git, Postgres (a database) and Puppeteer (a tool that controls a web browser). On 9 December 2025 Anthropic gave MCP to the Agentic AI Foundation, a group inside the Linux Foundation, the non-profit that looks after Linux and other open software. Anthropic, Block (the payments company) and OpenAI started the foundation together. Its post says the Linux Foundation will not decide MCP's technical direction. MCP's own maintainers, the people who look after the code, still make those choices.

The MCP docs name Claude, ChatGPT, Visual Studio Code, Cursor (a code editor) and MCPJam as apps that support it, and the foundation post adds Gemini and Microsoft Copilot. I did not check which protocol version each of these apps speaks today.

Read next: Claude Code mods: what a plugin can reach

MCP has three roles. The host is the AI app you use, for example Claude Desktop or VS Code. A server is a small program that offers tools or data, for example a GitHub server or a database server. A client is the part inside the host that talks to one server. If a host uses three servers, it holds three clients.

They talk in JSON-RPC 2.0. JSON is a simple text format for data. RPC means remote procedure call: asking another program to run something. So JSON-RPC is a way to send a request in JSON, such as "call this tool with these inputs", and get an answer that carries the same id number. Some messages are one-way notices, called notifications, which have no id. You will see JSON-RPC messages from my run below.

The messages travel over one of two transports, the road a message takes. With stdio, the host starts the server as a small program on your computer. They talk through its standard input and output, the way a terminal program reads what you type and prints text. With Streamable HTTP, the server usually runs on another computer (it can also run on yours, as in my demo below), and each message is a web request (an HTTP POST) to one address. The answer can come back in one piece or in several small parts, which is why it is called streamable.

A server can offer three kinds of things. The spec, short for specification (the official rule book), says who decides when each one is used. That matters for safety: if the model decides alone, a misleading tool description can steer it.

Tools are actions, such as "search my notes" or "create a GitHub issue". Tools are model-controlled: the AI model reads the list of tools and decides on its own when to call one. Resources are data, such as a file or a list of notes, each with an address like notes://all, similar to a web address. Resources are application-driven: the app decides when to read them and show them to the model. Prompts are ready-made messages, such as "summarise my notes". Prompts are user-controlled: you pick one, often from a menu or a command you type that starts with /.

Clients can offer features too. A server can ask the user for more information, which the spec calls elicitation. In the 2026-07-28 version the server does not send its own request for this. It answers "input required" with its questions, and the client sends the original request again with the user's answers. The changelog calls this Multi Round-Trip Requests. For anything sensitive, such as a password, the spec says the server must send the user to a web page outside the app instead of showing a form.

Three older features are now deprecated: roots (which folders a server may use), sampling (a server asking the app's model to write text) and logging. Deprecated means they are on their way out, and the earliest they can be removed is the first spec released on or after 28 July 2027. One part of logging, the request that sets the log level, is already gone.

MCP versions are named by date. The current one is 2026-07-28, released on 28 July 2026. The one before it was 2025-11-25.

The biggest change: MCP became stateless. In the old versions, a client first sent initialize, the server answered, the client sent initialized, and only then could real work start. That opening exchange is called a handshake. Over HTTP, the server could also hand out a session id, a label for a conversation it remembers. Every later request then had to reach a copy of the server that knew that session. The new version removes the handshake and the sessions. Every request now carries the protocol version and what the client can do, inside a part of the message called _meta.

Busy services run many copies of the same server, and a load balancer, a program that spreads requests over those copies, sends each request to one of them. The release post says that now "any request can land on any instance behind a plain round-robin load balancer": any copy can answer. One catch: this is only true of the protocol. If your server keeps its own data in memory, as my small demo below does, each copy has different data. Real servers keep shared data in a database. And a client that listens for change notices still holds one long connection open to one copy.

A new method, server/discover, lets a client ask "who are you, which versions do you speak, what can you do?". Servers must support it; clients may call it first, but they do not have to. For a server that needs to remember something between calls, the release post recommends handing the model a handle, an id that points to the saved information, inside a tool's answer. The model passes it back next time.

Mixing versions needs care. The spec's table says an old client cannot talk to a server that only speaks the new version ("Legacy clients have no fall-forward mechanism"). A new-only client cannot talk to an old-only server either. Software that speaks both, which the spec calls dual-era, works with both. The Python SDK I used is dual-era. The official test tool, the MCP Inspector, still starts in the old mode by default, which I learned when my first test used it (below).

Everything about the protocol comes from the 2026-07-28 specification, the MCP docs and blog, and Anthropic's launch post, all read on 6 October 2026. The main pages are linked below. The client list comes from those pages too; I did not test each app.

I ran one small server and three clients (the Python SDK, the Inspector's command line and its web page) on my Mac, plus curl over HTTP. Every terminal shown is a frame or text from a real recording. I did not connect the server to Claude or ChatGPT. I did not test OAuth, error answers, the Origin check or Multi Round-Trip Requests. I also did not test MCP Apps, the first official extension (an optional add-on to the protocol), which lets a server show small screens inside the chat.