How MCP 2026-07-28 changes AgentCore operations

Remote MCP servers ran over HTTP, yet they were harder to scale like ordinary APIs. Part of the context between requests remained attached to a connection. Horizontal scaling therefore required sticky routing or a session store shared by every server instance.

MCP 2026-07-28, released on July 28, 2026, changes that premise. Each request now declares the protocol version, operation, and required client information. Only clients that need to inspect server capabilities call the separate discovery method. Remote MCP can now be operated around the lifetime of an HTTP request instead of a connection.¹

AgentCore-based agents are affected too. A stateless transport does not erase an agent's execution state or business state. To understand this release from a deployment perspective, separate the state that disappeared from the state that merely moved.

The release removes a transport session, not all state

State in an AgentCore system falls into at least three layers.

The specification removes the first layer. It does not remove Runtime session isolation or Memory. A multi-call workflow issues a handle such as job_id or browser_id, then passes that handle back in the arguments of the next tool call.

Previously, processing state could hide behind a connection while the server recovered the context. The model and application must now handle state identifiers explicitly. Infrastructure gets simpler, but the application still owns handle expiry, ownership, reuse permissions, and idempotency. The burden is greater for irreversible tools such as payments, deletion, or external transmission.

The payload carries request context instead of session context

You do not need to memorize every new field to understand the operational change. One comparison shows what a migration changes. A follow-up tool call under the earlier protocol returned the session identifier issued by the server.

POST /mcp HTTP/1.1
Mcp-Session-Id: <session-id>
Content-Type: application/json
Accept: application/json

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"continue_job","arguments":{"job_id":"job_01"}}}

A 2026-07-28 request exposes the protocol version and operation in headers while carrying client information in the body. An HTTP intermediary such as Gateway or WAF can identify the operation without parsing JSON-RPC. The request body remains the final authority.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: continue_job
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":41,"method":"tools/call","params":{"name":"continue_job","arguments":{"job_id":"job_01"},"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"agentcore-agent","version":"1.0"}}}}

The job_id here is not a replacement for an MCP session. It is a state handle owned by the business system. A tool returns the handle in its first response, and the agent supplies it in the next request.

{
  "name": "continue_job",
  "arguments": {
    "job_id": "job_01",
    "approval_id": "approval_07"
  }
}

This distinction changes the security boundary. Gateway checks the caller and tool permission. The target must separately verify that the caller may use that job_id. The target or business store also owns handle expiration, reuse, and duplicate-request handling.

What actually changes in AgentCore

The size of the change depends on which AgentCore layer you operate.

AgentCore Gateway turns Lambda functions and OpenAPI or Smithy APIs into MCP tools. The change is narrow in that setup. The MCP version belongs to the Gateway, not to each target. Adding 2026-07-28 to supportedVersions leaves Lambda and existing API input contracts intact.²

On the agent side, verify that the MCP client SDK actually selects the new version. When a framework hides the SDK, do not infer support from the package version alone. Confirm the requested protocol version in Gateway access logs.

The validation surface is broader when Gateway fronts a custom MCP server. AgentCore Gateway translates ordinary tool calls between old and new versions, but a 2025 client invoking Elicitation or Sampling on a 2026 server is outside that translation path. Test whether the client, Gateway, and target server support the same capability across the full route.²

AgentCore Gateway can expose the new version gradually. Read the current configuration first, then update it with the complete list containing both old and new versions.

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier <gateway-id>

aws bedrock-agentcore-control update-gateway \
  --name <gateway-name> \
  --role-arn <gateway-role-arn> \
  --protocol-type MCP \
  --authorizer-type <gateway-authorizer-type> \
  --gateway-identifier <gateway-id> \
  --protocol-configuration '{
    "mcp": {
      "supportedVersions": ["2025-11-25", "2026-07-28"]
    }
  }'

There is one trap: UpdateGateway replaces the complete version list rather than appending one value. Sending only the new version without reading the current configuration can disconnect older clients. Requests without a version header are treated as 2025-03-26, so explicit version transmission belongs in regression tests.

What the infrastructure gains

The most direct gain is horizontal scaling. A request no longer depends on a protocol session held by one instance, making round-robin load balancing and serverless execution easier. A shared business-state store may still be necessary, but sticky routing and shared storage required only by MCP become removal candidates.

With Mcp-Method and Mcp-Name, Gateway, WAF, and rate limiters can distinguish request types without opening the JSON-RPC body. Tool-specific limits, routing, cost allocation, and latency metrics can live in the standard HTTP layer. Servers reject mismatches between headers and the body, reducing the risk of an intermediary trusting a misleading header.

Tool and resource lists now carry ttlMs and cacheScope. Clients can avoid repeatedly calling a stable tools/list, and stable tool ordering after reconnection reduces churn in upstream prompt caches. W3C Trace Context is standardized in _meta, making it easier to connect one trace from the MCP host through Gateway to the target service.

Use the observability maturity model to decide how far distributed tracing and alerting need to go.

Errors also split between the HTTP and application layers. An unsupported version returns HTTP 400 with -32022, a mismatch between headers and body returns HTTP 400 with -32020, and an unknown method returns HTTP 404. Monitoring can distinguish rollout errors from application failures without parsing the JSON-RPC body.

These benefits do not guarantee lower cost. If Gateway already absorbed session handling, or business state still requires shared storage, there may be little infrastructure to remove. Measure adoption by components retired, deployment options gained, and incident response time. A serverless label alone does not prove savings.

Simpler infrastructure creates new application duties

Explicit state design has a cost. Handles are easier to observe and reproduce when they appear in requests, but also easier to steal or replay. Make them unguessable, bind them to the authenticated principal, and define expiration, revocation, and idempotency for repeated requests.

Cache boundaries need care too. Sharing a tool list or resource result marked cacheScope: "private" across authenticated principals can mix permissions or data. Setting every TTL to zero, however, discards the new cache contract. If a tool catalog varies by user, include authentication context in the cache key.

The compatibility matrix grows while Gateway serves two protocol versions. Test client, Gateway, target versions, and extension support together. Core-version support does not imply support for MCP Apps or Tasks. Each Extension has its own version and capability negotiation.

Old features also need a retirement plan. Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated. They will not disappear immediately, and the deprecation window lasts at least 12 months, but new implementations should avoid depending on them. If you used the experimental 2025 Tasks API, redesign around the tasks/get, tasks/update, and tasks/cancel lifecycle in the new io.modelcontextprotocol/tasks extension.¹

Authentication has separate work. The new specification requires RFC 9207 iss validation and binds credentials to their issuing authorization server. Dynamic Client Registration is deprecated during the move toward Client ID Metadata Documents. Raising the protocol version does not alter an existing IAM or OAuth/JWT authorizer on AgentCore Gateway. Audit issuer validation and registration flows in custom MCP OAuth clients and servers separately.

Decide on Apps and Tasks separately from the core upgrade

Formal MCP Extensions make long-term operation more predictable. Instead of adding every capability to the core and forcing another breaking release, MCP now negotiates independent extension IDs and versions. Clients and servers that do not support an extension can ignore it. AAIF likewise frames the release less as a feature bundle and more as the operational predictability and security needed for enterprise infrastructure.³

MCP Apps lets a tool server provide interactive HTML that a host renders in a sandboxed iframe. Tasks returns a durable handle for long-running work so a client can inspect, update, or cancel its progress. This model fits a stateless core because the work can survive a dropped connection or restart.

Adding 2026-07-28 to AgentCore Gateway is not the same as putting Tasks into production. The host, client SDK, Gateway, and target server must support the extension. Claude also announced a staged rollout across products, so do not assume that every host supports every extension today.⁴

Long-running work does not automatically require Tasks. If Step Functions, SQS, EventBridge, or a business job API already provides a proven asynchronous lifecycle, Tasks should expose a standard MCP surface rather than replace that execution layer. Map the task handle to the internal job ID, propagate cancellation, and define retention.

Decide when to adopt it

The best candidate is not a system with no state. It is a system that already separates transport state from business state.

A four-stage migration is enough

Start with a dependency inventory. Search code and infrastructure for initialize, initialized, Mcp-Session-Id, logging/setLevel, -32002, Roots, Sampling, and the old Tasks API. Confirm that the agent framework and MCP SDK actually support 2026-07-28.

Next, publish the old and new versions together on Gateway. Only canary clients that request the new version should enter the 2026 path. There is no need to force the Gateway setting and every client deployment into the same release window.

Then validate across instance changes. Send follow-up requests with the same state handle to different instances and verify that work continues. Test per-tool rate limits, trace continuity, cache isolation, retries, and duplicate execution. If the system uses Elicitation or Sampling, add explicit failure scenarios for each old and new version combination.

Finally, retire the old version. Remove it from supportedVersions only after every client sends the new version explicitly and the fallback has been tested. Record the full current list before replacement and roll back with that complete list if necessary. Like any production AI rollout, this migration needs rollback gates and evidence before release.

What it means for MCP to behave more like ordinary HTTP

The largest change in MCP 2026-07-28 is not the number of features. By removing initialize and Mcp-Session-Id, the protocol drops two hidden infrastructure contracts. A Japanese analysis captured this perspective as “graduating from session management.”⁵

When AgentCore Gateway turns Lambda and APIs into MCP tools, adopting the release may remain a thin boundary change. A custom MCP server that hid context inside a session faces a different migration: the application must take on explicit state and authorization design.

The real question is not whether stateless is better. Ask which state the protocol had been carrying and who now owns it. Clear ownership unlocks serverless execution, horizontal scaling, and standard observability. Unclear ownership is a reason to fix state boundaries before enabling a version flag.

For the earlier layer in which a website exposes and helps agents discover an MCP endpoint, see our practical implementation of agent readiness. This article covers the next step: the operating protocol and deployment boundary.

If you need to design protocol migration, authorization boundaries, and the AgentCore Gateway deployment together, start with Cloud & Infrastructure. AX consulting connects the agent's tools, evaluation, and business workflow.

References