You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
👋 We're working toward MCP 2026-07-28 support in swift-sdk and would like to help with SEP-2575 — but want to coordinate before opening a large PR series, since this touches the dispatch core.
Is anyone already working on this, or is there an intended design/owner? In particular, should the Swift implementation mirror the shapes the TypeScript SDK landed for SEP-2575, or is there a Swift-specific plan? Happy to align to whatever's already decided.
Context on what we've found mapping the work (against the official @modelcontextprotocol/conformancestateless.ts scenario + the draft schema.json):
The stateless lifecycle needs foundation changes beyond a Server tweak: per-request _meta (namespaced io.modelcontextprotocol/*) currently isn't carried through Request<M>; the Server can't observe the negotiated version at dispatch (it's transport-agnostic, and version is only stored via the handshake); MCPError can't yet carry error.data (needed for -32021 requiredCapabilities / -32022); and the stateless transport drops server→client requests (sampling/roots would hang without SSE-on-POST).
The conformance harness (MCPConformance/Server) is currently stateful (requires Mcp-Session-Id), so the SEP-2575 server scenario can't run against it yet. A session-less harness entrypoint + the diagnostic tools the scenario expects (test_missing_capability, test_logging_tool) looks like a natural, low-risk first PR that unblocks conformance testing for everyone — we'd be glad to contribute that if it's welcome.
Separately, we've opened two small stateless-transport correctness fixes that stand on their own — #267 (colliding in-flight JSON-RPC ids) and #268 (cancelled request leaves the POST hanging) — a review on those would be appreciated.
@jpurnell — another downstream consumer here, blocked on the same thing, and your mapping matches
what we found independently.
We're running an MCP router (Swift, this SDK) and wrote an enforcement profile against 2026-07-28 in late July — currently a ratification candidate internally. It covers the same
eight SEPs tracked in #238/#241–#247, and reached the same three foundation conclusions you did:
per-request _meta not being carried through Request<M>, the server being unable to observe
the negotiated version at dispatch, and MCPError having nowhere to put error.data.
Two things we hit that I didn't see mentioned, in case they're useful:
Removing the session removes the natural home for credentials, which under 2026-07-28
become per-request input. We wrote that up as an explicit negative result — the obvious
"carry a handle in _meta" shape does not survive contact with SEP-2567's requirements
once you ask what re-presents the handle and what revokes it. Happy to share the analysis
if it saves anyone the same dead end.
Version negotiation becomes a per-request assertion rather than a handshake outcome, so
anything that cached the negotiated version at connection time needs a different owner. That
bites Versioning.negotiate as currently shaped.
Your sessionless conformance-harness PR sounds like the right first cut, and we'd use it. Given
this thread has been open five weeks with no maintainer response and main hasn't taken a commit
since 2026-04-29, is anyone coordinating a fork? We're standing one up for our own use either
way, and would rather converge than duplicate.
Activity
jpurnell commentedon Jul 29, 2026
👋 We're working toward MCP
2026-07-28support inswift-sdkand would like to help with SEP-2575 — but want to coordinate before opening a large PR series, since this touches the dispatch core.Is anyone already working on this, or is there an intended design/owner? In particular, should the Swift implementation mirror the shapes the TypeScript SDK landed for SEP-2575, or is there a Swift-specific plan? Happy to align to whatever's already decided.
Context on what we've found mapping the work (against the official
@modelcontextprotocol/conformancestateless.tsscenario + the draftschema.json):Servertweak: per-request_meta(namespacedio.modelcontextprotocol/*) currently isn't carried throughRequest<M>; theServercan't observe the negotiated version at dispatch (it's transport-agnostic, and version is only stored via the handshake);MCPErrorcan't yet carryerror.data(needed for-32021 requiredCapabilities/-32022); and the stateless transport drops server→client requests (sampling/roots would hang without SSE-on-POST).MCPConformance/Server) is currently stateful (requiresMcp-Session-Id), so the SEP-2575 server scenario can't run against it yet. A session-less harness entrypoint + the diagnostic tools the scenario expects (test_missing_capability,test_logging_tool) looks like a natural, low-risk first PR that unblocks conformance testing for everyone — we'd be glad to contribute that if it's welcome.Separately, we've opened two small stateless-transport correctness fixes that stand on their own — #267 (colliding in-flight JSON-RPC ids) and #268 (cancelled request leaves the POST hanging) — a review on those would be appreciated.
Let us know how you'd like to divide this up. 🙏
bartonCUBE commentedon Sep 4, 2026
@jpurnell — another downstream consumer here, blocked on the same thing, and your mapping matches
what we found independently.
We're running an MCP router (Swift, this SDK) and wrote an enforcement profile against
2026-07-28in late July — currently a ratification candidate internally. It covers the sameeight SEPs tracked in #238/#241–#247, and reached the same three foundation conclusions you did:
per-request
_metanot being carried throughRequest<M>, the server being unable to observethe negotiated version at dispatch, and
MCPErrorhaving nowhere to puterror.data.Two things we hit that I didn't see mentioned, in case they're useful:
become per-request input. We wrote that up as an explicit negative result — the obvious
"carry a handle in
_meta" shape does not survive contact with SEP-2567's requirementsonce you ask what re-presents the handle and what revokes it. Happy to share the analysis
if it saves anyone the same dead end.
anything that cached the negotiated version at connection time needs a different owner. That
bites
Versioning.negotiateas currently shaped.Your sessionless conformance-harness PR sounds like the right first cut, and we'd use it. Given
this thread has been open five weeks with no maintainer response and
mainhasn't taken a commitsince 2026-04-29, is anyone coordinating a fork? We're standing one up for our own use either
way, and would rather converge than duplicate.