What changed
Announced on 28 July 2026, the shipped MCP 2026-07-28 revision settles what its release candidate left open, and its quietest answer is the one that surprised me. Tasks moved out of the experimental core into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update (SEP-2663) 1. Change notifications moved off the old HTTP GET endpoint onto a single subscriptions/listen stream that clients opt into per notification type 1. And the protocol version now travels in a request header: every request carries Mcp-Protocol-Version 2.
The header decides which protocol you get
Covering the release candidate, I assumed any version disagreement would announce itself. On AWS’s gateway, one kind of disagreement does not. AWS describes what its AgentCore Gateway does with that header 2:
| Request | What the gateway does |
|---|---|
Version listed in supportedVersions | Serves the request in that version |
| Version not supported | HTTP 400, code -32022, and the supported list |
| No header at all | Defaults to 2025-03-26 |
Two rows are loud. The third costs a day: a client that forgets the header gets no error there, just a working connection to a revision from sixteen months earlier, with every capability it was written against quietly missing.
Tasks are surface you have to ask for
An extension is negotiated, not assumed. Long-running work modelled on the core task primitives now depends on the peer implementing io.modelcontextprotocol/tasks 1, and tasks/update is API you have never called 1. Notifications cut the other way: one subscriptions/listen stream with per-type opt-in 1 is less code than an endpoint you poll.
Impact on your team
If you ship an MCP client, send Mcp-Protocol-Version on every request this week and assert it in a test, because the failure it prevents is silent 2. If you ship a server, return your supported versions on the rejection rather than a bare 400, as that gateway does 2. On Tasks I would not port yet: wait until the peers you call advertise the extension, then adopt tasks/get before tasks/update 1. The notification move is worth doing now, since subscriptions/listen replaces polling code you already maintain 1.