MCP spec timeline: 2025-11-25, RC on May 29, stable on July 28, 2026
The MCP 2026-07-28 spec went stable on July 28, 2026, 60 days after its May 29 RC, replacing 2025-11-25. Dates, and how to check what you run.
MCP 2026-07-28 is the stable spec: the GitHub releases page lists it as stable, released July 28, 2026, after a release candidate on May 29, 2026. The previous stable version was 2025-11-25. From the RC to stable is 60 days, and as of 2026-10-03 the stable spec is 67 days old. Source: the MCP project's releases page, read 2026-10-03.
The dates
Version names in MCP are dates. The table keeps only what the releases page states, plus two intervals worked out from those dates.
| Version | Status | Date |
|---|---|---|
| 2025-11-25 | Previous stable | as listed on the releases page |
| 2026-07-28 RC | Release candidate | May 29, 2026 |
| 2026-07-28 | Stable | July 28, 2026 |
What the new version changes in one list
The changelog is long. For a media-generation integration the changes that matter most are these:
- No protocol-level sessions, no initialize handshake, and no Mcp-Session-Id header.
- A new required server/discover call.
- subscriptions/listen replaces the GET endpoint and resources/subscribe.
- Tasks become an official extension, polled with tasks/get.
- Roots, Sampling and Logging are deprecated, and HTTP+SSE is reclassified as Deprecated.
- Dynamic client registration is deprecated in favor of Client ID Metadata Documents.
A stable spec is not a stable fleet
A spec going stable does not mean every client and server speaks it that day. Clients ship on their own schedules and often keep the older version as a default for a while, and servers move when their maintainers choose. Assume a mixed fleet for the whole twelve-month minimum deprecation window the spec sets for the deprecated features.
The Sume docs do not state which protocol version the hosted server speaks. So test the actual connection instead of reading a version from a post, including this one.
Check what you are running
Connect, then ask the agent to call mcp_health and tools_list, which the Sume quickstart recommends as first calls. If both work, the connection is good regardless of version, and you can then check your client's own documentation for its protocol support. Pin the client version in CI so a silent upgrade does not change protocol behavior under a scheduled job.
claude mcp add --transport http sume https://mcp.sume.com/mcp
claude mcp login sume
# in the session: call mcp_health, then tools_listSources
Related posts
More in Developers
- MCP tasks extension and Sume job statuses: mapping for render tools
In MCP 2026-07-28 tasks are an extension polled with tasks/get. Map task handles, polling, update and list onto Sume job ids, status reads and jobs_cancel.
- MCP TS SDK 2.3 enforces one server per request: where state lives
TypeScript SDK 2.3.0 enforces one server instance per request. For a media tool that means job state belongs in job ids, as Sume's jobs_wait does.
- Next.js 16.3.8 dev-server MCP disclosure and where the Sume key lives
Next.js 16.3.8 fixes a low-severity dev-server MCP disclosure and a high-severity image SSRF. How to keep a Sume API key server-side as you upgrade.
- Next.js 16.3.8 fixes ISR cache poisoning: keep job pages dynamic
Next.js v16.3.8 fixes cache poisoning in SSG and ISR and Draft Mode leaks. Why a Sume job status page should stay dynamic and uncached, whatever the version.
Written by Sume