How AgentCore Gateway supports the MCP 2026-07-28 spec

The Model Context Protocol just crossed a threshold it's been building toward for a while: it dropped its session model entirely. The 2026-07-28 spec, published today, is described by its own maintainers as the largest revision since MCP launched, and the headline change is that the protocol is now stateless, meaning a remote MCP server behaves like an ordinary HTTPS endpoint instead of something that needs sticky sessions or a shared session store to scale.

Under the old design, every interaction started with an initialize/initialized handshake, and the server handed back an Mcp-Session-Id that had to ride along on every subsequent call. That pinned a client to whichever server instance issued the session, which is a headache the moment you try to run MCP servers behind a load balancer at any real scale. The new spec, via SEP-2575 and SEP-2567, kills the handshake and the session header. Instead, protocol version, client info, and capabilities travel inside the request's own _meta field, so a single tool call is self-contained and can land on any server instance. If an application still needs continuity across calls, the pattern now is to pass an explicit ID as a tool parameter, the same way you'd handle state in any stateless HTTP API.

The rest of the update is mostly about making MCP traffic legible to normal infrastructure. New Mcp-Method and Mcp-Name headers expose intent outside the JSON-RPC body, so load balancers and rate limiters no longer need to parse payloads to know what's happening. List and read responses now carry TTL and cache-scope metadata borrowed from HTTP Cache-Control semantics, and the spec reserves W3C Trace Context keys so a distributed trace can flow cleanly from agent to gateway to downstream service. Error handling gets cleaner too: transport failures now return real HTTP status codes instead of a JSON-RPC error wrapped in an HTTP 200, and the old MCP-specific