A team builds a custom MCP transport over its internal message queue so that agents in a data center can reach servers. What must the custom transport preserve to stay interoperable?
Select an answer to reveal the explanation.
Short Explanation
A custom transport is a new road, not a new language. You can carry MCP over your message queue, but the JSON-RPC messages, the patterns and the per-request _meta have to arrive intact. Bringing back the handshake or HTTP specifics misses the point.
Full Explanation
The transports overview allows clients and servers to implement custom transport mechanisms, noting that the protocol is transport-agnostic and can run over any channel that supports bidirectional message exchange. Implementers who do so MUST preserve the JSON-RPC message format, the message patterns, and the per-request metadata model, and they SHOULD document connection establishment, message framing and cancellation to aid interoperability. Custom transports over a reliable byte stream SHOULD reuse the stdio framing of newline-delimited JSON-RPC. Mapping Streamable HTTP status codes and headers onto queue messages is not required; those are features of one binding, and the body remains the source of truth for metadata on every transport. Reintroducing the initialize handshake and per-client sessions contradicts revision 2026-07-28, where every request is self-contained and servers must not infer state from earlier requests. Claiming a custom transport may redefine message contents ignores the explicit preservation requirement; a transport that changed meanings would no longer be MCP. Exam caveat: the authorization specification is written for HTTP, so a custom transport must document how it handles credentials, and clients and servers may negotiate their own strategies. Operational check: send the same server/discover, tools/list and tools/call requests over the queue and over stdio and confirm the JSON-RPC bodies and _meta fields are identical.