MCP Transports: stdio vs. Streamable HTTP/Sockets
CoreUnderstand MCP servers, their primitives, and transports · Difficulty 2/5
Explanation
Two Transport Families
MCP servers communicate with clients over one of two transport patterns, and the right choice depends entirely on the deployment shape:
- stdio -- the server runs as a local subprocess communicating over standard input/output. This is ideal for local, single-user integrations where the client launches and owns the server process directly.
- Streamable HTTP / sockets -- a network transport for remote or shared servers that serve multiple clients at once.
Matching Transport to Deployment
The exam-relevant judgment is matching the transport to the deployment, not memorizing the transports in isolation: a personal, single-user, locally-run integration is a stdio case; a shared service reused by multiple clients or teams is an HTTP/sockets case.
Common exam traps
- Picking HTTP/sockets for a local, single-user subprocess scenario, or vice versa -- the deployment shape (local/single-user vs. remote/multi-client) determines the correct transport.
- Confusing MCP transports with unrelated network concepts (e.g., a batch API or a direct websocket to Anthropic) -- the two MCP-relevant transports are stdio and Streamable HTTP/sockets.
Key Takeaways
- stdio: local subprocess transport, ideal for local, single-user integrations
- Streamable HTTP/sockets: network transport for remote or shared servers serving multiple clients
- Match the transport to the deployment shape rather than defaulting to one option
- Exam questions test recognizing the correct transport for a described deployment scenario
Glossary Terms
An MCP transport mechanism where the client launches the server as a subprocess and communicates via stdin/stdout pipes. Ideal for local development and trusted single-user environments. Simple to set up but limited to same-machine deployment.
An MCP transport that communicates over HTTP with Server-Sent Events (SSE) for streaming. Runs as an independent network service — not a subprocess. Enables multiple simultaneous clients, per-request authentication, and remote deployment. The correct transport for shared, cloud-hosted, or containerised MCP servers.
Related Concepts