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 step-up scopes (SEP-2350) vs Sume's mcp:write re-consent
The MCP 2026-07-28 draft adds step-up scope accumulation. On Sume today, getting from mcp:read to mcp:write means a new consent and a new token.
- 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 tasks/get vs Sume's Agent Completion status_url polling
The MCP 2026-07-28 tasks extension polls by handle with tasks/get. Sume's Agent Completions poll a status_url until next_action is not poll_status.
- MCP tool ran twice: idempotency_key saves your Sume render
Claude Code fixed MCP tool calls that sometimes ran twice on large results. Sume's paid MCP tools require an idempotency_key so a repeat does not bill twice.
Written by Sume