What MCP is, in one diagram

The short answer

MCP is a protocol that lets an AI application use tools and data it did not ship with. You write a server once, and any application that speaks MCP can use it: Claude Code, Codex, Cursor, Cherry Studio and others.

Three roles

Role	What it is	Example
Host	The application the person uses. It runs the model and decides what the model may do.	Claude Desktop, Codex, Cursor
Client	A connector inside the host. One client talks to exactly one server.	The part of Codex that starts your server and sends it requests
Server	Your program. It offers tools, data and prompt templates over MCP.	A server that queries your database

The host never talks to a server directly. It creates one client per server, and the client handles the protocol.

What a server offers

Primitive	What it is	Who decides to use it
Tools	Functions the model can call, such as add(a, b) or search_orders(query)	The model, within limits the host sets
Resources	Data the host can read, addressed by URI, such as file:///… or db://orders/42	The host application
Prompts	Reusable prompt templates with arguments	The person, usually from a menu or slash command

Most servers start with tools. Our first server has one tool and nothing else.

How messages travel

Every message is JSON-RPC 2.0. MCP defines two standard transports:

• stdio: the client starts the server as a child process and exchanges messages over its standard input and output, one JSON object per line. Use it for servers that run on the same machine as the host. Because stdout carries the protocol, a server must write its own logs to stderr.
• Streamable HTTP: the server is a web endpoint, usually /mcp, and each request is an HTTP POST. Use it for remote or shared servers.

An older third transport, HTTP+SSE, is deprecated. See From HTTP+SSE to Streamable HTTP.

What 2026-07-28 changed

Until 2025-11-25, a client opened every connection with an initialize handshake, and HTTP servers tracked a session with an Mcp-Session-Id header. The 2026-07-28 specification removed both:

• No handshake. Each request carries the protocol version and the client’s capabilities in its _meta field.
• No protocol sessions. Any request can go to any server instance. A server that needs state across calls hands out its own IDs as ordinary tool arguments.
• server/discover. A client that wants to know what a server supports up front asks it with this method.

You can see the result with nothing but curl. Against our Python example running over Streamable HTTP, this single request lists the tools without any setup:

curl -s -X POST http://127.0.0.1:8931/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{
        "io.modelcontextprotocol/protocolVersion":"2026-07-28",
        "io.modelcontextprotocol/clientCapabilities":{}}}}'

The response includes "resultType":"complete", a ttlMs cache hint and cacheScope, all new in 2026-07-28.

If you are following an older tutorial

Code that calls initialize, reads Mcp-Session-Id, or imports SSEServerTransport was written for an earlier version. Servers built with current SDKs still accept those older clients, but new code should follow the 2026-07-28 shape. Start with the migration guides.

Old clients still work

The current TypeScript, Python and Go SDKs serve both generations from the same server code. In our tests a default TypeScript client still connected with the 2025-11-25 handshake, and the same server answered 2026-07-28 clients as well. The Java SDK 2.1.0 only speaks 2025-11-25 so far. The details are in the first server guide.

Next

• Write your first server in TypeScript
• Test any server with the MCP Inspector