MCP 2026-07-28: what changes for AI agent builders

Published 2 October 2026 · Updated 2 October 2026

In short. The MCP 2026-07-28 revision makes the protocol stateless: no sessions or handshake, and every request carries its version and capabilities. Agent builders move state into explicit, authorised handles, adopt OAuth with Protected Resource Metadata and update their SDKs. Roots, Sampling, Logging and HTTP+SSE remain for at least 12 months.

On 28 July 2026 the 2026-07-28 revision of the Model Context Protocol (MCP) was released: the protocol an AI agent uses to work with external tools and data. The official blog describes it as a shift from a stateful, bidirectional protocol to a stateless request-and-response one: each request can reach any instance behind an ordinary load balancer. Source: MCP blog and changelog.

What has changed

  • No sessions or handshake. The Mcp-Session-Id header and the initialize exchange are removed. Each request carries the protocol version and the client capabilities in _meta. A new method, server/discover, announces the server’s versions and capabilities.
  • Simpler Streamable HTTP transport. Each message is a POST to a single endpoint; resumption of SSE streams is removed. Headers such as Mcp-Method and Mcp-Name appear, useful to load balancers and application firewalls.
  • Server requests to the client. Roots, Sampling and Elicitation no longer travel as requests from the server: the server replies with an input_required result and the client retries with the answers (a pattern called Multi Round-Trip Requests).
  • Caching. List results (tools/list and similar) carry ttlMs and cacheScope.
  • Tasks. The experimental tasks leave the core and become an official extension.

Authentication

Authorisation remains optional. If you use HTTP, the specification points to OAuth 2.1 with Protected Resource Metadata (RFC 9728) and the resource parameter (RFC 8707). The preferred client registration moves to Client ID Metadata Documents; Dynamic Client Registration is deprecated. The server must verify that the token was issued for it and must not forward tokens it receives.

What to migrate, in order

  1. State inventory. If your server kept per-session state, move the state into explicit handles (for example a shopping cart identifier) passed as arguments, with authorisation checked on every call.
  2. SDK updates. The top-tier SDKs are TypeScript, Python, C#, Go, Rust and Ruby; for TypeScript and Python there are version 2 releases that support the new revision. Check each SDK’s migration guide, because dates and version numbers must be reconfirmed on the release pages.
  3. Compatibility. A modern client does not talk to a legacy-only server, and vice versa. During the transition you need clients and servers that support both eras.
  4. User input. Review the points where the server asked the client for data: they must be rewritten using the new input_required schema.
  5. Deprecations. Roots, Sampling, Logging and HTTP+SSE remain for at least twelve months: plan your exit.

Security risks to check

The official Security Best Practices page lists, among others: confused deputy in OAuth proxies, token forwarding (prohibited), SSRF in OAuth discovery, hijacking of state handles (owning a handle is not authentication) and non-isolated local MCP servers. Tool annotations should be treated as untrusted unless the server is trusted, and for sensitive actions the specification recommends a human in the loop.

What is not verified

The exact dates and versions of the SDK releases on GitHub and the default values of tool annotations were not confirmed against a primary source in this note. Before migrating, read the official guides for the SDKs you use.

To design an agent with least privilege, evaluations and controls, see AI agents and automation with LLMs.

Need a hand?

If you want to apply these points to your case, tell me in a few lines.

Let's talk