transports-wg

Strawman proposal for roadmap for the next ~6 months.

Summary Standardizes a public, replaceable transport extension point across official MCP SDKs: the SDK boundary between MCP protocol processing and the mechanism that carries MCP JSON-RPC messages. A conforming SDK exposes a public transport abstraction through which a third-party transport can send and receive complete MCP JSON-RPC messages without forking or modifying protocol dispatch. Scope In: JSON-RPC-preserving custom transports (WebSocket, /, Unix sockets, named pipes, gRPC/Cap'n Web tunnels carrying opaque MCP JSON-RPC, in-process channels). Out (deliberately): native RPC bindings that replace the JSON-RPC method layer (e.g. typed protobuf gRPC services, native Cap'n Web object-capability mappings) — deferred to a separate proposal. Out**: adding any new standard MCP transport binding. Why this framing Narrows the deferred SEP-2598: keeps MCP JSON-RPC as the semantic boundary (which the 2026-07-28 spec normatively requires for custom transports), standardizes the SDK extension seam behaviorally rather than by identical API, and centralizes conformance vectors instead of requiring every Tier-1 SDK to maintain its own harness. What's here — the proposal (draft). — supporting research: cross-SDK transport survey and RPC-transport analysis. Open for discussion Draft for WG comment. Highlights for review: Message-oriented boundary (one complete JSON-RPC message) vs exchange-oriented API — §9. Opaque Transport Context as the only carrier-specific escape hatch — §5. Behavioral conformance; concurrency/correlation as the one MUST — §Conformance. SDK alignment table and per-SDK guidance — §SDK Alignment. Ready for feedback.

The roadmap invites the community to experiment via custom transports while official transports stay fixed this cycle. I'd like to scope one such experiment: a receiver-driven, message-oriented transport targeting the interactive short-message regime of MCP. Context Agent workloads are dominated by many small round trips with occasional large transfers (context snapshots, tool outputs) sharing one connection. Short messages should arrive in one round trip and stay ahead of bulk transfers. The current IETF agent-transport drafts (Nandakumar / Jennings / Liu families, 2026-08, all over MOQT) are uniformly sender-driven: publishers stamp per-object priority, relays order by it, and subscribers have no way to express their own urgency. Short-message latency pays stream/session setup, none of them adds an application-layer scheduling policy, and none treats determinism as a design goal. The complementary design point is receiver-driven scheduling in the Homa tradition: an unscheduled window for single-packet round trips, receiver GRANT + SRPT admission, eight-level sender priority, receiver-driven RESEND. Reference implementation (Apache-2.0 / MIT) Rust crate * — crates.io + , with an IETF draft (v00) of the wire format in-repo. Deterministic benchmark: fixed workload, FNV-1a workload fingerprint, committed baseline, >1% regression gate. On a loopback mixed load (91% 100B + 9% 1MiB), short RPC P50 814 µs / P99 4231 µs vs a TCP baseline 1265 µs / 21924 µs (P99 ≈ 5.2×). Honest boundary: loopback, no real congestion — it demonstrates the scheduling architecture, not data-center numbers. Questions for the WG 1. How should a custom transport be scoped against SEP-2598's Pluggable Transports contract — specifically, is receiver-driven scheduling* ("the transport may pull by receiver urgency") expressible in that contract, or is it out of scope? 2. Would the WG be interested in a shared head-to-head benchmark harness (same workload, vs a MOQT implementation) as a neutral comparison basis for custom transports? Happy to follow the issue → SEP-style proposal → PR flow. This is an experiment in exactly the lane the roadmap invites.