A team wants MCP clients and servers on the same host to communicate over a Unix domain socket instead of a subprocess's standard streams. What does the specification recommend for message framing?
Select an answer to reveal the explanation.
Short Explanation
A socket is just another pipe, so you send the same one-message-per-line format you'd use over stdio. The trap is inventing your own framing when the spec already handed you one.
Full Explanation
MCP is transport-agnostic, and clients and servers may implement custom transports as long as they preserve the JSON-RPC message format, the message patterns and the per-request metadata model. For transports that run over a reliable bidirectional byte stream, such as Unix domain sockets or TCP, the specification says they should reuse the stdio framing rather than define a new one: one newline-delimited JSON-RPC message per line, with no embedded newlines. Only the subprocess-specific aspects, such as launch, stderr handling, shutdown by closing the stream and restart, need channel-specific equivalents. Streamable HTTP is one binding with its own header layer; custom transports are not required to carry HTTP headers, and on stdio-style bindings all metadata lives in the message body. Length-prefixed binary framing is not forbidden outright, but it ignores the recommendation and makes the transport incompatible with existing stdio tooling, and newline-delimited JSON is not reserved for real pipes. HTTP+SSE is a deprecated legacy transport, not MCP's canonical framing. Exam caveat: custom transports should document connection establishment, framing and cancellation, and stdio-style cancellation uses notifications/cancelled. Operational check: send a request and response over the socket and confirm each message is a single UTF-8 JSON line that an ordinary stdio client can parse.