Implement SEP-2260: Require Server requests to be associated with a Client request

[felixweinberger]

This is a tracking issue for implementation of SEP-2260.

[mattzcarey]

Status — SEP-2260 (Server requests associated with Client requests)

Track: A (core, sequential spine) — starts now (current spec, doesn't require 2026-06 mode)
Spec: seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md · merged & marked Final in spec#2730

What's done

• Nothing in main yet.
• Closed exploration: feat(server): handleHttp() per-request entry, SessionCompat, dual-conformance #2058 (handleHttp() per-request entry, SessionCompat, dual-conformance) — Felix's r3-handlehttp branch laid the per-request HTTP entry-point groundwork the bugfix will land into.

Outstanding (acceptance criteria from the spec page)

• R-2260-1 (wire): s→c requests (roots/list, sampling/createMessage, elicitation/create) MUST only be sent on the POST-response SSE stream of an originating client request.
• R-2260-3 (sdk): no API for unsolicited s→c.
• R-2260-4 (wire): SSE keepalive SHOULD be used during nested waits.
• R-2260-5 (wire): client receiving an orphan s→c request SHOULD respond -32602.
• R-2260-6 (wire): GET-initiated standalone SSE streams MUST NOT carry s→c requests (notifications/pings only).
• R-2260-7 / 8 (guidance): timeouts accommodate human-in-the-loop delays; ping exempt.

Fixes long-standing bugs #963 and #1167.

Test backlog

• [DRAFT] test(e2e): 2026-06 spec backlog — SEP-2260 + SEP-2575/2567 as expected-fail stubs #2180 (DRAFT) adds the 2260 + 2575/2567 acceptance criteria to the v2 e2e suite as known-failure stubs — adopt as the conformance ratchet for this issue.

Open spec PRs to watch

• None active (SEP marked Final 2026-05-15).

Suggested first PR

Standalone bugfix (~90 LOC per the spec-page sequencing plan): ensure ctx.elicit / ctx.sample only emit on the originating request's response stream, never on a separate channel. Lands on current-spec code, doesn't need 2026-06 mode.

[felixweinberger]

Scope clarification from implementation analysis: SEP-2260's MUST-strength rules never landed in the published 2025-11-25 spec pages (they remain SHOULD-strength there: server→client messages "SHOULD relate to the originating client request"), and in the current draft spec they are enforced structurally by MRTR (SEP-2322) rather than as standalone rules.

So this issue's deliverables split as follows:

1. 2025-lineage improvements — delivered by fix(server): associate ctx-scoped elicitation/sampling with the originating request (SEP-2260) #2228: ctx-scoped elicitation/sampling requests now carry relatedRequestId and ride the originating request's response stream, plus an opt-in SSE keepalive for long nested waits.
2. The remaining rules (client rejects unsolicited server→client requests; no API for unsolicited pushes) assert draft-era semantics and are delivered by the MRTR implementation (Implement SEP-2322: Multi Round-Trip Requests #2187), where they hold by construction.

No separate "SEP-2260 implementation" beyond these two pieces should be expected.

[norika1207-lab]

This looks worth pinning down as a protocol-level regression rather than only an implementation bug.

For server requests associated with client request, the acceptance test I would want is a minimal client/server fixture that records the exact JSON-RPC or HTTP exchange, then asserts both the wire result and the local lifecycle state after the failure path. In MCP deployments, the dangerous failures are often not just wrong return values; they are pending requests, dropped notifications, mismatched session state, or errors that get translated into a generic response and become impossible to diagnose.

A useful fix boundary would preserve three signals: the protocol error sent to the peer, the local exception or cancellation reason available to application code, and a trace/log field that ties the two together. That makes the behavior debuggable for agent hosts without requiring every host to special-case this SDK detail.