What Is the Model Context Protocol and How Does It Work?

MCP architecture: hosts, clients and servers

This page is for people who build or evaluate MCP servers and clients. For the plain-English version, read What is MCP?. For servers and examples, read What is an MCP server?.

The MCP specification names three roles:

A host creates one client per server, so one chat can draw on several servers. A local stdio server typically serves a single client. A remote Streamable HTTP server typically serves many (architecture overview).

The protocol has two layers. The data layer is the JSON-RPC 2.0 message set: discovery, tools, resources, prompts and notifications. The transport layer is how those messages travel, including framing and authorization. The same messages run over either transport.

How does MCP work? The request lifecycle

Revision 2026-07-28 removed the initialize handshake and protocol-level sessions (changelog). Every request now carries its protocol version and the client's capabilities in a _meta field, and clients should identify themselves there too. Any server instance can answer any request.

A typical exchange:

1. Discover, if the client wants to. The client calls server/discover. Servers must implement it. Clients may skip it. The result lists supportedVersions and capabilities, and can carry usage instructions for the model.
2. List tools. tools/list returns each tool's name, description and JSON Schema for inputs. The result also carries two cache hints, ttlMs and cacheScope.
3. Call a tool. The model picks one and the client sends tools/call with arguments.
4. Go round again if the server needs input. The server returns resultType: "input_required" in place of a final result. The client collects the answer and retries the call.
5. Finish. The server returns resultType: "complete" with the tool's content.

The first tools/call in that diagram looks like this on the wire:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "issue_refund",
    "arguments": { "order": "1042" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

Multi round-trip requests (MRTR)

Earlier revisions let a server send its own requests to the client in the middle of a call. That needed a connection held open. The MRTR pattern replaces it:

• The server returns inputRequests, for example an elicitation/create request, and can add an opaque requestState string.
• The client gathers the answers and retries the original call with inputResponses and the unchanged requestState, under a new JSON-RPC id.
• The server must treat requestState as attacker-controlled input. If it affects authorization, resource access or business logic, the server must protect its integrity, for example with an HMAC.

MRTR is allowed on three requests only: tools/call, resources/read and prompts/get.

Version and capability negotiation

• Client capabilities travel on every request. A server must not send an input request the client did not declare. No elicitation/create, for example, unless the client lists elicitation.
• Server capabilities, such as tools, resources and prompts, come back from server/discover.
• Extensions are declared in an extensions field under prefixed names such as io.modelcontextprotocol/tasks.
• A request for a version the server does not support gets UnsupportedProtocolVersionError, code -32022, with the versions it does support. The client retries with one of them (versioning).

The session-based lifecycle before 2026-07-28

Revisions up to 2025-11-25 are stateful (2025-11-25 lifecycle). The client sends initialize, the two sides agree on a version and capabilities, and the client sends notifications/initialized before normal traffic starts.

The 2026-07-28 spec calls those revisions legacy, and an implementation that supports both eras dual-era. Over HTTP, a dual-era client sends a modern request first. If the reply is a 400 without a recognized modern error, it falls back to initialize. On stdio it probes with server/discover.

Legacy implementations are still in use. Claude's connector docs list the 2025-03-26, 2025-06-18 and 2025-11-25 authorization specs as the ones Claude follows (Claude docs). PopMCP's endpoint is session-based too, as the table further down shows.

MCP primitives

Tools are model-controlled: the model decides when to call one. A tool has an input schema, can declare an output schema and can carry annotations such as readOnlyHint. Clients must treat annotations as untrusted unless they come from a trusted server (tools).

Resources are data the application reads, each with a URI. Clients watch for changes through subscriptions/listen, which replaced resources/subscribe. Prompts are templates the user picks.

Elicitation lets a server ask the user for input. Form mode collects structured data. URL mode sends the user to a web page, and the spec requires it for passwords, API keys and payment details (elicitation).

Sampling let a server borrow the client's model, and roots told a server which folders it could use. Both are deprecated, along with protocol logging. The suggested replacements are calling an LLM provider's API directly, passing paths as tool parameters, and logging to stderr or OpenTelemetry.

Deprecated features still work. The feature lifecycle policy sets at least twelve months between deprecation and removal. Tasks, which arrived as an experimental core feature in 2025-11-25, moved out to an official extension.

MCP transports

The spec defines two standard transports:

Streamable HTTP in 2026-07-28:

• Every POST carries MCP-Protocol-Version and Mcp-Method headers. tools/call, resources/read and prompts/get also carry Mcp-Name. A gateway can route or rate-limit without parsing the body, and a server must reject a request whose headers and body disagree.
• The Mcp-Session-Id header, the standalone GET stream and SSE resumption are gone. A client that wants change notifications opens a subscriptions/listen stream.
• Servers must validate the Origin header to block DNS rebinding.
• The older HTTP+SSE transport from 2024-11-05 has been deprecated since 2025-03-26.

Remote vs local MCP servers covers what the two transports mean in practice.

MCP authorization

Authorization is optional in the spec. HTTP servers that use it should follow the authorization spec. stdio servers should take credentials from the environment.

• The MCP server is an OAuth 2.1 resource server. It must implement Protected Resource Metadata (RFC 9728) so a client can find its authorization server.
• Clients must use PKCE and must send the resource parameter (RFC 8707). Servers must check that a token was issued for them (security considerations).
• For client registration, Client ID Metadata Documents are the recommended route. Dynamic Client Registration is deprecated and kept for older authorization servers. Pre-registered clients still work.
• Clients must validate the iss parameter (RFC 9207) when the authorization response includes it.
• A server must not pass the client's token through to an upstream API. It uses a separate credential there.
• A 403 with insufficient_scope tells the client which scopes to request next.

MCP OAuth explained walks through the flow step by step.

For companies, the Enterprise-Managed Authorization extension lets an identity provider grant MCP server access centrally. The MCP blog names Okta, Claude and Visual Studio Code among its first supporters.

MCP specification version history

Governance, extensions and SDKs

Anthropic introduced MCP in November 2024. Since 9 December 2025 it has belonged to the Agentic AI Foundation, a directed fund under the Linux Foundation (MCP blog). What is MCP? has the history and the member list.

The project is run by its maintainers. David Soria Parra and Den Delimarsky signed the 2026-07-28 release post as lead maintainers. Spec changes go through SEPs, proposals filed as pull requests, and working groups triage the ones in their area.

Extensions are optional and negotiated between client and server. The official ones include Tasks for long-running work, MCP Apps for interactive UI inside a conversation, and Enterprise-Managed Authorization.

The roadmap published on 22 August 2026 lists five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise security, improved primitives, and SDK developer experience.

Official SDKs are ranked by tier:

On release day the TypeScript, Python, Go and C# SDKs supported 2026-07-28, and the Rust SDK supported it in beta, according to the release post.

Check what your client supports

Each client declares its own capabilities, so two clients can treat the same server differently.

Claude's connector docs say Claude supports tools, prompts and resources, but not resource subscriptions or sampling (Claude docs). ChatGPT's developer mode accepts SSE and streaming HTTP servers, and can register through Client ID Metadata Documents or Dynamic Client Registration (OpenAI).

If you are building a server

• Name tools with letters, digits, underscores, hyphens and dots, up to 128 characters. The spec recommends that set, and under 2026-07-28 the name also travels in the Mcp-Name header.
• Return tools/list in a stable order. The spec recommends it so clients and model prompt caches can reuse the list.
• Keep state in explicit handles. With no sessions, a server that needs state across calls returns a handle from one tool and accepts it as an argument on the next. It should check the caller's authorization against that handle every time.
• Decide whether to serve legacy clients. A dual-era server answers initialize for older clients and stateless requests for newer ones.

How PopMCP implements MCP

PopMCP is a hosted MCP server for business tools. Here is where it sits against the spec.

It is not an agent framework or a workflow builder, and it does not run jobs on a schedule.