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. 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 ortask . A client MUST treat a result from an earlier-protocol server that omits it ascomplete .
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:

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 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 and the next may not. The specification’s overview 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 aninput_required result asks for, below) unless that request declaredelicitation .
• If the operation can’t be done without a capability the request didn’t declare, the server MUST return a MissingRequiredClientCapabilityError (-32021 ) whosedata.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:

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 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.

import secrets
import time

from mcp.server import MCPServer
from mcp.server.mcpserver.exceptions import ToolError

mcp = MCPServer("shop")

baskets: dict[str, dict] = {}
LIFETIME = 24 * 60 * 60  # seconds of inactivity before a basket expires

def current_caller() -> str:
    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)
    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:

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 indata.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
2. MCP goes stateless: what changed in the 2026-07-28 specification
3. server/discover: the one method every MCP server must implement
4. Server instructions: the paragraph every model reads first
5. Stateless MCP requests: _meta, resultType and explicit handles
6. Caching hints and pagination in MCP
7. MCP transports in 2026: stdio and Streamable HTTP