The Model Context Protocol project published its final 2026-07-28 specification on July 28, accompanied by updated TypeScript, Python, Go, and C# SDKs. The release removes protocol-level sessions, adds a governed extensions system, and changes how clients discover capabilities, resume work, cache results, route calls, and authorize access. The maintainers call it MCP’s largest revision since launch in the release post.

Amazon Web Services shipped an implementation path the same day. Amazon Bedrock AgentCore Gateway, a capability of Amazon Bedrock AgentCore, can advertise the new revision alongside earlier versions after one UpdateGateway call, according to the AWS implementation note.

Publication and platform support arrived together. Operators now have a migration decision.

The protocol session disappears

Previous MCP revisions began a connection with an initialize request and an initialized notification. The exchange established the protocol version, client information, and capabilities. Remote Streamable HTTP deployments could also mint an Mcp-Session-Id, tying later requests to protocol state created earlier in the connection.

That arrangement complicated horizontal scaling. A load balancer had to keep a client attached to the instance holding its session, or every instance had to consult a shared session store. Restarts, scale-to-zero events, and instance replacement all had to preserve that relationship.

MCP 2026-07-28 retires the initialization exchange and removes Mcp-Session-Id. Protocol version and client capabilities now travel in _meta on each request, client and server identity metadata can accompany individual messages, and clients may call the new server/discover RPC whenever they need the server’s current capabilities. The full list appears in the project’s 2026-07-28 changelog.

Because the information needed to interpret a request accompanies that request, any compatible instance can process it, allowing ordinary round-robin distribution across replaceable servers while eliminating the protocol session store that previously connected one call to the next.

The boundary is precise. MCP has become stateless at the protocol layer. Tools can still run workflows that last for hours, wait for human approval, update a database, or resume after an outage. Their state now has to live behind an explicit application interface.

Durable work moves behind a handle

The release documentation gives cross-call state a visible shape. A server that needs to preserve application state can mint a handle and return it as an ordinary tool argument. A later request presents that handle, and whichever instance receives the call resolves it against the application’s data layer.

This makes cross-call state explicit rather than connection-bound. The handle can point to a durable task record with an owner, authorization scope, status, result location, expiration policy, and recovery history. It can survive instance replacement because the instance itself carries no special claim on the work.

Tasks follow the same design. They have moved from the experimental core into the official io.modelcontextprotocol/tasks extension. The redesigned workflow uses tasks/get for polling and tasks/update for client input, while servers can return task handles from tool calls. The release post places Tasks alongside MCP Apps and Enterprise Managed Authorization in the formal extensions system.

Multi Round-Trip Requests cover work that pauses for additional input. The protocol defines an InputRequiredResult with resultType: "input_required"; the client gathers the requested information and retries the original call with inputResponses. The exchange travels as discrete requests that any compatible instance can accept.

Consider a tool that submits a purchase order. The downstream system commits the order, but the response disappears during a network failure. A retry may reach another MCP server instance. The new instance has zero connection memory, so correct recovery depends on a durable operation identifier, a recorded outcome, and replay rules in the tool’s application layer.

The handle supplies addressing, while a deduplication key and transaction record govern replay. Operators should define how every side-effecting tool behaves after timeouts, duplicate delivery, partial downstream completion, expired handles, and canceled tasks. “Exactly once” remains a business-system claim backed by storage and transaction design.

Task records also need a recovery state machine. Useful states might include accepted, running, waiting for input, completed, failed, canceled, and expired, with transitions committed before a response is returned. The protocol standardizes how clients continue the conversation. The server still owns the truth about whether the work happened.

Gateways can see the call

Stateless requests fit existing HTTP infrastructure better, and two additions make them easier to operate.

Streamable HTTP POST requests now carry Mcp-Method and, where applicable, Mcp-Name. A gateway can route, meter, rate-limit, and apply policy using headers instead of parsing the JSON-RPC body. AWS shows a request carrying Mcp-Method: tools/call and a tool name in its AgentCore Gateway example.

That creates useful control points. Expensive tools can receive separate quotas. Administrative tools can require stricter authorization. Traffic can be divided by method or tool before it reaches the server pool. Tool implementations should still validate the authenticated principal, arguments, and target resource at execution time.

List and resource-read responses also gain explicit cache instructions. Results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list carry ttlMs and a cacheScope of public or private, according to the changelog. Deterministic ordering for tools/list helps client caches and upstream prompt caches remain stable.

Caching now has a protocol vocabulary, along with a sharp failure mode. A shared cache that ignores private scope can expose a user-specific tool catalog or resource response to another principal. Cache keys should include the protocol version, server identity, method, relevant arguments, authorization identity, tenant boundary, and extension set whenever those fields can change the result.

The revision also documents propagation of traceparent, tracestate, and baggage through _meta. Distributed traces can follow a request through the client, gateway, interchangeable server instance, and downstream service even though the protocol connection no longer supplies continuity.

Authorization must follow every request

A session once offered a tempting place to remember who had connected and what the client could do. Stateless routing removes that hiding place. Each instance must be able to derive authorization from the current request and trusted identity infrastructure.

The revision hardens several parts of the OAuth 2.0 and OpenID Connect path. Authorization servers should include the RFC 9207 iss parameter in responses, and clients must validate a present issuer against the issuer recorded for the flow before redeeming the authorization code. Clients must bind persisted credentials to the authorization server that issued them and re-register when that server changes. Client registration also gains an explicit application_type, and step-up authorization accumulates previously granted scopes. These changes are listed in the official changelog.

Task handles deserve the same care as resource identifiers. Every lookup should bind the handle to the authenticated principal, tenant, tool, and current authorization policy. A valid handle presented by the wrong user should fail even when the task began under a legitimate session hours earlier.

Authorization context may also change while a task waits. Tokens expire. Roles change. Approval can be revoked. Operators need an explicit rule for whether resumed work uses the authority captured at creation, the caller’s current authority, or a narrowly scoped service grant recorded with the task. MCP standardizes the transport and authorization mechanics. Governance still decides which authority is acceptable.

Pin the date and test the responsibilities

MCP’s date-based revision is an API contract, and AgentCore Gateway makes coexistence possible. A gateway can advertise 2026-07-28 alongside 2025-11-25. Clients requesting the older revision keep the older behavior, while clients requesting 2026-07-28 receive the new semantics. AWS says a request for an unadvertised version receives HTTP 400 with error code -32022 and a list of supported versions. Requests that omit the version header default to 2025-03-26.

Deployments should pin the version explicitly because an omitted header selects the older 2025-03-26 revision.

The UpdateGateway call starts a migration whose production confidence still comes from compatibility tests. A sensible test plan covers:

  • Version negotiation: Pin every client, SDK, gateway, and server to an expected revision. Exercise explicit requests, omitted versions, unsupported versions, and mixed-version traffic through the same endpoint.
  • State inventory: Find every use of connection memory, session-local capability data, per-connection tool catalogs, and Mcp-Session-Id. Move durable business state behind server-minted handles.
  • Replay behavior: Inject timeouts after downstream commits, resend identical tool calls, and confirm that idempotency keys return the recorded result instead of repeating the side effect.
  • Task recovery: Kill an instance during each task state, route the next request elsewhere, and verify polling, updates, cancellation, expiration, and result retrieval.
  • Authorization: Test issuer validation, credential rebinding, scope step-up, token expiry, role changes, cross-tenant handles, and resumed tasks.
  • Cache isolation: Verify public and private behavior across users, tenants, protocol versions, capability changes, and tool-catalog updates.
  • Routing and tracing: Confirm that Mcp-Method, Mcp-Name, and JSON-RPC content agree, then follow trace context through the gateway and every downstream call.
  • Breaking details: Audit logging/setLevel, protocol-session assumptions, and clients matching the old -32002 resource error. The revision changes that error to JSON-RPC -32602.
  • Deprecations: Roots, Sampling, and Logging remain functional during a minimum twelve-month deprecation window, while new implementations should use their designated replacements.

The updated Tier 1 SDKs reduce protocol implementation work, yet they cannot decide where a company stores task state, how a tool deduplicates a financial action, which identity owns a handle, or how recovery proceeds after an ambiguous failure. The SDKs expose these application responsibilities but do not implement the company-specific storage, deduplication, ownership and recovery policies behind them.

As of July 29, mixed-version AgentCore Gateway deployments had no published operating record covering task recovery, duplicate side effects, issuer binding or private-cache isolation under the new revision.

The Signal is the public edge of a private practice. Sherpa points the same intelligence engine at one owner's business — competitors, suppliers, regulators, watched daily, graded and sourced. Work with a Sherpa →