MCP servers communicate with clients over one of two transport mechanisms: stdio (standard input/output) or SSE (Server-Sent Events over HTTP). The choice of transport determines how the server is deployed, how clients connect to it, and what operational complexity it introduces. Most developers start with stdio for local development and migrate to SSE or HTTP Streaming when they need remote access, multi-client support, or cloud deployment. Understanding when each transport is appropriate prevents over-engineering local servers and under-engineering production ones.
Stdio Transport
In stdio transport, the MCP client launches the server as a child process and communicates with it by writing JSON-RPC messages to the process’s standard input and reading responses from its standard output. The client manages the server’s lifecycle — starting it when needed, stopping it when done. Communication is local and synchronous from the client’s perspective: the client writes a request, the server writes a response, and they exchange messages through OS-level pipes. Stdio is the default transport for local MCP servers and is what most packaged MCP servers (filesystem, GitHub, Slack, etc.) use. Its advantages are simplicity: no network configuration, no authentication setup, no port management, and no possibility of external access (the process is local and pipe-connected). Installation is typically just configuring the client to know the path to the server executable and any arguments it needs.
SSE Transport (and HTTP Streaming)
SSE (Server-Sent Events) transport runs the MCP server as an HTTP server. The client connects to a URL, establishes a persistent SSE connection to receive server-to-client messages, and sends client-to-server messages via HTTP POST requests to a separate endpoint. This bidirectional communication over HTTP enables scenarios that stdio cannot support: the server runs on a remote machine and clients connect over the network; multiple clients connect to the same server instance simultaneously; the server is deployed as a cloud service that persists independently of any client session. The MCP specification also defines an HTTP Streaming transport (sometimes called Streamable HTTP) that replaces SSE with a more flexible bidirectional streaming mechanism — as of mid-2026, SSE is more widely implemented but HTTP Streaming is the direction the specification is heading for production deployments.
When to Use Each
Stdio is the right transport for local tools that run on the developer’s own machine: filesystem access, local database connections, local code execution, tools that require access to local environment variables or credentials. The tool runs as a subprocess with the same local permissions as the client, which is appropriate for personal development tools. SSE or HTTP Streaming is the right transport for shared team infrastructure: a company’s internal database accessible to multiple developers, a shared codebase search server, a cloud-deployed tool that multiple clients access simultaneously. Remote transport is also required when the MCP server needs to run in a specific environment — on a server with specific dependencies installed, inside a Kubernetes cluster, or on hardware with specific capabilities (a GPU server, a database server).
Figure 1 — MCP transport: stdio vs SSE at a glance
Configuration for Stdio Servers
Clients configure stdio servers by specifying the command to run the server process and any arguments or environment variables it needs. In Claude Desktop’s configuration file (claude_desktop_config.json), a stdio server entry specifies the command (the executable path), args (command-line arguments), and optionally env (environment variables to set for the process). The client starts the server process on connection and stops it when the conversation ends — which means each new conversation starts a fresh server process. For servers that maintain state (a persistent database connection, a long-running computation), this per-conversation lifecycle can be a limitation. Solutions include making the server stateless (loading everything it needs from disk or network on each start) or using SSE transport to run the server as a persistent process.
Configuration for SSE Servers
SSE servers are configured in clients with a URL pointing to the server’s SSE endpoint. The client connects to this URL and establishes the SSE stream; the server’s base URL is also used for the POST endpoint that carries client-to-server messages. For local development, the URL is typically http://localhost:8000/sse. For production remote servers, the URL is an HTTPS endpoint with appropriate authentication. Because SSE servers run as persistent HTTP servers rather than per-client processes, they can maintain state across client connections and serve multiple clients simultaneously — important for shared team infrastructure where the same server needs to handle concurrent requests from multiple developers.
Authentication Differences
Stdio servers have no authentication concern — only processes running locally with appropriate permissions can communicate with them through pipes. SSE servers require authentication whenever they are accessible beyond localhost, because any HTTP client that can reach the server URL could potentially send requests. MCP’s authentication specification uses OAuth 2.0 for remote server authentication — the client performs an OAuth flow to obtain a token, and the server validates the token on each request. For internal team servers behind a VPN or on a private network, simpler approaches work: shared API keys in request headers, or network-level access control (the server only accepts connections from specific IP ranges). The authentication setup is the main additional complexity cost of SSE over stdio, and for solo developers running local tools, it is a cost with no benefit — stdio is the right transport specifically because it avoids this overhead.
Transport Selection in Practice
The practical decision rule: start with stdio for any server you are building for your own use on your own machine. Migrate to SSE when: you want to share the server with other team members, when you need the server to persist state across client sessions, when the server needs to run in a specific environment you cannot replicate locally, or when you want to deploy the server as a managed service. Most of the popular community MCP servers (filesystem, GitHub, Brave Search, PostgreSQL) default to stdio because they are designed for individual developer use. Enterprise MCP servers that serve whole teams are typically SSE-based. Building for personal use: stdio. Building shared infrastructure: SSE.
The stdio vs SSE choice is an infrastructure decision, not a capability decision — both transports support the full MCP capability set. Make the choice based on deployment requirements: local personal tools use stdio for simplicity; shared or remote infrastructure uses SSE for multi-client support and deployment flexibility. Over-engineering a personal tool with SSE transport adds complexity with no benefit; under-engineering a shared team server with stdio limits it to one user at a time. Match the transport to the deployment model from the start to avoid having to refactor later.
Streaming and Progressive Responses
Both transports support streaming responses — a server can send partial results progressively rather than waiting until a complete response is ready. For stdio, streaming uses the same pipe channel with incremental JSON-RPC messages. For SSE, streaming is natural because SSE is inherently a server-push mechanism — the server sends events as they are ready and the client processes them incrementally. This streaming capability matters for long-running operations: a tool that takes 30 seconds to complete can stream partial results every few seconds rather than making the client wait silently. The MCP specification defines progress notifications for exactly this purpose — servers can send intermediate progress updates during long tool executions, which clients can display to users as loading indicators or incremental output. Implementing progress notifications makes long-running MCP tools feel responsive rather than unresponsive, and is worth adding for any operation that regularly takes more than 2–3 seconds.
Testing Transport Configuration
Testing a stdio server is straightforward: run the server process manually in a terminal and send JSON-RPC messages to its stdin to verify it responds correctly. The MCP Inspector (a browser-based testing tool from the MCP team) automates this — point it at a server command or URL and it provides a GUI for browsing capabilities, calling tools, and reading resources. For SSE servers, any HTTP client can test the connection; curl to the SSE endpoint should return a persistent event stream. The most common configuration issue with stdio servers is path resolution: the client configuration needs absolute paths to the server executable, not relative paths, because the client process may have a different working directory. For SSE servers, the most common issue is CORS configuration — clients running in a browser context need the server to include appropriate CORS headers. Both issues are immediately visible in the MCP Inspector, making it the recommended first debugging tool for any transport configuration problem.