Why must an MCP server re-read capabilities from every request rather than caching them?

## The rule Revision 2026-07-28 removed the `initialize` handshake and, with it, the idea that capabilities are established once and then remembered. The replacement rule is stated as a MUST NOT: servers must not infer capabilities from prior requests. The capability object arrives in `params._meta` under `io.modelcontextprotocol/clientCapabilities` on every single request, and the server evaluates the request in front of it using only that object. The specification's framing is worth quoting because candidates often soften it: "MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities," and "an open connection, such as a STDIO process, is not a conversation or session." The stdio clause exists precisely because a subprocess *feels* like a session — one long-lived pipe, one peer at the other end — and implementers are tempted to hang state off it. ## Why caching is wrong, not merely unnecessary ### The declaration can legitimately change Capabilities are a property of the request, not of the client as an organism. The same client may declare interactive capabilities on a call it is making on behalf of a user sitting at a screen, and declare none at all on a scheduled background call where nobody can answer a question. A server that remembered the first declaration would happily start an interaction the second call cannot complete. Nothing in the protocol forbids the variation; the client is behaving correctly and the caching server is wrong. ### The next request may land elsewhere A remote MCP deployment is ordinary HTTP infrastructure. Requests are POSTs, and any node can serve any of them. A capability set cached in one process's memory is invisible to its peers, so a cache-dependent server works in single-process testing and fails intermittently in production — the worst possible failure signature. ### There is nothing to hang the cache on Protocol-level sessions and their identifying header were removed in 2026-07-28, so a server has no protocol-blessed key under which to file remembered capabilities. Keying off a transport connection re-introduces exactly the connection-as-session assumption the revision deleted, and keying off self-reported client identity is worse, because that identity is untrusted. ## What a correct server does instead Validate `_meta` in one place, before dispatch. Parse the capability object into a value that travels with the request through your handler chain — a request-scoped context object, not a field on a connection or a process-wide map. Every decision that depends on what the client can do reads from that value. When the current request's declaration is insufficient for the work, the server returns `-32021` `MissingRequiredClientCapabilityError` with `data.requiredCapabilities` naming what was needed. It does not consult history, does not assume the client "probably still" supports what it declared a minute ago, and does not degrade silently. If the client does support the capability, it re-issues the call with the declaration corrected. Equally, a server must not treat an absent `clientCapabilities` key as an empty object or as a repeat of the last one. Absence is invalid params: `-32602`, delivered with HTTP 400 on Streamable HTTP. ## The client side of the same rule Clients carry a matching obligation: build `_meta` for every outgoing request rather than once at start-up. In practice the reliable pattern is to stamp it in the transport layer so that no individual call site can forget, and to derive the capability object from the *situation* — is a human present, is this interactive, is this a batch job — rather than from a single constant. ## What this costs and what it buys The cost is real: a few hundred bytes of metadata on every call, and a small amount of validation work per request. The payoff is that a server needs no affinity, no session store, no expiry sweeper, and no reconnect logic to rebuild negotiated state. A process can be restarted mid-flight and the next request is served normally. For a protocol whose servers are frequently small, short-lived, and deployed behind ordinary load balancers, that trade is deliberate. ## How this shows up in interviews The question separates candidates who read the current specification from those recalling the handshake era. Weak answers say caching is "an optimisation" or "fine within one connection". A strong answer names the MUST NOT, gives at least one concrete way a cache produces a wrong result rather than merely a stale one, and points at `-32021` as the sanctioned response when the present declaration falls short.