Why architecture matters here
MCP transports look interchangeable but are not. stdio is fast, simple, and only local — the child process model. HTTP/SSE works remotely but adds server-side state and reconnect complexity. Streamable HTTP unifies bidirectional messages on one endpoint, simplifying operations at some cost of protocol complexity.
The architecture matters because your product decisions push you toward one or the other. A desktop app with local tools uses stdio. A hosted SaaS MCP server uses streamable HTTP for scale. A legacy integration might use HTTP+SSE. Each has ops implications — timeouts, backpressure, session resume.
Understanding the pieces makes those choices with intent rather than by copy-paste.
The architecture: every piece explained
The top strip is the transport landscape. MCP client is the host process (a code editor, agent runtime, or IDE). stdio transport spawns the MCP server as a child process and communicates via stdin/stdout with newline-delimited JSON-RPC. HTTP + SSE uses a POST endpoint for requests and an SSE stream for server-initiated messages and responses. Streamable HTTP uses a single endpoint that upgrades to a bidirectional message stream, letting request/response and server notifications share one connection.
The middle row is the shared machinery. JSON-RPC framing defines requests, responses, and notifications by their fields (id, method, params). Init handshake negotiates protocol version; incompatible clients/servers fail early. Capability negotiation exchanges what each side supports — tools, resources, prompts, sampling. Auth + sessions — bearer tokens, OAuth flows, cookies — differ by transport but are consistent in intent.
The lower rows are resilience and ops. Reconnect + resume lets HTTP transports resume a session after network hiccups. Observability logs framed messages and pings for liveness. Ops tunes timeouts, rate limits, and backpressure per transport based on client and server characteristics.
End-to-end flow
End-to-end: a desktop MCP client spawns a local server via stdio. Init handshake exchanges version and capabilities; client discovers 5 tools and 12 resources. User asks a question; client calls tools/list, then invokes a tool via tools/call; server responds with results. Later, the client connects to a hosted MCP server via streamable HTTP. Auth is OAuth-based; the client receives a session ID. Requests flow over POST; the server pushes progress notifications on the same stream. A network blip; the client reconnects with the same session ID and resumes; no data loss. Observability shows framed request/response timings and reconnect events.