Skip to content

MCP 2026-07-28 — what it means for muster

This folder is muster's working analysis of the MCP 2026-07-28 release candidate, "the largest revision of the protocol since launch." The release candidate is locked as of May 21, 2026 and the final specification is due July 28, 2026. The three artefacts every reader should keep open alongside these docs are:

Each section document below is grounded in the upstream SEP/PR text (read via gh against modelcontextprotocol/modelcontextprotocol), the announcement, and the relevant external standards, then cross-checked against muster's own code. Every section follows the same six-part template — what the spec says, linked SEPs/PRs, muster impact, required changes, open questions, and a References list — so they are easy to skim.

Executive summary

muster is, by design, both an inbound MCP server (for clients like Cursor, Claude Code, and the muster agent's own MCP-server mode) and an outbound MCP client (for every aggregated upstream MCP server). The 2026-07-28 release touches both surfaces, but very unevenly:

  • The stateless rework is the dominant change. Removing the initialize handshake, the Mcp-Session-Id header, the long-lived GET SSE stream, and the free-floating server-to-client channel — and replacing them with per-request _meta, header-level routing, server/discover, multi-round-trip InputRequiredResult, and ttlMs / cacheScope caching — rewires the parts of muster that are built around the protocol-level session (the connection pool, the capability store, the session-auth store, the inbound transport, and the outbound clients). This is the highest-blast-radius section by far.
  • Extensions become a first-class, negotiated concept, and MCP Apps and Tasks are the two extensions that ship on top of that framework. For muster the framework lands first as a passthrough requirement (forward an opaque extensions map both ways) and second as a per-extension "do we support this natively?" decision.
  • Authorization is hardened with six OAuth/OIDC SEPs. muster's auth code is mostly aligned already (CIMD client_id, issuer-keyed token store, agent-side iss validation); the main concrete gap is server-side iss validation in the aggregator's OAuth proxy.
  • Roots, Sampling, and Logging are deprecated — and muster implements none of them over MCP today, so this is a policy commitment and a non-event for the code base. muster's logging is already the OpenTelemetry pipeline the spec names as the replacement.
  • Tool schemas adopt full JSON Schema 2020-12 and the resource-not-found error code moves from -32002 to -32602. muster's schema plumbing is already permissive and emits no literal -32002, so this is mostly a mark3labs/mcp-go dependency bump plus "don't regress" guards.
  • Governance and timeline (the feature-lifecycle policy, the conformance gate, the SDK tier system, the RC → Final calendar) are pure process for muster, but they hand muster a usable external conformance signal and a vocabulary for tracking feature state.

The single most important strategic fact spanning every section: muster runs on github.com/mark3labs/mcp-go (v0.54.1), which is not one of the tier-rated official SDKs. The Tier 1 "ship by July 28" guarantee applies to modelcontextprotocol/go-sdk, not to muster's dependency. muster's adoption clock is mcp-go's clock, not the spec's — so most wire-level work is gated on mcp-go shipping a 2026-07-28-aware release (or muster migrating to the official Go SDK).

Document set

Doc Section Primary SEPs / PRs
01-stateless-protocol.md Stateless protocol (handshake/session removal, server-to-client restructuring, headers/caching, tracing) SEP-2575, 2567, 2260, 2322, 2243, 2549, 414
02-extensions-first-class.md Extensions become first-class (the framework) SEP-2133
03-mcp-apps.md MCP Apps (server-rendered UIs) SEP-1865
04-tasks-extension.md Tasks graduates to an extension SEP-2663
05-authorization-hardening.md Authorization hardening SEP-2468, 837, 2352, 2207, 2350, 2351
06-deprecations-roots-sampling-logging.md Roots / Sampling / Logging deprecated SEP-2577 (+ 2596)
07-json-schema-2020-12.md Full JSON Schema 2020-12 for tools SEP-2106, 2164
08-protocol-evolution.md How the protocol evolves from here (governance) SEP-2596, 2484, 1730/#1777
09-release-timeline.md Release timeline and validation (process/calendar)

These docs are the seed material for GitHub issues, not a commitment to a particular implementation. No muster code, schema.json, or Go file is changed by this folder.

Risk / effort overview

Per section, an at-a-glance read of blast radius, effort, and what gates the work. Highest impact first.

  • 01 Stateless protocol — highest risk, highest effort, mostly gated. Touches the session layer (internal/aggregator/session_connection_pool.go, capability_store.go, session_auth_store.go and their Valkey variants), the inbound transport (server.go, connection_helper.go), and every outbound client (internal/mcpserver/client_*.go). Most of it is gated on mcp-go speaking the new transport; the internal session-model refactor is the one large ungated piece that can start now.
  • 05 Authorization hardening — medium risk, medium effort, mostly ungated. Concentrated in muster's own OAuth code (internal/oauth/, pkg/oauth/, internal/agent/oauth/). Much is already aligned; the highest-priority concrete gap is server-side iss validation in internal/oauth/handler.go. Independent of mcp-go.
  • 04 Tasks extension — medium risk, high effort, gated. muster's workflow engine (internal/workflow/) already behaves like a Tasks server (durable execution_id, status enum, lookup endpoints); mapping it onto tasks/get / tasks/update / tasks/cancel, adding input_required / cancelled states, and aggregator forwarding is substantial new code. Gated on the extensions plumbing and mcp-go.
  • 02 Extensions framework — medium risk, medium effort, gated. Passthrough of an opaque extensions map (inbound and outbound) plus a native-support decision matrix. Gated on mcp-go exposing the extensions field on its capability structs.
  • 03 MCP Apps — medium risk, low-to-medium effort, gated. muster renders nothing; the work is preserving _meta.ui end-to-end through the meta-tool layer (which strips _meta today), advertising io.modelcontextprotocol/ui when an upstream supports it, and not prefetching UI templates server-side. Gated on mcp-go _meta carriage + the extensions field.
  • 07 JSON Schema 2020-12 — low risk, low effort, gated on a bump. muster's schema plumbing already passes arbitrary keywords through and emits no literal -32002. Mostly a mandatory mcp-go dependency bump plus "don't regress" guards (forward array/primitive structuredContent, bound schema depth, reject network $refs, regression-guard -32002). Opportunistic upside: add outputSchema to muster's own structured-result tools.
  • 06 Deprecations — minimal risk, minimal effort, a non-event. No code to delete or migrate (muster speaks none of Roots/Sampling/MCP Logging). The work is a policy commitment, a guard scenario, and docs; muster's logging is already the OTel replacement.
  • 08 Protocol evolution — process, low effort. Adopt the upstream conformance suite in CI (report-only first), add a sep: tag convention to the BDD scenarios, and decide the mcp-go vs modelcontextprotocol/go-sdk question. No wire work of its own.
  • 09 Release timeline — process, no code. Sequences everything above onto the RC → Final calendar; the only hard deadlines muster faces are removal dates (none inside this window), and muster's pace is set by mcp-go availability, not July 28.

Suggested adoption order

Synthesised from the per-section "required changes" and the phased schedule in 09-release-timeline.md. The order front-loads ungated work and test scaffolding so the gated wire work has a clean place to land and an external signal to validate against.

  1. Decide and track the SDK dependency (08 §5, 09 Phase 0). Open a tracking issue for mcp-go's 2026-07-28 support and make the mcp-go vs modelcontextprotocol/go-sdk decision once, explicitly — it determines how much of the wire work muster writes versus inherits.
  2. Do the ungated muster work (09 Phase 1): decouple the internal session model from Mcp-Session-Id (01 §4 item 2) and land server-side iss validation plus the other muster-owned auth items (05 §4).
  3. Stand up the conformance / BDD scaffolding (08 §4): adopt the upstream conformance suite in CI report-only, add the sep: tag convention, and add the -32002 regression guard (07 §4.2).
  4. Bump mcp-go once it ships 2026-07-28 support (07 §4.1) — unlocks JSON Schema 2020-12 and the -32602 error code with a one-line go.mod change.
  5. Implement the stateless inbound transport and outbound clients (01 §4 items 3–8): server/discover, per-request _meta, Mcp-Method / Mcp-Name routing, subscriptions/listen, InputRequiredResult, and ttlMs / cacheScope.
  6. Wire the extensions map and the extension forwarding/native support (02, 04, 03).
  7. Flip conformance CI to blocking at/after Final (08 §5, 09 Phase 3) and add a CHANGELOG entry per adopted surface naming the SEP and its lifecycle state.
  8. Carry the deprecations policy throughout (06): do not add Roots/Sampling/MCP-Logging; keep forwarding the deprecated methods unchanged; restate the OTel posture in operator docs.

The dependency between sections is small but real: the extensions framework (02) is a prerequisite for both MCP Apps (03) and Tasks (04), and the stateless transport (01) underpins per-request _meta, which in turn carries the extensions map and the Tasks/clientCapabilities declarations.

Consolidated source material

This mirrors the "Source material" index the section docs were written against. Every SEP/PR was read via gh against modelcontextprotocol/modelcontextprotocol; non-GitHub sources were fetched directly.

Primary announcement

Spec entry points

Context & process

External standards referenced

All SEPs / PRs by section

References