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
The server->client forwarding integration tests (mid-call elicitation,
sampling, progress, logging) exercise a surface that exists only on a
Legacy (2025-11-25) session: the 2026-07-28 revision removed
server-initiated requests, replacing them with client-polled multi-round
retrieval (SEP-2322), and SEP-2577 deprecates sampling and logging
outright. Today these tests land on Legacy only incidentally, because the
Modern dispatch kill-switch (#5959) rejects the go-sdk client's
Modern-first probe; once the switch is removed (#6033) the client
negotiates Modern and all of them fail at connect.
Pin the downstream test clients to Legacy explicitly via a transport-level
RoundTripper that answers server/discover with the same -32022 rejection
the kill-switch produces (mcpcompat cannot pin a protocol version, #5911),
and pin the Modern-client contract for the same eliciting backend in a new
integration test: an explicit JSON-RPC error naming the refused request,
never a hang, a fabricated success, or an input_required envelope. Document
the client-edge limitation and the intended future MRTR shape (#5743) in
the vMCP architecture doc.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GvBj7nNWqDQ3rKYNeY6aam
elicitation/sampling/roots purely by negotiated protocol version, so no
307
+
capability negotiation can restore the Legacy forwarding model for Modern
308
+
clients.
309
+
- A server that never returns `input_required` is fully SEP-2575-conformant:
310
+
the per-request `clientCapabilities` a client declares are an offer the
311
+
server may use, not an obligation.
312
+
- SEP-2577 deprecates sampling (and logging and roots) outright as of
313
+
2026-07-28, with direct LLM-provider integration as the sanctioned
314
+
replacement — so elicitation is the only durable consumer a future MRTR
315
+
implementation would serve.
316
+
317
+
Legacy clients keep the full mid-call forwarding behaviour unchanged; the
318
+
forwarding integration tests pin their downstream clients to Legacy explicitly
319
+
(`legacyPinningRoundTripper` in `pkg/vmcp/server`) because that surface exists
320
+
only on a Legacy session.
321
+
322
+
**Bridging was considered, costed, and rejected — this is a design position,
323
+
not a backlog item.** Serving MRTR to Modern clients on top of a *Legacy*
324
+
backend would require parking the live, mid-flight backend call server-side
325
+
(the blocked goroutine and its open session cannot be serialized into the
326
+
opaque `requestState` the SEP designed for handler re-invocation) and keying
327
+
the resume on an unguessable token — per-round server state with TTL/eviction,
328
+
identity binding on a token that becomes a capability to resume someone else's
329
+
in-flight call, and replica affinity with no `Mcp-Session-Id` to route on. That
330
+
is a session in disguise: exactly the construct the 2026-07-28 revision
331
+
removed. The spec's own sanctioned path for genuinely stateful
332
+
`input_required` work is the **Tasks** extension (SEP-1686: `tools/call`
333
+
returns a `taskId`; the client polls `tasks/get`/`tasks/result` and answers via
334
+
`tasks/input_response`) — if Modern-client elicitation over Legacy backends is
335
+
ever truly demanded, that is the machinery to reach for, not parked
336
+
`tools/call`.
337
+
338
+
The coherent future MRTR shape for a re-aggregating gateway is
339
+
**Modern-client ↔ Modern-backend pass-through** — relay a Modern backend's
340
+
`inputRequests`/`requestState` to the client and the client's
341
+
`inputResponses` back, genuinely stateless at vMCP. It requires the egress
342
+
half first (today a Modern backend's `input_required` surfaces as
343
+
`errModernInputRequired`, the seam left in `pkg/vmcp/client`), and by the time
344
+
Modern backends exist to relay from, SEP-2577's deprecations make elicitation
345
+
its only durable consumer; see #5743.
346
+
347
+
Progress and log notifications toward Modern clients are a separate concern
348
+
from MRTR: they remain spec-legal as request-scoped notifications on the
349
+
POST-initiated SSE response stream (SEP-2260 requires messages on that stream
350
+
to relate to the originating request; `progressToken` is unchanged), which the
351
+
single-shot dispatcher does not produce today — a vMCP streaming-dispatch gap,
352
+
not a spec absence.
353
+
292
354
## Served MCP Capabilities
293
355
294
356
Beyond tools, vMCP aggregates and serves the full complement of MCP capabilities. Every served capability flows through the domain **core** (`pkg/vmcp/core`), so the same admission decision that filters `tools/list` also gates reads, gets, and completions.
0 commit comments