MCP 2026-07-28: Stateless Core, Extensions, Tasks

The 2026-07-28 revision declares MCP "a stateless protocol: all the information needed to process a request is contained in the request itself" (the request travels as JSON-RPC, a small id-and-method envelope)[1]. In practice, every request has to describe itself; the spec enforces that with two rules. Servers "MUST NOT rely on prior requests over the same connection to establish context (e.g., capabilities, protocol version, client identity)", and state that has to span requests "MUST be referenced by an explicit identifier the client passes on each request"[1]. Two fields in the request's _meta object (MCP's per-request metadata) are therefore required on every request, io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities; a request missing either "is malformed" and gets -32602[1]. On HTTP the version goes in an MCP-Protocol-Version header; an Mcp-Method header is required on all requests and an Mcp-Name header on tools/call, resources/read and prompts/get, "so that intermediaries (load balancers, gateways, observability tooling) can route and inspect requests without parsing the body"[3].

There is no initialize: "There is no negotiation handshake. Every request carries its protocol version, and the server accepts or rejects each request independently"[4]. Sessions and Mcp-Session-Id are gone: a modern-only server receiving one should "ignore it, and do not mint or echo session IDs"[3]. The core spec does not promise that any instance can serve any request; SEP-2575 explains why the stateless design allows it in principle[5], and Study D shows where it breaks. To compare the two eras, use the toggle and step through each with Prev and Next; the legacy side is the 2025-11-25 specification, with the client sendingnotifications/initialized and the session being a MAY[6].

With no handshake, compatibility is checked per request. If the server does not implement the version a request names, it "MUST respond with an UnsupportedProtocolVersionError listing the versions it does support" (-32022, HTTP 400), and "The client SHOULD select a mutually supported version from the supported list and retry the request"[4]. If the request needs a client capability the client did not declare, the server "MUST return a MissingRequiredClientCapabilityError (-32021) whose data.requiredCapabilities lists the missing capabilities"[1]. Both are ordinary replies; the retry carries the fix.

server/discover exists for clients that want to know first: "a client is free to invoke any RPC inline and handle UnsupportedProtocolVersionError if its preferred version is not supported"[4]. The exception is stdio with a possibly legacy server, where "some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics", so on stdio a dual-era client "SHOULD probe with server/discover before sending any other request", and even a modern-only client is RECOMMENDED to probe[7]. Switch between the two errors and step through.

Extensions are "identified using a unique extension identifier with the format: {vendor-prefix}/{extension-name}"; four are official today: OAuth Client Credentials, Enterprise-Managed Authorization, MCP Apps (io.modelcontextprotocol/ui) and MCP Tasks (io.modelcontextprotocol/tasks)[9]. They are declared per request: "Clients advertise extension support in _meta["io.modelcontextprotocol/clientCapabilities"] within each request" and "Servers advertise extension support in the server/discover response"[9]. "Extensions are always disabled by default and require explicit opt-in from the developer."[9]

When one side lacks an extension, the normative rule is: "If one party supports an extension but the other does not, the supporting party MUST either revert to core protocol behavior or reject the request with an appropriate error"[4]. For Tasks both outcomes are spelled out. A server "MUST NOT return CreateTaskResult to a client that did not include the extension capability on its request". A server that cannot serve the request without a task "MUST return an error with the code -32021"[11]. Declaring does not force the server's hand either: it "MAY return CreateTaskResult ... at its own discretion and on a per-request basis. The server is the sole decider"[11]. Switch between a client that declares Tasks and one that omits it.

The Tasks extension lets a server "respond to a tools/call request with an asynchronous task handle instead of a final result, allowing the client to retrieve the eventual result by polling"; in this version "The following methods currently support task-augmented execution: tools/call"[11]. Durability is a MUST at creation: "A server MUST NOT return CreateTaskResult until the task is durably created - that is, until a tasks/get for the returned taskId would resolve"[11]. Retention is not: clients "MAY treat the TTL as a backstop", servers "MAY mark a task as failed at any point after the TTL elapses, and subsequently delete it", and "It is compliant behavior for a server to return an error stating the task cannot be found if it has purged an expired task"[11].

Two facts cut against the "any instance" reading of the core. Polling requests carry a routing key: "the client MUST set the Mcp-Name header to the value of params.taskId. This allows transport intermediaries and load balancers to route subsequent requests for the same task to the server instance holding its state, which is typically required for correctness"[11]. And cancellation is "cooperative: The request signals intent, and the server decides whether and when to honor it ... Eventual transition to cancelled is not guaranteed"[11]. Step through the happy path, then the cancel path.

The server can no longer open its own request to the client mid-call (there is no held-open stream to carry it): "Servers MUST send server-to-client requests (such as roots/list, sampling/createMessage, or elicitation/create) using the MRTR pattern. The previous pattern of server-initiated requests is no longer supported. This is a breaking change."[12] The pattern is four steps: the client sends a request; the server "responds requesting more information"; the client gathers it and "retries the original request including the additional requested information"; the server answers with the final result[12]. Multi round-trip requests (MRTR) exist so that servers can ask "without requiring a shared storage layer across server instances or requiring stateful load balancing"[12].

The rules that make it safe are on both sides. requestState "is an opaque string meaningful only to the server", and the client "MUST echo back the exact value ... MUST NOT inspect, parse, modify, or make any assumptions about" it[12]. The server, in turn, "MUST treat requestState as an attacker-controlled input. If requestState influences authorization, resource access, or business logic, servers MUST protect its integrity (e.g. HMAC or AEAD)"[12]. The retry is a new request: "The JSON-RPC id MUST be different between the initial request and the retry, as they are independent requests"[12]. Step through one round trip.

A tool points at a UI resource through _meta.ui.resourceUri; the resource's URI "MUST start with ui:// scheme", its mime type "MUST be text/html;profile=mcp-app", and the content "MUST be valid HTML5 document"[13]. The host fetches it with resources/read ("Host MAY prefetch and cache UI resource content") and renders it where "All View content MUST be rendered in sandboxed iframes with restricted permissions"; a web host "MUST wrap the View and communicate with it through an intermediate Sandbox proxy" on a different origin, over the browser postMessage channel[13].

Inside the sandbox the app is a client of its host: "Conceptually, UI iframes act as MCP clients, connecting to the host via a postMessage transport", and the dialect keeps a handshake the core protocol dropped, ui/initialize and ui/notifications/initialized; "The Host MUST NOT send any request or notification to the View before it receives an initialized notification"[13]. Once initialized, the host pushes tool data: it "MUST send" ui/notifications/tool-input and "MUST send" ui/notifications/tool-result "when tool execution completes (if the View is displayed during tool execution)". The app's own tools/call messages go back through the host, which "MAY forward" them or "MAY decide to block some messages or subject them to further user approval"[13]. Step through a render and one round trip.

Four actors: the MCP client, the MCP server (the resource server), the Resource Authorization Server "that issues access tokens for the MCP Server", and the enterprise IdP "used for single sign-on"[14]. Three normative steps: "1. Single Sign-On to the MCP Client via OpenID Connect or SAML ... 2. Token Exchange (RFC8693) 3. JWT Authorization Grant (RFC7523)"[14]. The policy decision sits in step 2: "The IdP evaluates administrator-defined policies for the token exchange request and determines if the MCP Client should be granted access to act on behalf of the user for the target MCP Server and scopes"; if not, the client gets an OAuth token error and never holds an ID-JAG[14].

What the profile guarantees about the token: the ID-JAG "is a JWT issued and signed by the IdP" and the access token the resource authorization server issues "MUST be audience-restricted to the MCP Server identified by the resource claim in the ID-JAG"[14]. What it does not guarantee is control of traffic: "The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual MCP traffic"[14]. The informative overview's "taking effect immediately across all MCP clients" describes issuance; the normative profile says only that the IdP's visibility "does not extend to the actual MCP traffic", and the example access token carries expires_in of 86400 seconds[15][14]. Step through the three exchanges.