Model Context Protocol

The vocabulary trips people up more than the protocol does. A host is the application the user is actually using. It owns one client per connection, and each client talks to one server.

Host      the application the user is in (an IDE, a chat client)
  └─ Client    one connector per server, owned by the host
       └─ Server   a process or an endpoint offering tools, resources, prompts

A server offers three things to the model: tools it can call, resources it can read, and prompts the user can invoke. A client can offer things back, such as elicitation, where the server asks the user a question mid-call.

This revision is a rewrite of the connection model, not a point release. Sessions are gone. The initialize handshake is gone. Every request now carries its own protocol version, client identity and capabilities, and the server answers each one on its own terms.

That makes MCP servers ordinary stateless services, which is the whole point: they can sit behind a load balancer without sticky routing, and a crashed process loses nothing but in-flight work. It also means anything you read about MCP that opens with a handshake is describing the era that ended. The versioning page has the compatibility matrix.

A tool definition in MCP is a name, a description and a JSON Schema. That is exactly the shape model providers already accepted for function calling, so MCP did not ask anyone to invent a new idea. It standardised the plumbing around an idea that already worked, which is the only kind of protocol that ever spreads.

The consequence is worth stating plainly: MCP does not make a model better at using tools. It makes a tool reusable across hosts. If you are building one agent against one set of functions you control, you may not need it at all.

The from-scratch build lives in a field note, MCP tool calling without the SDK, which writes a whole stdio server with no dependencies. These pages pick up after it.

• MCP Transports: stdio and Streamable HTTP

  The two transports MCP defines, how each frames messages, and what the 2026-07-28 revision removed from the HTTP one: sessions, the GET stream, and resumability.

• Building an MCP Server

  What a server owes a client beyond tools: discovery, resources and prompts, cacheable lists, error conventions, and shutdown that does not need a kill signal.

• Consuming an MCP Server You Did Not Write

  Version negotiation without a handshake, detecting whether a server is modern or legacy, timeouts, cancellation, and the trust boundary you cross by connecting.

• MCP Security: the Threat Model

  Every model-facing string in MCP is an injection surface, a stdio server is a local process with your privileges, and the protocol enforces none of it. What that means in practice.

• MCP Versioning: Modern and Legacy Eras

  The 2026-07-28 revision split MCP into two eras. What moved, which combinations of client and server actually work, and how to keep a page about this protocol from going stale.

Every page here states the protocol revision it describes. This protocol has already deleted a handshake, a session header, a streaming endpoint and a resumption mechanism. An undated page about MCP is a trap, including ours, so we date them.