Implement SEP-2322: Multi Round-Trip Requests

[alexhancock]

SEP-2322: Multi Round-Trip Requests (MRTR) — rust-sdk implementation

Spec PR: modelcontextprotocol/modelcontextprotocol#2322
Conformance: modelcontextprotocol/conformance#188
Track: Specification · Stage: accepted · Priority: P0 · Theme: Transport Evolution and Scalability
Needs code changes: Yes (Large) — Breaking

Summary

A Transports Working Group proposal for Multi Round-Trip Requests: a transport-level mechanism so a
single logical request can involve multiple message round-trips (e.g. for server→client requests
that occur within the lifetime of a client request) without depending on long-lived sessions. The
SEP carries schema changes and is explicitly flagged as a breaking change.

Why this needs code changes in rust-sdk

The current transports assume a session/connection over which server→client requests can occur at
any time. The request/response correlation today lives in the generic service.rs peer machinery
(request id → pending response map) and the streamable HTTP server tower.rs, which currently maps
each POST to an SSE stream for that request. MRTR reframes round trips around the lifetime of a
client request, which changes both that correlation and how tower.rs frames the response stream
when the server needs to call back into the client mid-request.

Proposed work

• Add the MRTR schema fields/types to model.rs per the SEP.
• Add the MRTR framing to the streamable HTTP server (streamable_http_server/tower.rs): allow a single client POST's SSE response stream to carry interleaved server→client requests and their responses within that request's lifetime.
• Extend the client (streamable_http_client.rs) to answer server→client requests that arrive on the response stream of its own outbound request.
• Adjust request correlation in service.rs so server-initiated requests are tagged with the originating client request id (shared mechanism with SEP-2260).
• Gate behind ProtocolVersion::V_2026_07_28 (breaking vs. older always-on-connection behavior).
• Wire up the conformance scenario from conformance#188.

Affected areas

crates/rmcp/src/service.rs (peer request correlation), service/client.rs, service/server.rs,
transport/streamable_http_client.rs, transport/streamable_http_server/tower.rs,
model.rs (new framing/schema fields).

Notes / risks

• Tightly coupled with SEP-2260 (server requests must associate with a client request) and SEP-2663 (tasks). Sequence MRTR first, then layer 2260 and tasks on top.
• Breaking vs. older always-on-connection behavior; gate behind ProtocolVersion::V_2026_07_28 so older peers are unaffected.

[erenatas]

Hi all, just realized that I did duplicate work #946 , I will close it. On the other hand, I would be happy to help with the stateless efforts 🙏