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

<p>Today, the Model Context Protocol (MCP) published its 2026-07-28 specification, the largest and most significant revision of the protocol since its launch. With this release MCP becomes a stateless protocol that scales on ordinary HTTP infrastructure. Alongside the transport changes, this new version introduces a governed extensions system, strengthens authorization by aligning more closely with enterprise practices for OAuth 2.0 and OpenID Connect, and establishes lifecycle guarantees that limit future breakage.</p> <p>You can start using the latest protocol on your <a href="https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html" target="_blank" rel="noopener">AgentCore Gateway</a>, a capability of Amazon Bedrock AgentCore, today by calling <code>UpdateGateway</code> with the list of versions you want your gateway to support. Existing clients keep working exactly as before, and there is no per-target step. In this post, we walk through what changed in the protocol and why, what it means for your agents and tools, and how to enable the new version on your gateways.</p> <p>Already familiar with the spec changes? Jump straight to <a href="#updating-your-agentcore-gateway">Updating your AgentCore Gateway</a>.</p> <h2 id="what-changes-with-the-new-spec-and-why-it-matters">What changes with the new spec and why it matters</h2> <p>This release contains <strong>backward-incompatible changes</strong> to the MCP protocol. The transition to statelessness is a foundational change that protocol maintainers believe is necessary to address scaling challenges with enterprise deployments. The introduction of breaking changes with new versions, however, is not expected to be the norm. To help facilitate backward-compatible updates in future revisions, maintainers have introduced new governance enhancements to the protocol specification (a feature lifecycle policy, an extensions framework, and a conformance-suite requirement). These enhancements are designed to support protocol evolution without breaking core capabilities.</p> <p>Upgrading is also <strong>opt-in</strong>, and nothing changes until both you and your clients act. AgentCore Gateway advertises the protocol versions it speaks through a single configuration field. Clients select a version on every request. Adding 2026-07-28 to a gateway that also advertises 2025-11-25 does not change anything for clients that request the older version. Only a client that requests 2026-07-28 gets the new behavior. Nothing breaks on July 28.</p> <h2 id="mcp-is-now-stateless">1. MCP is now stateless</h2> <p>In prior versions of the protocol, every Streamable HTTP interaction with an MCP server began with an <code>initialize</code>/<code>initialized</code> handshake, in which the client and server exchanged protocol versions and capabilities. The server then issued an <code>Mcp-Session-Id</code> header that every subsequent request was required to carry:</p> <pre class="http"><code>POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json Accept: application/json {"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}}}</code></pre> <p>That session pinned the client to the server that issued it. Therefore, to scale an MCP server horizontally, operators needed sticky sessions at the load balancer, a shared session store behind the fleet, or both.</p> <p>By removing sessions, remote MCP servers effectively become standard HTTPS endpoints, which scale cleanly with enterprise workloads. As the protocol becomes stateless, the handshake and the protocol-level session are both no longer needed (<a class="Hyperlink TrackedChange TrackChangeHyperlinkInstruction SCXW147330082 BCX0" href="https://modelcontextprotocol.io/seps/2575-stateless-mcp" target="_blank" rel="noreferrer noopener"><span class="TextRun Underlined SCXW147330082 BCX0" lang="EN-US" xml:lang="EN-US" data-contrast="none"><span class="NormalTextRu