Stateless MCP requests: _meta, resultType and explicit handles

The 2026-07-28 Model Context Protocol (MCP) revision requires every request to carry its own context in `_meta`, including the protocol version and the client's capabilities, so servers can no longer rely on a handshake, session, or connection identity, according to part 5 of a series on the specification. Under the revision, servers return only what the current request declared it can handle and answer `-32021` when an operation needs an undeclared capability, while every result names its kind in `resultType` as `complete`, `input_required`, or `task`, and clients MUST treat results from earlier-protocol servers that omit `resultType` as `complete`. State that outlives a single call lives in explicit opaque handles that creation tools return and later calls pass back, with the server checking the caller and expiry on every call.

Stateless MCP requests: meta, resultType and explicit handles If I had to keep one rule of the 2026-07-28 revision in mind while writing a server, it would be this one: every request carries everything the server needs to process it. You can’t rely on an earlier handshake, on a session, or on knowing which connection a request came from. That rule decides how you read a request, what you send back, and where you keep anything that has to last longer than a single call. This is part 5 of my series on what a Model Context Protocol MCP server does under the 2026-07-28 specification, after server instructions in part 4 https://pournasserian.com/writing/mcp-2026-server-instructions . The facts are as I read them in October 2026. In brief 1. Every request carries its own context in meta . The protocol version and the client’s capabilities are required on each request, so a server reads them from the request in hand. 2. Capabilities can change from one request to the next. A server returns only what this request said it can handle, and answers -32021 when the operation needs a capability the request didn’t declare. 3. Every result names its kind in resultType : complete , input required or task . A client MUST treat a result from an earlier-protocol server that omits it as complete . 4. State across calls lives in explicit handles. A creation tool returns an opaque id, later calls pass it back, and the server checks the caller and the expiry every time. The request envelope Every request MUST carry two meta fields: the protocol version and the client’s capabilities. The specification’s examples often leave them out to stay short, but real traffic always carries them. Here is a tools/call with its envelope: { "jsonrpc": "2.0", "id": 42, "method": "tools/call", "params": { "name": "search docs", "arguments": { "query": "rotate storage keys" }, " meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientCapabilities": { "elicitation": { "form": {}, "url": {} }, "extensions": { "io.modelcontextprotocol/ui": { "mimeTypes": "text/html;profile=mcp-app" } } }, "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" }, "progressToken": "req-42", "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01" } } } These are the keys you’ll meet: | meta key | Direction | Status | Purpose | |---|---|---|---| | io.modelcontextprotocol/protocolVersion | Request | MUST | Protocol revision for this request | | io.modelcontextprotocol/clientCapabilities | Request | MUST | What the client supports for this request, extensions included | | io.modelcontextprotocol/clientInfo | Request | SHOULD | Client name and version | | io.modelcontextprotocol/logLevel | Request | Optional, part of the deprecated Logging feature | Opt in to notifications/message for this request only | | progressToken | Request | Optional | Ask for progress notifications | | traceparent , tracestate , baggage | Request | Convention, from Specification Enhancement Proposal SEP 414 https://modelcontextprotocol.io/seps/414-request-meta | World Wide Web Consortium W3C trace context | | io.modelcontextprotocol/serverInfo | Result | SHOULD | Server name and version | | io.modelcontextprotocol/subscriptionId | Notification | MUST on listen streams | Ties a notification to its subscriptions/listen request | Apart from progressToken and the trace-context keys, meta keys carry a prefix: io.modelcontextprotocol/ for the protocol’s own, and a vendor’s own for a vendor key such as anthropic/alwaysLoad , so the two don’t collide. traceparent , tracestate and baggage are left without one on purpose, so they stay compatible with OpenTelemetry conventions. Part 3 https://pournasserian.com/writing/mcp-2026-server-discover covers clientInfo , serverInfo and what happens when a request names a version the server can’t serve. Capabilities are per request Because capabilities arrive with each request, two requests from the same client can declare different ones: one may declare the Tasks extension https://modelcontextprotocol.io/extensions/tasks/overview and the next may not. The specification’s overview https://modelcontextprotocol.io/specification/2026-07-28/basic/index puts it plainly: a server MUST NOT rely on capabilities the client has not declared. So decide what to return from the request in hand: - Never return a task handle to a request that didn’t declare the Tasks extension. - Never put an elicitation into inputRequests what an input required result asks for, below unless that request declared elicitation . - If the operation can’t be done without a capability the request didn’t declare, the server MUST return a MissingRequiredClientCapabilityError -32021 whose data.requiredCapabilities lists what is missing. On HTTP, the response status MUST be 400 Bad Request. The specification only asks you to decide per request. My advice goes further: build one request-context object at the start of each request, holding the version, the capabilities, the client info, the caller’s identity and the trace context, and pass it explicitly to every handler. Never cache a capability decision in a static or per-connection field. Caching it per connection is a common bug when porting a 2025-era server to 2026-07-28: it works in local tests with one client and breaks in production behind a load balancer. What comes back: resultType Every result carries a required resultType , which tells the client what to do next: | resultType | Meaning | Defined by | |---|---|---| | "complete" | A normal, final result | Core | | "input required" | The server needs more input; the client must retry with inputResponses | Core, Multi Round-Trip Requests MRTR https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr | | "task" | Work continues asynchronously; poll tasks/get | Tasks extension | Clients MUST treat a result from an earlier-protocol server that omits the field as "complete" . Put together, a client branches like this: input required is how a stateless server asks for more, through MRTR. task comes from the Tasks extension, so by the rule above only a request that declared that extension may receive one. State without sessions: explicit handles The protocol has no notion of a state handle. To the wire, a handle is just a string returned in one tool result and passed as an argument to the next. A server that needs state across calls a shopping cart, an open browser context, a database transaction returns a handle from a creation tool and accepts it on later calls. Part 2 https://pournasserian.com/writing/mcp-2026-what-changed explains why sessions went away; this is what takes their place. Here is the pattern with two server instances and one shared store, where each handle is kept with its owner and a time to live TTL : Any instance can serve any request, and the only shared dependency is whatever store holds the explicit state. That fits serverless platforms, autoscaling and rolling deployments well. The specification’s guidance on designing handles: - Authorization. On an authenticated server, a handle only names the state; holding it grants nothing, so check the caller’s authorization against the handle on every call. On an unauthenticated server the handle is necessarily a bearer token, so give it enough entropy for example, a version 4 universally unique identifier, or UUIDv4 and a bounded lifetime. - Opacity. A handle that encodes internal structure invites parsing or guessing. - Lifetime. State the retention policy in the creation tool’s description, for example “baskets expire after 24 hours of inactivity”. - Expiry errors. A call with an expired or unknown handle returns a tool execution error that says so, so the model can recover by creating a new handle. In Python Here is the handle pattern with the official Python SDK, mcp 2.3.0; the comments mark the two stand-ins, the store and the caller. python import secrets import time from mcp.server import MCPServer from mcp.server.mcpserver.exceptions import ToolError mcp = MCPServer "shop" A dict stands in for the shared store that every server instance reads. baskets: dict str, dict = {} LIFETIME = 24 60 60 seconds of inactivity before a basket expires def current caller - str: Stub: an authenticated server takes the caller from the validated access token. return "user-123" @mcp.tool def create basket - dict str, str : """Create a shopping basket. Baskets expire after 24 hours of inactivity.""" basket id = "bsk " + secrets.token urlsafe 16 opaque, random, hard to guess baskets basket id = {"owner": current caller , "expires": time.time + LIFETIME, "items": } return {"basket id": basket id} @mcp.tool def add item basket id: str, sku: str - str: """Add an item to a basket made by create basket.""" basket = baskets.get basket id Someone else's basket gets the same answer as one that never existed. if basket is None or basket "owner" = current caller : raise ToolError "Unknown basket. Call create basket to start a new one." if basket "expires" < time.time : del baskets basket id raise ToolError "Basket expired. Call create basket to start a new one." basket "items" .append sku basket "expires" = time.time + LIFETIME return f"Added {sku}. The basket holds {len basket 'items' } item s ." Two choices in it are mine, not the specification’s: the expiry moves forward on every use, to match “24 hours of inactivity”, and a basket that belongs to someone else gets the same answer as one that doesn’t exist. Raising ToolError gives a tool execution error: the result has isError set, and its text is your message after a prefix the SDK adds. The model reads it and can call create basket again. The SDK’s in-memory client shows a successful call and an unknown handle: python import anyio from mcp import Client async def main : async with Client mcp as client: created = await client.call tool "create basket", {} basket id = created.structured content "basket id" added = await client.call tool "add item", {"basket id": basket id, "sku": "sku-42"} print added.content 0 .text unknown = await client.call tool "add item", {"basket id": "bsk nope", "sku": "sku-42"} print unknown.is error, unknown.content 0 .text anyio.run main Added sku-42. The basket holds 1 item s . True Error executing tool add item: Unknown basket. Call create basket to start a new one. Method and caveats - Built from my guide to MCP servers in 2026 its chapter on stateless requests, and the handle pattern from its design-patterns chapter , written against the 2026-07-28 specification as of October 2026. - The Python sample was run against mcp 2.3.0 on 8 October 2026 with the SDK’s in-memory client; the output shown is what it printed. - Where the specification is more precise than my notes the -32021 error lists the missing capabilities in data.requiredCapabilities , and on HTTP it comes with status 400 , this article follows the specification. Series What an MCP server actually does in 2026 Part 5 of 35 1. What an MCP server does in 2026: much more than a list of tools https://pournasserian.com/writing/mcp-2026-what-a-server-does 2. MCP goes stateless: what changed in the 2026-07-28 specification https://pournasserian.com/writing/mcp-2026-what-changed 3. server/discover: the one method every MCP server must implement https://pournasserian.com/writing/mcp-2026-server-discover 4. Server instructions: the paragraph every model reads first https://pournasserian.com/writing/mcp-2026-server-instructions 5. Stateless MCP requests: meta, resultType and explicit handles 6. Caching hints and pagination in MCP https://pournasserian.com/writing/mcp-2026-caching-and-pagination 7. MCP transports in 2026: stdio and Streamable HTTP https://pournasserian.com/writing/mcp-2026-transports