The Model Context Protocol changed its basic operating assumption. In the 2026-07-28 revision, a request should carry the context a server needs instead of depending on an initialization exchange and a sticky session. That makes horizontal scaling easier, but it breaks clients and gateways that treated transport state as part of the protocol.
The MCP project formally retired initialize, initialized, and Mcp-Session-Id. Each request can now identify the protocol revision, client, and declared capabilities through metadata. An optional server/discover method provides server details when a client needs them.
The old and new MCP contract
| Concern | Older revisions | 2026-07-28 revision |
|---|---|---|
| Startup | initialize, then initialized | No mandatory setup exchange |
| Session routing | Mcp-Session-Id could bind requests | Any request can reach any instance |
| Protocol version | Negotiated during initialization | Sent with each request |
| Client identity | Initialization context | Request metadata |
| Capabilities | Initialization context | Request metadata |
| Server discovery | Implicit in startup exchange | Optional server/discover |
The design target is simple: a round-robin load balancer should be safe. Request two does not need to land on the worker that handled request one. Servers can still maintain application state in a database or job system, but transport stickiness is no longer the mechanism that makes the protocol correct.
What breaks first
- A client that refuses to send tools or calls before initialization completes.
- A gateway that routes by
Mcp-Session-Id. - A server that stores authorization or capability state only in worker memory.
- A reconnect flow that expects
Last-Event-IDto resume the protocol stream. - Health checks that treat HTTP GET or DELETE support as mandatory.
The revised Streamable HTTP spec allows a server to return method not allowed for GET or DELETE. It may ignore old session and event-resume headers. Those responses are not necessarily outages. Monitoring must interpret them in the context of the negotiated protocol revision.
Self-contained does not mean unauthenticated
Putting client identity and capabilities in metadata does not make every claim trustworthy. Authentication still needs a verifiable credential and authorization still belongs on the server. Treat capability declarations as request context, not as permission to use a tool.
Our guide to agentic resource discovery makes the same separation: discovery can tell an agent that a resource exists, while policy decides whether the caller may use it.
Use a dual-stack compatibility layer
A safe client starts with explicit version handling. When it talks to an older server, preserve the older initialization and transport rules. When both sides support 2026-07-28, send the new request metadata and do not require a session header. Log which path was selected.
Do not guess the revision from one HTTP status. A proxy can rewrite errors, and an older deployment may expose a newer route accidentally. Add an integration fixture for each supported revision and fail clearly when neither contract completes.
Move state to an explicit owner
Audit anything currently held in process memory: consent, pagination cursor, job handle, tool approval, rate-limit counter, artifact reference, and audit correlation ID. Decide whether it belongs in the request, a signed token, or a durable store. Document expiry and ownership for each item.
This is also the moment to remove accidental cross-user state. Sticky workers can hide isolation bugs because one user’s requests keep returning to the same process. Randomized routing and concurrent-user tests expose those assumptions quickly.
A seven-test migration suite
- Send consecutive requests to different backend instances.
- Restart a worker between tool listing and tool invocation.
- Remove all old session headers on the new path.
- Verify authorization on every consequential call.
- Return 405 for unsupported GET and DELETE without triggering an outage alert.
- Run old and new clients against both supported server revisions.
- Trace one request across gateway, server, tool, and durable state.
Keep success criteria observable. A tool result is not enough if the audit trail loses the caller or the load balancer creates duplicate work. The AI integration control-plane guide shows how idempotency and approval gates matter when an agent can change external systems.
My verdict: remove session assumptions before adding scale
Instrument the transition with revision, request ID, client ID, backend instance, authorization decision, tool call, and response status. Redact secrets, but keep enough correlation to prove that a request succeeded after crossing instances. Track how often the compatibility path is used. When that number reaches zero for an agreed support window, remove legacy code and the operational alerts built around session headers. Until then, a dual stack is a product commitment and should have an owner.
Test cancellation and long-running work separately from ordinary request routing. A durable job should keep its own identifier and status outside one HTTP connection. If a client disconnects, the server must know whether to continue, cancel, or expose the result later without depending on the worker that received the first call.
The stateless revision is a useful simplification. It makes the protocol friendlier to ordinary web infrastructure and reduces the amount of hidden setup state. It does not remove the need for durable application state, authentication, or safe retries.
Upgrade in two passes. First make every request independently routable and observable. Then remove the legacy initialization and session path after your oldest supported clients are gone. A clean cutover is less important than knowing which contract handled every request.
Read the primary specification
- Read the MCP project’s 2026-07-28 specification announcement.
- Review the Streamable HTTP transport specification.
- Compare the MCP version negotiation guidance.
Checked September 3, 2026. Protocol changes come from the official MCP repository and specification. Failure modes, migration order, and test design are Musthave.ai analysis.
