Moving MCP servers to the 2026-07-28 specification

What changed in the 2026-07-28 revision

The changelog of the revision groups its changes as major, minor and deprecated. The ones that decide how much work a server needs are these.

Removed outright

• Protocol-level sessions and the Mcp-Session-Id header are gone from the Streamable HTTP transport, and list endpoints no longer vary per connection. A server that needs state across calls hands out its own handles and takes them as ordinary tool arguments (SEP-2567).
• The initialize handshake and notifications/initialized are gone. Every request now carries the protocol version and the client's capabilities in _meta, and the version a server does not support gets an UnsupportedProtocolVersionError (SEP-2575).
• Servers must implement server/discover, an RPC that advertises their supported protocol versions, capabilities and identity (SEP-2575).
• ping, logging/setLevel and notifications/roots/list_changed are removed. The log level is set per request with a _meta key, and a server must not send log notifications for a request that did not ask for them (SEP-2575).
• SSE stream resumability is removed: a broken response stream loses the request in flight, and the client sends it again as a new request (SEP-2575).

Replaced or changed

• Experimental tasks moved out of the core protocol into an official extension, io.modelcontextprotocol/tasks, that polls with tasks/get (SEP-2663).
• Server-initiated requests such as roots/list, sampling/createMessage and elicitation/create give way to multi round-trip requests: the server returns an input_required result and the client retries the request with the answers (SEP-2322). Every result now carries a resultType field.
• tools/list, prompts/list and resources/list results, among others, must carry ttlMs and cacheScope so that clients can cache them (SEP-2549).
• Authorization servers should send the iss parameter in authorization responses, and clients must check a present one against the issuer they recorded (SEP-2468). Trace context is carried in _meta keys such as traceparent (SEP-414).

Marked deprecated

A deprecated feature keeps working, but the specification says new implementations should not adopt it and existing ones should migrate. The revision deprecates Roots, Sampling and Logging together (SEP-2577), and OAuth Dynamic Client Registration in favour of Client ID Metadata Documents (PR 2858). It also reclassifies the older HTTP+SSE transport as deprecated under its new lifecycle policy (SEP-2596). The specification keeps a registry of deprecated features that lists each of them with its migration path.

The date that matters

The date in the home page's countdown, about 28 July 2027, comes from the specification's feature lifecycle and deprecation policy, adopted by SEP-2596. The policy says a deprecated feature stays deprecated for at least twelve months, counted from the release of the revision that first marks it. The deprecated registry applies that to Roots, Sampling, Logging and Dynamic Client Registration: their earliest removal is the first revision released on or after that date.

Three things follow from the policy's own wording, and they are easy to misread.

• It is a minimum. The features deprecated by the 2026-07-28 revision can be removed no earlier than about 28 July 2027, and the policy adds that a feature may stay deprecated for much longer. Removal is decided when a revision is prepared.
• It applies only to the features the revision marks deprecated. The HTTP+SSE transport is on its own schedule in the registry, not on this date.
• Changes the revision made outright, such as removing protocol sessions and the initialize handshake, apply from the revision itself. A client that speaks only 2026-07-28 will not open a session with your server, whatever the date.

A server can keep serving older clients for a while. Plan the move around the revision, and treat the date as the point after which deprecated features may disappear from the specification.

A migration checklist for a server owner

Work through the steps in this order. Each step names the Spellwarden rule that reports it, with a link to the rule's page, and the rules read only what a server shows from outside. The migration checklist Spellwarden writes for a server holds only the steps that apply to it, in the scanner's own order, and the HTTPS and tool description steps are reported by their rules, not as checklist items.

Transport and security of the connection

1. Serve the endpoint over HTTPS only. A plain http:// endpoint is not probed at all; SW-MCP-009 reports it.
2. Move from HTTP+SSE to Streamable HTTP. SW-MCP-004 reports a server that still answers as HTTP+SSE.

The removed session and handshake

1. Add server/discover and stop requiring initialize. SW-MCP-007 reports a server that answers initialize but not server/discover.
2. Remove sessions: stop issuing Mcp-Session-Id and move any cross-call state into handles that your tools take as arguments. SW-MCP-006 reports the header.
3. Read the protocol version and the client's capabilities from _meta on each request, and advertise 2026-07-28 or later. SW-MCP-005 reports an older version.
4. Replace Sampling, Roots and Logging: use an input_required result where you asked the client for a model call, and the per-request log level where you logged. SW-MCP-008 reports a server that still declares them.
5. Move long jobs to the Tasks extension if a tool runs for minutes. The checklist reports a long-running tool when it can see one; no rule is raised for it.
6. Set ttlMs and cacheScope on list results, and carry traceparent in _meta. These are checklist steps only, because they are not security findings.

Authentication

1. Put OAuth in front of the tools. SW-MCP-001 reports a server that lists its tools without authentication, and SW-MCP-002 one that relies on a static key.
2. Publish OAuth Protected Resource Metadata (RFC 9728), use resource indicators (RFC 8707), and register your client with a Client ID Metadata Document instead of Dynamic Client Registration. SW-MCP-003 reports a server whose authorization server offers registration and does not support Client ID Metadata Documents.
3. Check that the metadata is coherent: the authorization server's issuer matches where its metadata lives, and the resource names your endpoint. SW-MCP-010 reports metadata that is missing or does not match. The specification now has clients check iss on the way back.

Tool descriptions

1. Read your tool descriptions as a model reads them. Text that steers the model towards the tool is reported at medium, and text that conceals, overrides or injects instructions at high, by SW-MCP-011.
2. Scan again. When nothing is left on the list, a server is ready.

Checking your servers with Spellwarden

Spellwarden checks a server against this revision for you and writes the checklist above for it. Add the server's endpoint in the dashboard, and Spellwarden sends the protocol's own unauthenticated requests to it, never a credential, and records its transport, its authentication, the protocol version it advertises and which deprecated features it still uses. A server counts as ready when it advertises 2026-07-28 or later, uses a current OAuth flow and uses no deprecated feature; every other probed server is marked to migrate, and a server that runs locally over stdio is marked not probeable.

The migration report of each server holds the ordered checklist and the days left to the planning date. Check MCP servers and plan their migration describes the report and what the probe reads. The same checks run on your own machine or in your pipeline with the open-source scanner's --probe option, described in Open-source scanner, CI wrappers and Infra Pack. The server checks are part of the Team and Enterprise plans.

Open the MCP servers page in the live demo

Once a server is ready, an Enterprise organisation can admit it to its private registry, which keeps a server that is still moving on a grace period and lists only what passes the organisation's policy.

Getting help with the move

If your team would rather hand the work over, Spellwarden offers a fixed-fee migration: a ten-day engagement by an EU team that moves up to five servers to the stateless specification with OAuth, delivers a migration report for each server and admits the result to your private registry. The migration section of the home page describes it and has the booking button.

Related guides

• Check MCP servers and plan their migration
• The private registry
• Scanner rules