Amazon AWS Backs Stateless MCP, but Compatibility Is Now the Real Test

Amazon AWS added MCP 2026-07-28 support to AgentCore Gateway two days after the specification’s largest architectural revision reached stable release. One UpdateGateway call can enable the new protocol version on an existing gateway. However, the simple control-plane change conceals a harder transition for clients, servers, and enterprise security teams.

The new Model Context Protocol revision removes protocol-level sessions and makes every request describe its own version and client capabilities. MCP is an open standard for connecting AI applications with tools, data sources, and other services. Its stateless design should make gateways easier to scale, route, and recover.

That benefit comes with a compatibility test. Clients must adopt new request metadata, servers must implement discovery, and older session assumptions no longer hold. Amazon Bedrock AgentCore Gateway now sits between those two protocol eras, translating enterprise services into MCP tools while enforcing access controls at one managed endpoint.

The real story is therefore larger than a version checkbox. Amazon AWS is betting that a managed gateway can absorb protocol churn before it reaches every application team. Whether that works depends on version negotiation, authorization correctness, and the behavior of mixed client fleets.

Amazon AWS Turns a Major MCP Rewrite Into One Gateway Update

AWS has reduced the infrastructure step to one API operation, but applications still need to speak the revised protocol correctly.

The MCP maintainers released the stable 2026-07-28 specification on July 28, following a release-candidate period that began in May. The stable MCP release replaces several assumptions established during the protocol’s early growth.

AWS followed with support in Amazon Bedrock AgentCore Gateway. According to the company’s AgentCore update, gateway owners can add the new revision through UpdateGateway. The request updates the gateway’s MCP protocol configuration and its supported version list.

The relevant control-plane object is protocolConfiguration.mcp.supportedVersions. AWS documents that field as an array of MCP versions the gateway can use. UpdateGateway returns HTTP status 202 when the service accepts an update, after which the gateway moves through an updating state.

That distinction matters operationally. An accepted call does not mean every connected client has completed a successful request. Teams should wait until the gateway returns to its ready state, then run conformance and workload tests against the actual endpoint.

The change does not require organizations to rebuild every Lambda function, OpenAPI service, or Smithy service behind their gateway. AgentCore Gateway already converts those resources into MCP-compatible tools. It also supports remote MCP targets and other HTTP services, depending on the target configuration.

This architecture lets AWS change the protocol-facing layer without requiring identical changes in each downstream business service. A customer-support API can remain an API, for example, while the gateway exposes its operations as tools to compatible agents.

AgentCore Gateway also handles inbound authentication, outbound credentials, tool discovery, routing, and policy enforcement. Those controls become more valuable when one endpoint fronts services owned by several internal teams.

Yet the UpdateGateway call changes only the gateway’s declared support. A client using the 2026 revision must still send the required metadata and headers. An older client must negotiate a mutually supported revision or use a compatible fallback path.

That is the first constraint behind AWS’s simple upgrade message. The managed service can reduce platform work, but it cannot make an outdated SDK emit a new wire format.

The second constraint involves testing. Gateway owners need to verify tool listing, tool calls, authentication failures, streaming behavior, and cache controls under each supported version. Success with one modern client does not establish compatibility across an enterprise fleet.

A practical rollout therefore starts with inventory. Teams need to identify which agent applications connect to the gateway, which SDK versions they use, and whether those SDKs support MCP 2026-07-28.

Organizations that maintain technical decisions and test evidence in a searchable engineering knowledge base can record results by client and protocol version. That record becomes important when a failure appears only in one framework or deployment channel.

AWS has made the control-plane action small. The application-level verification remains the real migration project.

Why Stateless MCP Changes the Gateway Equation

Stateless MCP moves compatibility information into every request, making horizontal routing simpler while forcing each message to stand on its own.

Earlier MCP revisions used an initialization exchange to establish protocol details and capabilities. A client sent initialize, the server responded, and the client completed the sequence with notifications/initialized. Streamable HTTP could also use an Mcp-Session-Id header to associate later traffic with a protocol-level session.

The MCP key changes remove that lifecycle for the new revision. They also remove the protocol-level session identifier. Servers that need state across calls must issue explicit handles that clients pass as regular tool arguments.

Every new-style request carries its protocol version and client capabilities inside _meta. Clients should also identify themselves there. Servers return their identity within result metadata, making each exchange more self-describing.

A new server/discover method lets a client inspect supported versions, capabilities, and server identity before other work begins. A server using the 2026-07-28 revision must implement this remote procedure call.

This design changes what a gateway needs to remember. It no longer has to depend on an initialization exchange completed through one connection or associate later protocol traffic with an opaque MCP session.

A load balancer can route separate requests without preserving protocol-level affinity. A gateway instance receiving the tenth call can inspect the same essential compatibility information that the first instance received.

That model suits a managed cloud gateway. Stateless services can scale across workers, replace unhealthy capacity, and distribute traffic without restoring an MCP session record before interpreting every request.

It also reduces an awkward mismatch between short-lived cloud infrastructure and connection-oriented protocol behavior. Serverless functions and distributed gateways generally work best when requests contain the information required for independent processing.

However, stateless does not mean the agent’s work has no state. A purchasing workflow might still require approval information, a transaction reference, or data collected during an earlier exchange. The specification moves that state into explicit application-level handles instead of hiding it within the transport session.

That shift can improve visibility. Tool arguments and server-issued handles create clearer ownership boundaries than state inferred from a connection. They also demand careful design because clients may retry requests or present old handles.

The new revision drops Streamable HTTP resumability through Last-Event-ID and server-sent event identifiers. If a response stream breaks during a request, the client must send a new request with a new request ID.

That rule creates an important operational question. If a tool performs a side effect before the stream fails, a blind retry could repeat the action unless the application implements idempotency.

Consider an agent that creates a support ticket. The ticket service might successfully store the record while the response stream disappears. A retry should carry an application-level idempotency key or query the prior operation before creating another ticket.

AWS cannot solve every downstream idempotency problem at the protocol boundary. Gateway logs and traces can show the repeated calls, but the target service must define safe retry behavior.

The revision also replaces separate server-initiated calls with Multi Round-Trip Requests. Under this pattern, a server returns an input_required result describing information it still needs. The client retries the original request with the requested responses.

This approach keeps control within a request and retry sequence. It avoids an independent server-to-client request arriving through a connection that another gateway instance might not own.

All results now include a resultType, normally complete or input_required. Clients talking to older servers must treat an omitted value as a completed result, preserving a limited compatibility bridge.

The mechanism clearly favors distributed infrastructure. The tradeoff is that SDKs and applications must adopt more explicit metadata, retry logic, and state handling.

The Pressure Falls on SDKs and Mixed Client Fleets

AgentCore Gateway can support two protocol eras, but each organization must prove that its clients negotiate the right one.

The immediate pressure target is not an API hidden behind the gateway. It is the client software that connects to the MCP endpoint.

A client claiming the 2026-07-28 revision must send the protocol version and its capabilities on each request. It must understand server/discover, required result types, and the revised handling of multi-step interactions.

HTTP clients must also use standard MCP request headers, including Mcp-Method and Mcp-Name. These headers let infrastructure inspect and route traffic without parsing every JSON-RPC body.

That change is useful for gateways, observability systems, and security controls. It also creates another validation point where incomplete clients can fail before a tool executes.

MCP defines specific errors for this new boundary. Header mismatches use code -32020, missing required client capabilities use -32021, and unsupported protocol versions use -32022.

Those codes give platform teams a clearer failure taxonomy. A rise in -32022 responses indicates version negotiation trouble, while -32020 points toward disagreement between HTTP headers and the enclosed request.

The SDK transition will not happen simultaneously across languages. Official implementations can adopt a stable specification on different schedules, and applications often pin library versions long after a new release appears.

Enterprises also have clients they do not fully control. An employee might use an approved desktop assistant, an internal command-line agent, and an IDE extension built by another team. Each may negotiate MCP differently.

AgentCore’s supported version list offers a bridge for this mixed fleet. The gateway can advertise more than one revision rather than forcing all clients onto the new wire format at once.

That support should be treated as a migration mechanism, not proof of identical behavior. Features removed from the 2026 core still exist in older protocol flows. A test that passes after negotiating an older revision says little about the stateless path.

Roots, Sampling, and Logging are now deprecated rather than immediately removed from the entire specification. New implementations should avoid adopting them, while existing implementations receive a defined transition period.

MCP’s new feature lifecycle policy establishes a minimum 12-month deprecation window. This governance change gives implementers more predictable notice than informal deprecation language.

The protocol suggests alternatives. Applications can pass directories through tool parameters or resource identifiers instead of Roots. Servers can call model-provider APIs directly instead of relying on Sampling. Implementations can use OpenTelemetry or standard error streams instead of protocol Logging.

Those substitutions change architecture, not merely syntax. A server that previously requested model sampling through its MCP client may need a direct provider integration, separate credentials, and a new cost-control policy.

The pressure therefore extends to security and finance teams. Moving model access from a client capability into the server changes where credentials live and where usage appears.

Gateway owners should classify clients into three groups. The first group fully supports the 2026 revision. The second works only with a prior stable version. The third has unclear behavior and needs isolation until testing is complete.

Testing should cover more than tools/list. A useful matrix includes discovery, authenticated tool calls, rejected scopes, response streaming, interrupted requests, list caching, and applications requiring additional user input.

Teams should also verify the negotiated version in telemetry. Without that signal, a successful request might hide an unexpected downgrade to the earlier protocol.

The migration succeeds when the new path carries representative production workloads. It does not succeed merely because the gateway accepts an updated supportedVersions field.

Authorization Gets Stricter as Extensions Leave the Core

MCP 2026-07-28 narrows credential ambiguity while moving optional capabilities into a governed, negotiated extension system.

The revised authorization rules focus on identity boundaries that become risky when agents connect to many servers. An MCP client may obtain credentials from several authorization servers, each protecting different tools and data.

The specification now says clients must bind stored credentials to the issuer that created them. A client must not reuse credentials with another authorization server, and it must register again when the issuer changes.

This rule addresses credential confusion. Similar server names, redirects, or changing metadata should not cause one service’s client credentials to travel to another authorization boundary.

Authorization servers should also include an iss value in their authorization responses. When that field is present, clients must validate it against the issuer recorded before exchanging the authorization code.

That validation follows RFC 9207, an Internet Engineering Task Force standard designed to prevent authorization-server mix-up attacks. The check matters when one client interacts with multiple issuers or discovers authorization metadata dynamically.

Dynamic client registration also receives tighter guidance. MCP clients must specify an appropriate application type, reducing conflicts around redirect URI rules for native and web applications.

These requirements do not make every deployment secure automatically. SDK options still need correct configuration, stored credential records require proper keying, and identity providers must return consistent issuer information.

AgentCore Gateway provides a useful enforcement point because it can authenticate inbound callers and manage outbound credentials separately. AWS documentation says the service supports custom JSON Web Token authorization, AWS Identity and Access Management, and other configured authorization modes.

That separation is essential. The identity allowed to invoke a gateway should not automatically receive unrestricted credentials for every target behind it.

AgentCore can also associate a policy engine with a gateway. The engine evaluates agent tool calls and decides whether each action is allowed or denied under configured policies.

The gateway model does not remove the need for least privilege. A broadly scoped target credential remains broadly scoped even when stored in a managed identity service.

Teams should test negative cases as carefully as successful calls. A client with an insufficient scope should receive a controlled authorization response, not an unrelated protocol error or access to a neighboring tool.

The extension system creates a parallel governance change. Optional features can now develop outside the core protocol while using standardized identifiers, capability declarations, and negotiation.

Under the extensions framework, official identifiers use the io.modelcontextprotocol prefix. Third parties should use a reversed domain they own, which reduces collisions between unrelated features.

Clients advertise supported extensions within their per-request capabilities. Servers advertise theirs through server/discover. Both sides must explicitly opt in, and extensions remain disabled by default.

Official extensions include asynchronous Tasks, interactive MCP Apps, OAuth client credentials, and enterprise-managed authorization. The core no longer needs to absorb each specialized feature before implementers can use it.

This structure can limit core complexity. It also creates a support matrix that platform teams must track across clients, servers, gateways, and SDK versions.

A client supporting an interactive interface extension should still handle a meaningful text response when the server can degrade gracefully. A server requiring a particular authorization extension can instead reject an incompatible client.

AgentCore Gateway’s first obligation is correct core protocol behavior. Support for the 2026 revision should not be interpreted as universal support for every present or future extension.

That is a key uncertainty in AWS’s announcement. The gateway can carry extension capability information, but customers need explicit documentation and tests for any extension their workflow depends upon.

The authorization changes and extension framework share one principle. Hidden assumptions are becoming explicit, whether they concern credential issuers, client capabilities, or optional behavior.

That explicitness is good for enterprise control. It also means incomplete configuration will fail more visibly than it did under a permissive integration.

What Amazon AWS Customers Still Need to Prove

The next three signals are negotiated-version telemetry, authorization failure quality, and extension support under real workloads.

The first signal is whether production clients actually negotiate MCP 2026-07-28. Gateway configuration alone cannot answer that question.

Teams should monitor request metadata and protocol-related errors after a staged rollout. They should compare results by client name, client version, framework, and deployment channel.

A falling rate of unsupported-version and header-mismatch errors would strengthen AWS’s managed-migration case. Persistent errors would show that client SDK adoption, not gateway availability, remains the bottleneck.

Downgrades deserve equal attention. A client that silently falls back to an older revision can keep a workflow running while hiding an unresolved migration problem.

Organizations should define the expected revision for each tested client. Alerts can then distinguish an approved compatibility fallback from an unintended downgrade.

The second signal is how authorization failures behave across multiple identity providers and targets. Teams need to test issuer changes, invalid iss values, expired tokens, insufficient scopes, and attempted credential reuse.

The safest outcome is a precise denial before the target executes. Logs should identify the policy or authorization boundary involved without exposing secrets to the caller.

Clean negative tests would support the claim that AgentCore reduces custom security work. Confusing failures or inconsistent issuer handling would weaken it, especially for gateways spanning several business units.

The third signal is extension interoperability. A workflow using Tasks, MCP Apps, or an authorization extension should verify capabilities before invoking extension-specific behavior.

Testing must include graceful degradation. A client without UI support should still receive useful core content when the server promises a fallback.

The opposite case matters too. If an extension is mandatory for safe operation, the server should reject the request clearly instead of attempting a partial workflow.

There are broader operational signals beneath these three priorities. Teams should watch interrupted side-effecting calls for duplicate actions, because the new revision removes stream resumability.

They should also examine caching. List and resource results now include ttlMs, a freshness hint measured in milliseconds, and cacheScope, which separates public from private cacheability.

Deterministic tool ordering can improve client-side and model prompt caching. However, stale tool descriptions can cause an agent to call an outdated schema, so cache behavior needs testing during target updates.

Observability should include distributed trace context. The specification documents _meta conventions for traceparent, tracestate, and baggage, helping teams follow work across clients, gateways, and targets.

That tracing becomes especially useful during retries. Operators need to connect the original failed stream with the newly issued request without treating them as one JSON-RPC request ID.

The managed gateway’s strongest value appears when these concerns converge. One endpoint can authenticate callers, apply policy, translate protocol traffic, select tools, inject target credentials, and produce audit evidence.

Its main risk also appears there. A gateway becomes a high-leverage control point, so a configuration mistake can affect many agents and services simultaneously.

A careful rollout should begin with a noncritical gateway or a limited client cohort. Teams can add the new supported version, wait for ready status, and run a version-specific test suite.

The next stage should introduce representative stateful workflows using explicit handles. It should include one interrupted request and one safely retried side effect.

Authorization testing should follow with both successful and denied calls. Extension-dependent workflows should enter last, after core protocol behavior is stable.

Rollback planning remains necessary. Keeping the previous stable revision in the supported version list gives compatible clients a fallback while teams investigate defects.

However, fallback should not become permanent ambiguity. Organizations need a date for reviewing remaining older clients and a plan for deprecated features they still use.

Developers should care because the revision changes where they put state and how they retry. Platform teams should care because compatibility becomes observable at the gateway boundary.

Enterprise buyers should care because managed protocol support can reduce duplicated infrastructure. They should still ask which extensions, SDKs, regions, identity configurations, and target types have completed production validation.

Knowledge workers will experience the result indirectly. Their assistants may connect to more tools with fewer connection failures, but only if identity and consent remain clear across those tools.

Amazon AWS has made the first migration action unusually small. The more important question is whether teams can make every request self-contained without losing safety, compatibility, or visibility.

Over the next one to three months, watch negotiated-version data, authorization denial quality, and extension conformance across major SDKs. Those signals will show whether stateless MCP has become a production standard or remains a gateway feature awaiting its clients.

For teams already running AgentCore Gateway, the practical next action is a controlled compatibility audit. Update one gateway, test every supported client, record the negotiated revision, and force the failure cases before expanding access.

That evidence matters more than the apparent simplicity of one API call. Amazon AWS now provides the bridge to MCP 2026-07-28, but each organization must prove that its agents can cross it safely.