Part of #5743 (Workstream C: 2026-07-28 stateless readiness).
Work
Design vMCP's stateless mode. vMCP's session model (two-phase SessionIdManager, Redis metadata, identity binding, 1000-session cap, per-backend session hints) exists because the protocol was session-ful; 2026-07-28 removes protocol sessions entirely — cross-call state moves to explicit server-minted handles passed as tool arguments.
- Server side: per-request
_meta (protocolVersion/clientInfo/clientCapabilities) instead of initialize; implement server/discover; decide what replaces per-session tool projection when there are no sessions (per-principal projection derived from auth context per request).
- Client side: stateless connections to 2026-07-28 backends; keep session-ful handling for 2025-11-25 backends (dual-protocol per backend).
- Composite workflows: elicitation becomes MRTR (see the MRTR passthrough issue); workflow state must key on server-minted handles, not session IDs.
- Statelessness dissolves the cross-pod affinity TODO (
registry.go) — any pod can serve any request; Redis remains for workflow/handle state only.
Depends on: the go-sdk v1.7 adoption issue. Deliverable: design doc first.
Part of #5743 (Workstream C: 2026-07-28 stateless readiness).
Work
Design vMCP's stateless mode. vMCP's session model (two-phase
SessionIdManager, Redis metadata, identity binding, 1000-session cap, per-backend session hints) exists because the protocol was session-ful; 2026-07-28 removes protocol sessions entirely — cross-call state moves to explicit server-minted handles passed as tool arguments._meta(protocolVersion/clientInfo/clientCapabilities) instead of initialize; implementserver/discover; decide what replaces per-session tool projection when there are no sessions (per-principal projection derived from auth context per request).registry.go) — any pod can serve any request; Redis remains for workflow/handle state only.Depends on: the go-sdk v1.7 adoption issue. Deliverable: design doc first.