VerifyMCP now supports MCP 2026-07-28

The Model Context Protocol shipped 2026-07-28 today, its largest revision since launch. VerifyMCP speaks it as of this release: we probe the new discovery call, score the new revision as the current spec, and still handle every older server exactly as before.

The initialize handshake is gone. This is the first MCP revision that is not backwards compatible on the wire, and a client that speaks only the old shape cannot talk to a server that speaks only the new one. The spec calls the two halves legacy and modern.

What actually changed

The protocol became stateless. There is no opening handshake and no protocol-level session. Every request now carries its own protocol version and client capabilities in _meta, and the Mcp-Session-Id header has been removed from the Streamable HTTP transport entirely. A server that needs state across calls mints an explicit handle and passes it back as an ordinary tool argument.

In place of the handshake, servers must implement a new server/discover call that reports their supported protocol versions, capabilities and identity in one response. If a client asks for a version a server does not implement, it gets back an UnsupportedProtocolVersionError naming the versions that would work.

Around that core:

• Multi Round-Trip Requests replace server-initiated requests. Instead of sending its own sampling or elicitation request, a server returns an InputRequiredResult, and the client retries the original call with the answers. Every result now carries a resultType, either "complete" or "input_required".
• Apps and Tasks became official extensions, moving out of the core protocol into a formal extensions framework.
• Results can be cached. List and read results carry ttlMs and cacheScope, so clients can stop polling.
• Authorisation got closer to production OAuth, which is what makes Entra and Okta integrations work without workarounds.
• Roots, Sampling, Logging, the HTTP+SSE transport and Dynamic Client Registration are all now deprecated, under a new lifecycle policy with a minimum twelve-month window before anything can be removed.

The practical upside of all this is deployment. Without a handshake or a session, an MCP server is an ordinary request/response HTTP service, so it runs on serverless and edge infrastructure and scales horizontally without sticky routing. Most of the removals in this revision exist to make that possible.

What VerifyMCP does now

We probe server/discover first, and fall back to initialize when the answer is not a recognised modern reply. That ordering is the spec’s own algorithm for clients that have to talk to both eras, and the detail that matters is what happens on a 4xx: modern servers also use 400 for their own protocol errors, so we read the response body before deciding. A recognised modern error code proves the server is modern and means “retry”, never “fall back”.

Getting this wrong would not have been a small thing. Until today, our probes proved a server was MCP by parsing an initialize result. A server implementing only the new revision answers that with an error, so it would have scored zero on transport modernity and come out unreadable across every category that depends on reading the schema. We would have been marking down the most up-to-date servers in the registry, which is the exact opposite of the job. Fixing that is the real reason this shipped today rather than next month.

Two smaller things came out of the same work. Modern requests now mirror their method and name into the Mcp-Method and Mcp-Name headers, which the spec requires and servers validate against the body. And our tool-call auth probe learned about resultType: an input_required result means the server is asking for input before it acts, so treating it as a completed call would have published “this server leaves its call path wide open” about a server doing precisely the opposite.

Which scores move, and why

Three changes move published numbers today. None of them is a server changing. All of them are the rubric catching up with the spec, so they land under a new rubric version and each affected component gets a single changelog entry saying the ruler moved. The category weights sitting around these signals were reset shortly afterwards, when the shared core landed, which does not alter any of the per-signal changes below. How we score always describes the current rubric, and the scoring changelog records every change we have made to it.

2025-06-18 left the supported window. We give full protocol-recency marks to the current revision and the one before it, so implementers get a release cycle to upgrade rather than dropping on day one. With 2026-07-28 as current, that window is now 2026-07-28 and 2025-11-25. Servers on 2025-06-18 go from full marks to partial credit, and their verdict changes from supported to outdated. If that is you, nothing about your server got worse, you are simply two revisions behind now instead of one.

The SSE transport ordinal is capped, from 0.6 to 0.4. HTTP+SSE has been deprecated since 2025-03-26, but this revision reclassified it as Deprecated under the new lifecycle policy, which makes it eligible for removal in a future revision. That is a firmer statement than “there is something newer”, and the score reflects it.

Authorisation servers offering only Dynamic Client Registration are capped at the same 0.4. RFC 7591 is now deprecated in favour of Client ID Metadata Documents, where your client ID is just an HTTPS URL the authorisation server fetches on demand. Advertising client_id_metadata_document_supported earns full marks. Deprecated-but-working costs the same 0.4 in both places on purpose, so “deprecated” means one consistent thing across the rubric.

Two cases deliberately score nothing at all, and both are worth stating plainly. If we could not read your authorisation server’s metadata, we emit no signal, because docking you for our own network failure would be dishonest. And if your authorisation server advertises neither mechanism, you are pre-registering clients out of band. That is priority one in the spec’s own ordering and a tighter posture than open registration, so marking it down would mean paying servers to expose a registration endpoint. We are not going to do that.

What to do about it

If you maintain a server, the honest answer is that there is no rush on the wire change and some urgency on the reading. Moving to 2026-07-28 is a breaking change for your clients, not a version bump, so check what connects to you before you ship it. The twelve-month deprecation window means nothing you rely on disappears this year.

What is worth doing this week is cheaper: upgrade your SDK so you are on 2025-11-25 at minimum, move off HTTP+SSE to Streamable HTTP if you have not already, and if you run your own authorisation server, look at whether it can advertise Client ID Metadata Document support.

Our spec versions page tracks every revision and what changed in each, and the 2026-07-28 page has the full breakdown. If your score moved today and you want to know exactly which signal did it, every component’s changelog names the reason code.