Why must an MCP client echo requestState verbatim and never inspect it?

## What requestState is for MCP revision 2026-07-28 is explicitly a stateless protocol — every request is self-contained, and a server MUST NOT rely on prior requests over the same connection to establish context. That rule creates a problem for the Multi Round-Trip Request pattern: a server that pauses a `tools/call` to ask for input has, by design, no place to keep "where I was". `requestState` is the answer. It is a value the server puts in the `InputRequiredResult` and the client hands straight back on the retry, and it is the only thing linking the two rounds. ## Why the spec makes it opaque **Freedom of representation.** Because no client may look inside, a server can choose whatever encoding suits it: a serialized continuation, a compressed and base64-encoded struct, an encrypted envelope, a signed token, or simply a random key into a short-lived cache. It can change that choice in the next deploy and no client needs updating. Had the shape been specified, it would have become a public contract. **Integrity.** The blob encodes decisions the server already made — which tool, which arguments were validated, which step of a multi-round flow is next, sometimes an authorization context. If a client could edit it, it could resume at a step it never earned, replay a half-finished flow, or fabricate a state that skips a confirmation the server intended to require. Servers therefore commonly authenticate the blob (MAC or encryption) and validate it on receipt rather than trusting its contents; a tampered or expired value should be rejected with an invalid-params error, not silently repaired. **Portability across nodes.** A remote MCP server sits behind a load balancer, and since 2026-07-28 removed protocol sessions and the `Mcp-Session-Id` header, there is no affinity to pin the retry to the node that produced the interim result. A self-contained `requestState` means any node can resume. If the server instead stores continuation server-side and puts only a key in the blob, it has quietly reintroduced shared state — workable with a shared store, but a design choice to make consciously. ## The client's obligations 1. Copy it exactly. Do not parse it as JSON, do not re-encode it, do not trim it, do not normalize whitespace or case. 2. Do not persist assumptions about it. It is not a request id, not a session id, not a resumption token you may reuse for a different call. 3. Echo the **latest** one. Each round produces its own `requestState`; a multi-round flow must send the value from the most recent `InputRequiredResult`. 4. Do not log it carelessly. It may embed authorization context or user data, so treat it as sensitive material rather than a debug string. ## Server-side design guidance - **Bound its lifetime.** Put an expiry inside the blob (or on the referenced record) and reject stale ones. A client may retry hours later — or never. - **Bound its size.** It travels on every subsequent round. Large continuations belong behind a key, not inline. - **Do not treat possession as authentication.** MCP 2026-07-28 replaced the old "session hijacking" guidance with **State Handle Hijacking**: holding a handle MUST NOT be treated as proof of identity. The retry must be authorized on its own credentials, and the server should check that the caller is the same principal the blob was minted for. - **Assume abandonment.** A client that declines the requested input simply never retries, so nothing may be left holding a lock, an open transaction, or a reserved resource. ## Analogy in the wider API world The pattern is the same one behind opaque pagination cursors, OAuth `state`, and continuation tokens: the producer defines the meaning, the consumer promises only to give it back unchanged. Naming that family in an interview shows you understand *why* the field is typed as an opaque string rather than a structured object.