The 2026 MCP specification is no longer upcoming work: the current revision, dated 2026-07-28, is published at modelcontextprotocol.io. It is a bigger change than a typical revision, because it removes the connection handshake and the protocol-level sessions that earlier versions were built around. This post covers what changed in plain terms, and what to check in an integration you already run. The protocol is still moving, so treat the official specification as the final word.
Where the ecosystem actually is right now
MCP is no longer purely an early-adopter bet. A meaningful and growing number of enterprise AI teams are running it in production, and major cloud and API gateway vendors have been building native MCP support directly into their platforms. If you evaluated MCP a year ago and decided it wasn't mature enough for your use case, it's worth re-evaluating. Real, visible progress has been made, even if "mature enough" still depends on your specific requirements.
What changed in the 2026-07-28 revision
MCP is now stateless
Earlier revisions opened every connection with an initialize handshake and, over HTTP, tracked a session with an Mcp-Session-Id header. The 2026-07-28 revision removes both. Every request now carries its protocol version and the client's capabilities, and the server handles each request on its own. A server that genuinely needs state across calls uses explicit handles that it creates and the client passes back as ordinary tool arguments.
A new server/discover call, which every server must implement, lets a client ask which protocol versions, capabilities and identity a server supports before it sends anything else; calling it is optional. For operations, this is the useful part: a server that does not hold per-connection state is much easier to scale horizontally, put behind a load balancer and recover after a failure.
Transport and notification changes
Server-to-client change notifications now go through one opt-in call, subscriptions/listen, which replaces the separate HTTP GET endpoint and the resource subscribe calls. Resuming a broken stream is gone: if a response stream breaks, the in-flight request is lost and the client re-sends it as a new request. ping, logging/setLevel and the roots-changed notification are removed, and log level is set on each request instead.
Server-initiated requests and long-running work
Requests that a server used to initiate itself, such as asking the client for input or a model completion, are replaced by a multi round-trip pattern. The server returns an input_required result describing what it needs, and the client retries the original request with the answers. Experimental tasks for long-running operations move out of the core protocol into an official extension.
Deprecations
Roots, Sampling and Logging are deprecated: they keep working during a deprecation window, but new implementations should not add them. The older HTTP+SSE transport is formally deprecated in favor of Streamable HTTP, and OAuth Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. The specification now has a feature lifecycle policy with a deprecation window of at least twelve months (at least ninety days under an expedited exception), so deprecated features are not removed overnight.
Authorization and caching
Authorization servers should include the iss parameter in authorization responses, and clients must validate it when it is present. Clients must also keep client credentials tied to the authorization server that issued them and re-register if it changes. Separately, list results now carry caching hints (ttlMs and cacheScope), and servers should return tools in a stable order so clients can cache them.
Does this affect an existing MCP integration you already have?
It depends on how it was built. A few things are worth checking:
- Does your server rely on sessions or the initialize handshake? Then it needs changes for this revision. The specification lets clients and servers support several protocol versions at once, and describes how to stay compatible with the handshake-based revisions (2025-11-25 and earlier), so you can migrate in steps rather than all at once.
- Do you use Roots, Sampling or Logging? They still work, but they are deprecated. The specification suggests passing directories or files through tool parameters instead of Roots, calling model provider APIs directly instead of Sampling, and logging to stderr or using OpenTelemetry instead of Logging.
- Are you still on HTTP+SSE or Dynamic Client Registration? Both are deprecated. Plan the move to Streamable HTTP and to Client ID Metadata Documents.
- Did you build your own OAuth or credential handling around MCP? Check it against the new issuer-validation and credential-binding requirements.
- Are you using a vendor's MCP gateway, SDK or hosted server? Ask which specification revision it supports before assuming compatibility. Support for a new revision can take time to arrive.
What this means if you haven't built with MCP yet
Whether MCP is mature enough to build on is less of a question than it was a year ago, and the open questions now are more "which tools should we expose, and with what permission model?" That is a scoping question as much as a technology-risk one. One caution: a revision that removes the handshake is a reminder that the protocol is still changing. Pin the specification revision you build against, and plan for upgrades.
How we approach this
We build MCP deployments against the current spec, with permission scoping and governance designed in from the start rather than retrofitted, We revisit existing deployments against spec updates as part of ongoing engagements, not as a separate migration project you have to initiate yourself.
Sources: MCP specification versioning, MCP 2026-07-28 key changes.