The Model Context Protocol (MCP) 2026-07-28 revision is the largest change to MCP since launch.
Earlier MCP revisions (2025-06-18 and 2025-11-25) share a session-based transport. A client establishes a session with an initialize/initialized handshake, receives an Mcp-Session-Id, and carries that ID on every subsequent request. The server handling that session must track its state, which in practice requires sticky routing behind a load balancer.
The 2026-07-28 revision removes the handshake and Mcp-Session-Id entirely. Every request is self-contained: the client declares its protocol revision and identity on each call instead of once at connection time. Any server instance can handle any request, and sticky routing is no longer required at the protocol layer.
The AI MCP Server entity detects a client’s protocol revision from the MCP-Protocol-Version header, reconfirmed from _meta, and applies the matching request and response model on the same route that already serves older revisions. The following table describes each change between the 2026-07-28 revision and the previous ones, and the specific impact on AI Gateway.
|
Area
|
2025-06-18 / 2025-11-25
|
2026-07-28
|
Impact on AI Gateway
|
|
Session lifecycle
|
initialize handshake plus Mcp-Session-Id on every request
|
No session; protocol version and client info carried in _meta per request
|
Stateless dispatch: no initialize/initialized exchange, no Mcp-Session-Id issued or expected, and an inbound Mcp-Session-Id header is ignored
|
|
Capability exchange
|
One-time at connection
|
server/discover on demand
|
server/discover replaces initialize as the way a 2026-07-28 client fetches server capabilities
|
|
Routing signal
|
Body inspection required
|
Mcp-Method and Mcp-Name headers on every request
|
Mcp-Method and Mcp-Name headers are validated against the JSON-RPC body; a mismatch is rejected
|
|
Tool list freshness
|
Long-lived SSE stream for change notification
|
ttlMs and cacheScope per response
|
tools/list and server/discover responses can carry ttl_ms and cache_scope cache hints, configured through config.server.cache
|
These changes are breaking at the protocol level: a 2026-07-28 client sending a stateless request to a server that only expects a session handshake gets an error or is misrouted. A revision-aware gateway is what lets both kinds of clients reach the same endpoint safely.
The following AI Gateway behaviors are specific to the 2026-07-28 revision but don’t map to a single spec change:
- Header validation:
Mcp-Method and Mcp-Name headers are validated against the JSON-RPC body, a mismatch is rejected.
- HTTP-status errors: A JSON-RPC failure carries its own HTTP status instead of being nested inside an HTTP 200 response.
- Unsupported revisions: A client declaring a revision the server doesn’t accept gets
HTTP 400 with JSON-RPC error -32022, listing the revisions the server serves. Narrow the accepted set with config.server.allowed_versions.
- Scope-hierarchy ACLs: An OAuth-scope ACL rule matches on scope hierarchy for
2026-07-28 clients, so a broader granted scope satisfies a rule naming a narrower one. Earlier revisions keep exact-match comparison.
For field-level configuration, see MCP versions on the AI MCP Server entity page.