MCP supports three transports: stdio (process-piped), SSE (server-sent events over HTTP), HTTP+JSON. Each fits a different deployment shape. Picking right means matching the transport to the trust and lifecycle model you actually have.
stdio — local subprocess
Server runs as a subprocess of the client. Communication over stdin/stdout. Right for: local tools, dev tools that should run with user's permissions, MCP servers tightly coupled to an app. Wrong for: shared remote services.
SSE — server-sent events
HTTP-based, server-pushes events to client. Lower-overhead than polling. Stateful connection. Right for: long-lived agent sessions with frequent server-initiated messages (notifications, streamed results).
HTTP+JSON — request/response
Plain HTTP request/response per call. Stateless on the server side. Right for: simple tool servers, multi-tenant remote services, scaling behind a load balancer. The default for hosted MCP.
Choosing
Embedded in a desktop app: stdio. Hosted multi-user service: HTTP. Need server-initiated events to a long-lived client: SSE. Don't try to mix transports for one server unless you have a reason.
Operational implications
stdio: no network exposure, no auth needed (process boundary is the boundary). HTTP: standard web ops (auth, rate limit, monitoring). SSE: stateful — connection drain on deploy, sticky sessions, more complex than HTTP.