MCP 2026-07-28 behind HTTP load balancers: routing and safe cache scope

What it is

Status as of 25 October 2026. MCP 2026-07-28 lets each HTTP request carry the context needed to process it independently. Re-check the versioned Streamable HTTP, caching and tools specifications before changing gateway rules. Ordinary load balancing and correct result caching are separate deployment decisions.

The core no longer requires transport sessions. Application state spanning requests still needs explicit identifiers and appropriate storage. A request may also have a streaming response; statelessness does not make every connection short-lived.

Why it matters

RFC 9111 defines ordinary HTTP cache keys around the HTTP method and target URI, with additional variation where specified. MCP operations share a POST endpoint, while their method and parameters live inside JSON. Inference: a generic cache keyed only by /mcp cannot safely distinguish those operations. JSON ttlMs is not an HTTP Cache-Control header and does not configure a proxy automatically.

Tool lists may vary with authorization, although they must not vary because of connection history. Deterministic ordering is recommended when the available set is unchanged. Neither property makes a permission-filtered catalogue public.

How to apply

• Preserve and validate routing metadata. Forward MCP-Protocol-Version and Mcp-Method; Mcp-Name is required for tools/call, resources/read and prompts/get. Servers processing the body must reject mismatches or missing required headers with HTTP 400 and HeaderMismatch (-32020). Decode names using the specified encoding before comparison. Do not trust these mirrored headers on a legacy path that lacks the corresponding validation requirement.
• Keep sensitive inputs out of routing headers. Tool schemas may expose parameters through x-mcp-header; the tools specification advises against marking passwords, tokens or personal data because intermediaries can see them. Route using permitted metadata and retain authorization at the execution boundary.
• Preserve streaming. Support JSON and SSE responses, disable inappropriate response buffering, and check idle-timeout behavior. The transport recommends X-Accel-Buffering: no for SSE and keep-alive comments for long-lived streams. Do not configure Last-Event-ID resumption for this revision or cache subscription streams.
• Limit eligible results. Cache hints are required on complete discovery, tool-list, prompt-list, resource-list, resource-template-list and resource-read results. Interim input_required results and requests carrying inputResponses or requestState must not be cached. Do not infer cache eligibility for tool execution merely from a read-only description.
• Apply freshness and isolation independently. ttlMs measures milliseconds from receipt; zero means immediately stale. Relevant change notifications invalidate fresh entries. public permits sharing only non-user-specific data; private restricts reuse to the same authorization context, including a separate cache for a different token. Key entries by server, protocol, method and result-affecting parameters; keep pagination pages distinct.
• Cache results, not obsolete envelopes. An MCP-aware intermediary must return the current request's JSON-RPC ID. Preserve the original freshness deadline rather than renewing it on a cache hit. For an ordinary HTTP proxy, keep POST caching disabled unless its MCP behavior is explicitly implemented and verified. Where storage must be prohibited, use the HTTP no-store directive as well as application policy; private alone permits private-cache storage.
• Verify with isolated test identities. Proposed staging checks: alternate instances, retrieve the same list under different permissions, change a catalogue, expire an entry, and reuse an eligible result with a different request ID. Confirm timely stream delivery and absence of cross-user reuse.

Pitfalls

TTL is a freshness hint, not a guarantee that data cannot change. Routing by a header is not authentication. A successfully balanced request does not prove that retries are safe for actions with side effects. Keep those application decisions explicit when enabling infrastructure optimizations.