Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, email [email protected] and we’ll put it right.
MCP protocol Scoring Remote servers Packages Building

MCP spec 2026-07-28 (current): what changed

2026-07-28 is the current revision of the Model Context Protocol specification, published on 28 July 2026. It is the largest revision since the protocol launched, and it is the version VerifyMCP treats as up to date: a server that speaks it earns full protocol-recency credit when we score it.

It is also the first revision that is not backwards compatible on the wire. Everything up to and including 2025-11-25 opened a connection with an initialize handshake. This revision removes that handshake entirely, so a client and a server on opposite sides of the line cannot talk to each other at all. The spec calls the two halves legacy and modern.

What changed versus 2025-11-25

The major changes, as listed in the official changelog, are:

  • A stateless core. The initialize / notifications/initialized handshake is gone. Every request now carries its own protocol version and client capabilities in _meta, under the keys io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. A version the server does not implement comes back as an UnsupportedProtocolVersionError (-32022) listing the versions it does support.
  • No more sessions. The Mcp-Session-Id header and protocol-level sessions are removed from the Streamable HTTP transport, and list endpoints no longer vary per connection. A server that needs state across calls now mints an explicit handle and passes it as an ordinary tool argument.
  • server/discover. Servers must implement a new discovery RPC that reports their supported protocol versions, capabilities and identity in one call. Clients may call it up front, and on stdio it doubles as the backwards-compatibility probe.
  • Multi Round-Trip Requests (MRTR) replace server-initiated requests. Rather than sending its own sampling/createMessage or elicitation/create, a server returns an InputRequiredResult carrying inputRequests, and the client retries the original request with inputResponses. Every result now carries a resultType of either "complete" or "input_required"; a result from an earlier-protocol server that omits the field must be read as "complete".
  • subscriptions/listen replaces the HTTP GET endpoint and the resources/subscribe pair, as a single long-lived POST-response stream that clients opt in to per notification type.
  • Official extensions. MCP Apps (interactive UI) and MCP Tasks (long-running work) graduated out of the core protocol into a formal extensions framework, advertised through a new extensions field on client and server capabilities.
  • Response caching. List and read results now carry ttlMs and cacheScope, so clients can cache instead of polling.
  • Standard request headers. Streamable HTTP POSTs must mirror the JSON-RPC method into Mcp-Method, and the tool or resource name into Mcp-Name, so intermediaries can route without parsing the body. A server rejects a request whose headers disagree with its body.
  • Removals: ping, logging/setLevel, notifications/roots/list_changed, and SSE stream resumability (Last-Event-ID).

What is now deprecated

This revision also adopted a formal feature lifecycle and deprecation policy, with a minimum twelve-month deprecation window and a published registry. Newly deprecated, and still fully functional in the meantime:

  • Roots, Sampling and Logging. Pass directories through tool parameters or resource URIs instead of Roots, integrate with an LLM provider directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging.
  • The HTTP+SSE transport, deprecated since 2025-03-26, is now classified Deprecated under the policy and is eligible for removal in a future revision. Migrate to Streamable HTTP.
  • OAuth Dynamic Client Registration (RFC 7591), in favour of Client ID Metadata Documents, where the client ID is an HTTPS URL the authorisation server resolves on demand. Authorisation servers advertise support with client_id_metadata_document_supported.

Why it matters

The stateless core is the headline: without a handshake or a session, an MCP server is an ordinary request/response HTTP service, so it can run on serverless and edge infrastructure and scale horizontally without sticky routing. That is what most of the removals in this revision exist to make possible.

The cost is a real migration. A client that only speaks initialize cannot reach a modern-only server, and it has no way to fall forward, so the spec expects clients to carry both eras for a while: try a modern request, inspect the body of a 4xx before falling back, and treat a recognised modern error as proof the server is modern rather than a reason to retry as legacy.

Because it is the current revision, a server that speaks 2026-07-28 earns full protocol-recency credit in the remote endpoint rubric. 2025-11-25 remains inside the supported window and also keeps full marks. If yours negotiates something older, see negotiate a current protocol version.

Read the full revision

modelcontextprotocol.io/specification/2026-07-28 (or the changelog).

Previous

Written by Stuart Blackler.