research: track MCP 2026-07-28 spec's breaking stateless redesign and rmcp's migration path

[bug-ops]

Description

The Model Context Protocol project has a release candidate for spec version 2026-07-28, described as "the largest revision of the protocol since launch." mcp-execution's entire pipeline depends on rmcp (the official Rust SDK) for the client handshake and tool discovery — Introspector::discover_server() (crates/mcp-introspector/src/lib.rs) is explicitly flagged as a critical path in .claude/rules/continuous-improvement.md. This is a forward-looking tracking item, not an immediate action: no code, dependency, or config change is needed today.

Key breaking changes in the 2026-07-28 RC (cross-verified across 3+ independent sources)

• initialize/initialized handshake removed entirely — protocol version, client identity, and capabilities move to per-request _meta fields.
• Mcp-Session-Id header eliminated (SEP-2567) — protocol goes fully stateless; no sticky routing / shared session store needed.
• tools/list and resource-read responses gain ttlMs and cacheScope metadata (SEP-2549) — clients get an authoritative cache-freshness signal, replacing reliance on long-lived SSE streams for list-changed notifications.
• Tool schemas gain full JSON Schema 2020-12 support (oneOf/anyOf/allOf, conditionals, $ref).
• Tasks extension graduates from experimental to core (tasks/get/tasks/update/tasks/cancel replace held-open SSE for long-running calls).
• Missing-resource error code changes from -32002 to standard JSON-RPC -32602.

Timeline

• RC locked: 2026-05-21
• Final spec publishes: 2026-07-28 (~3 weeks out)
• 10-week SDK validation window follows; rmcp (Tier 1 SDK) expected to ship support within it (roughly by early October 2026)

Why this matters here

1. When rmcp adds 2026-07-28 support it will very likely require a major version bump (precedent: rmcp 1.x -> 2.x for a smaller spec alignment, see chore: update rmcp 2.1.0 -> 2.2.0 and transitive patch/minor bumps #162) — this project's dependency monitoring should watch for it rather than be surprised by it.
2. The new ttlMs/cacheScope fields on tools/list are a potential opportunistic enhancement to the introspector's ServerInfo/ToolInfo caching layer once upstream servers advertise them — could inform staleness detection instead of relying purely on manual generate re-runs.
3. No current MCP servers this project talks to speak 2026-07-28 yet, and rmcp 2.2.0 (latest as of this cycle) has not announced support — so this is pure awareness/tracking for now.

Expected outcome

A documented tracking plan for reassessing discover_server() compatibility once rmcp ships 2026-07-28 support, plus an opportunistic evaluation of the ttlMs/cacheScope caching enhancement at that time.

Spec

.local/specs/002-mcp-2026-07-28-spec-stateless-migration/spec.md

Sources

• https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• https://github.com/modelcontextprotocol/rust-sdk/releases
• Corroborating coverage: Stacktree, byteiota, WorkOS (independently confirm the handshake/session removal and July 28 date)

[bug-ops]

Follow-up check (CI-013, 2026-07-09, ~a few hours after this issue was filed): no material change in the spec's status itself — still an RC, locked 2026-05-21, targeting final publication 2026-07-28. Cross-checked against the MCP blog and confirmed the "current finalized version remains 2025-11-25" framing is unchanged.

New detail worth tracking: rmcp's own SEP-2575 (stateless) tracking issue (rust-sdk#869) was closed 2026-07-01, with incremental scaffolding ("add SEP-2575 meta helpers", rust-sdk#942/#943) already merged into rmcp 2.1.0 (released 2026-07-02). However the companion SEP-2567 (sessionless/explicit state handles, rust-sdk#870) is still open and unassigned, and rmcp 2.2.0's changelog (released 2026-07-08, the version this repo would pick up via #162) contains no handshake-removal or server/discover/messages/listen work — just PKCE enforcement and conformance fixes. So: rmcp has started laying groundwork for the 2026-07-28 spec but has not shipped the breaking stateless behavior yet. This is consistent with this issue's original "likely by early October 2026" estimate — no change needed to the tracking plan, just confirmation it's still on track.

No action needed this cycle.