Transport & protocol

MCP uses JSON-RPC 2.0 under the hood, meaning structured request/response messages. But how those messages get from client to server depends on the transport layer. MCP supports three transport options, and the choice is usually simple.

STDIO transport: The client launches the server as a subprocess and communicates via stdin/stdout. Zero network configuration, minimal latency, easy to debug. Limitation: local only, one client per server process. This is what you will use for most of this workshop.

SSE (Server-Sent Events): HTTP-based transport. The client sends requests via POST and receives responses through a persistent GET connection. Works through HTTP proxies, supports auto-reconnection. Being superseded by Streamable HTTP.

Different environments have different constraints. STDIO is perfect for local development because there is zero network setup. HTTP-based transports are necessary when the server runs on a different machine. By supporting multiple transports with the same protocol on top, MCP works everywhere from a developer laptop to a cloud deployment.

Streamable HTTP: The modern, recommended transport for production. A single POST /mcp endpoint where the server responds with plain JSON or upgrades to SSE. Supports session IDs, event replay for reconnection, and horizontal scaling behind load balancers.

Quick decision guide: Same machine? Use STDIO. Remote with simple setup? Use SSE. Production deployment? Use Streamable HTTP. In this workshop, we'll use STDIO for most exercises and SSE for the chat client demo.