The anatomy of MCP: hosts, servers, messages and extensions

Most explanations of the Model Context Protocol stop at “USB-C for AI”. That is fine for a slide. It is not enough when you are deciding whether to build an MCP server for your document system, which client to standardize on, or where a gateway should sit. For those decisions you need to know what the protocol is actually made of.

This piece takes MCP apart as of the specification dated July 28, 2026. That release changed the protocol more than any since launch: the connection handshake is gone, servers no longer send requests to clients, and several features moved out of the core into extensions. If your mental model dates from 2025, parts of it are now wrong.

Three roles

A host is the application the person works in: Claude, an IDE, or an agent you built. The host owns the model, the user interface and the decision about what the user is allowed to approve.

Inside the host, an MCP client manages one connection to one server. A host that talks to five servers runs five clients. Keeping them separate matters, because each connection has its own authorization and its own set of tools, and nothing in the protocol lets one server see another’s traffic.

A server exposes capabilities to the client. It might be a small local process wrapping your file system, or a hosted service in front of a CRM. Servers are where your data lives from the protocol’s point of view, and they are also where most of your engineering and security effort will go.

The wire format

Every MCP message is JSON-RPC 2.0. A request has an id, a method and params, and gets exactly one response with the same id. A notification has no id and gets no response. That is the whole envelope.

Since July 2026 each request also describes itself. The protocol version and the client’s capabilities travel in a _meta object on every call, instead of being agreed once at connection time. It makes each message slightly larger and the system much simpler to run.

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "search_matters",
    "arguments": { "query": "Bluewater Logistics" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": { "io.modelcontextprotocol/tasks": {} }
      }
    }
  }
}

Two transports

With stdio, the host starts the server as a child process and the two exchange messages over standard input and output. There is no network, no port and no OAuth. The server simply runs with whatever access the user’s account has, which is convenient for a developer and a real consideration for a security team.

Streamable HTTP is for remote servers. The client POSTs JSON-RPC messages to a single endpoint, and the server can answer with plain JSON or stream its reply. Two details from the 2026 release are worth knowing. Every request must carry Mcp-Method and Mcp-Name headers, so a load balancer, WAF or gateway can see that this is a tools/call to search_matters without parsing the body. And with the Mcp-Session-Id header gone, any server instance can answer any request, which means ordinary round-robin load balancing works and you do not need sticky sessions or a shared session store.

The older HTTP+SSE transport, with its separate event stream endpoint, is deprecated. It still works for at least a year, but there is no reason to build on it now.

Discovery without a handshake

Until 2026, every connection began with initialize, where client and server agreed on a version and exchanged capabilities. That exchange is retired. Servers must now implement server/discover, which returns the protocol versions, capabilities, extensions and identity the server supports. Clients may call it up front, but they do not have to; a client that already knows what it needs can go straight to tools/list or tools/call.

What a server offers

Servers expose three kinds of thing, and the distinction is about who decides when each is used.

• Tools are model-controlled. Each has a name, a description, a JSON Schema for its inputs and optional annotations. The model reads the descriptions and decides when to call tools/call. This is where actions happen, and where most risk sits.
• Resources are application-controlled. They are pieces of data identified by URI, read with resources/read, such as a matter file, a policy document or a database row. The host decides which ones to put in front of the model.
• Prompts are user-controlled. They are templates a server offers, such as “summarize this matter for a partner”, that a person picks from a menu.

In practice, tools get most of the attention because they are what turn a chat assistant into an agent. Resources are underused. If the model only needs to read a document, exposing it as a resource keeps control with the host rather than the model, which is often what a compliance team wants.

When the server needs something back

Older versions let a server send requests to the client in the middle of a call: ask the user a question (elicitation), ask the host’s model to generate text (sampling), or ask which folders it may work in (roots). All of those relied on a connection held open in both directions, which a stateless protocol cannot offer.

The 2026 specification replaces them with multi round-trip requests. When a server needs input, it does not call the client. It finishes the call with a result that says input is required, describes what it needs, and includes an opaque requestState value. The client collects the answer, typically by asking the user, and sends the original request again with the answer and the same requestState. The server picks up where it left off without holding any memory between the two calls.

Sampling, roots and the protocol’s logging feature are deprecated along the way. Servers that need a model of their own are expected to call a model provider directly.

{
  "jsonrpc": "2.0",
  "id": 43,
  "result": {
    "resultType": "input_required",
    "requestState": "eyJzdGVwIjoiY29uZmlybSJ9...",
    "input": {
      "message": "File this note on matter 2291 (Acme internal investigation)?",
      "schema": {
        "type": "object",
        "properties": { "confirm": { "type": "boolean" } },
        "required": ["confirm"]
      }
    }
  }
}

Long-running work: the Tasks extension

Some calls take minutes, such as running a conflict search across a large client database or generating a due-diligence pack. Tasks, which were experimental inside the core, became the extension io.modelcontextprotocol/tasks in July 2026. A client that supports it says so in its capabilities. The server then decides whether a given tools/call should run as a task, and if so answers with a task handle instead of a result. The client polls with tasks/get, sends further input with tasks/update and can stop the work with tasks/cancel.

Extensions

Extensions are how MCP grows without bloating the core. Each has a reverse-DNS identifier, is off by default, and only applies when both client and server declare support. A server must still behave sensibly for clients that ignore it. Three are worth knowing now.

• MCP Apps (io.modelcontextprotocol/ui), the first official extension, released in January 2026. A server can ship an interactive HTML interface as a ui:// resource, which supporting hosts render in a sandboxed iframe next to the conversation.
• Tasks (io.modelcontextprotocol/tasks), described above.
• Enterprise-Managed Authorization, stable since June 2026, which lets an organization’s identity provider decide which servers each employee may use. Our MCP governance article walks through the token flow.

Authorization, in one paragraph

Local stdio servers have no protocol-level authorization at all. Remote servers use OAuth 2.1: the server is a resource server that publishes Protected Resource Metadata telling clients which authorization server to use, clients use PKCE and name the target server with the resource parameter so each token is valid for one server only, and a server may never forward the token it received to another API. The July 2026 release added issuer validation, bound client credentials to the authorization server that issued them, and deprecated Dynamic Client Registration in favor of Client ID Metadata Documents. The governance article covers this in detail.

The registry

The official MCP Registry at registry.modelcontextprotocol.io launched in preview in September 2025 and, as of November 2026, is still a preview with its API at v0.1. It does not host code. It stores metadata in a server.json file: a reverse-DNS name, a version, and where to get the server, either a package on npm, PyPI or a container registry, or a remote URL.

The registry verifies namespaces. To publish under io.github.your-account you sign in with GitHub, and to publish under your own domain you prove control with a DNS or HTTP check. Be clear about what that proves. It tells you who published the metadata. It says nothing about who operates a remote endpoint the metadata points to, or whether the code is safe. For a regulated firm the registry is a useful starting point for discovery, and the registry software can be self-hosted as a private catalog. It is not an approval process.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example-firm/matters",
  "description": "Search and summarize open matters.",
  "version": "2.4.1",
  "remotes": [
    { "type": "streamable-http", "url": "https://mcp.example-firm.com/mcp" }
  ]
}

What this means if you are building

A few things follow from the anatomy that are easy to miss on a first read of the specification.

Design remote servers to be stateless from day one. The protocol no longer gives you a session, so anything a server needs to remember across a multi-step interaction belongs in requestState, a task, or your own data store, not in process memory.

Decide early which of your data is a resource and which actions are tools. Moving a read-only lookup from a tool to a resource changes who controls it, and that is a governance decision as much as a technical one.

Do not build new work on sampling, roots, the logging feature, HTTP+SSE or Dynamic Client Registration. They all still work, and they are all on a deprecation clock of at least twelve months.

Put the gateway in the drawing before you put it in production. The new headers make it cheap to run, and most of the controls in our MCP governance guide assume it is there.

Common questions