# Stateless MCP requests: _meta, resultType and explicit handles

> Source: <https://pournasserian.com/writing/mcp-2026-stateless-requests>
> Published: 2026-10-09 00:00:00+00:00

# 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)