Discover how data travels between Client and Server — STDIO for local use, HTTP for the web, and SSE for real-time streaming.
In MCP, the transport is the layer that defines such as Client and Server communicate physically—which channel the data travels through. The MCP protocol itself is transport-independent: it defines the format of messages (the "what"), but does not dictate how those messages reach their destination (the "how"). This means the same server can work over different communication channels without changing its internal logic.
Think of transport as the transport of a message. You can send the same letter by mail or email, or read it over the phone — the message content is identical, but the channel changes. In MCP, the JSON-RPC message is always the same, but it can travel over STDIO (on the same machine), HTTP (over the network), or SSE (streaming over the network). The server doesn't need to know which transport is being used — it simply processes the messages it receives.
MCP officially supports three transports: STDIO, HTTP, and SSE. This separation between protocol and transport is an established architectural pattern — HTTP itself runs over TCP, but it could run over any reliable transport protocol. This independence is what makes MCP so flexible: it works both in a local script on your machine and on a cloud server serving thousands of clients simultaneously.
The transport STDIO (Standard Input/Output) is the simplest and most straightforward of the three. In this mode, the Client and Server run on the same machine, and communication happens through the process’s standard input and output channels — the famous stdin and stdout. The Client starts the Server as a child process and sends messages through the process’s stdin. The Server responds through stdout. No network, no ports, no HTTP configuration — just two processes communicating directly.
In STDIO, the Client spawns (starts) the Server as a child process in the operating system. Communication flows through the standard pipes: the Client writes to stdin from the Server and reads from the stdout from the Server. Each message is a JSON-RPC line terminated by a newline. This is the fastest transport because there’s no network overhead—the data passes directly through the operating system’s memory. Ideal for local tools such as file access, command execution, and IDE integration.
STDIO is perfect for local development and tools that run on your computer. If your MCP server accesses local files, runs scripts, or interacts with programs installed on the machine, STDIO is the natural choice. It’s also the easiest to debug—you can literally see the messages being exchanged in the terminal.
The transport HTTP allows the Client and Server to be in different machines, communicating over the network. The Server exposes HTTP endpoints, and the Client sends standard requests (POST) containing JSON-RPC messages. It’s the ideal transport for remote servers, cloud APIs, and scenarios where the server needs to be accessed by multiple clients simultaneously.
Over HTTP transport, the MCP Server runs as a web service that listens on a port (e.g., port 3000). The client sends JSON-RPC messages as the body of requests POST for the server endpoint. The server processes the request and returns the response in the HTTP response body. It’s the same familiar model as any REST API—but instead of various endpoints, all MCP messages go through a single endpoint, with the operation type defined inside the JSON-RPC.
The Client builds a JSON-RPC message (e.g., to call a tool) and sends it as the body of an HTTP POST to the Server endpoint.
The Server receives the request, deserializes the JSON-RPC, identifies the requested method, and executes the corresponding logic.
The Server assembles the JSON-RPC response with the result (or error) and sends it back to the Client in the HTTP response body.
HTTP is the most widely used protocol on the web, which makes MCP’s HTTP transport natively compatible with all the existing infrastructure: load balancers, reverse proxies, firewalls, TLS certificates, and monitoring tools. MCP servers over HTTP can be deployed on any cloud platform (AWS, GCP, Azure) and scaled horizontally using the same techniques used for any traditional web API.
O SSE (Server-Sent Events) is an HTTP extension that allows one-way streaming from the Server to the Client. Instead of the Client sending a request and waiting for the full response, the Server opens a persistent channel and continuously sends data as it becomes available. In MCP, this is ideal for long-running operations—such as processing a large file or running a lengthy query—where the Client needs real-time progress updates.
With SSE, the Server can send data to the Client without the Client having to keep asking (polling). The Client makes a single HTTP request, and the connection remains open. The Server then sends events over the channel whenever there is new data. In the MCP context, this allows the server to send progress notifications, partial results, and real-time status updates. The Client uses POST to send messages to the Server, and the Server uses the SSE channel to send responses and notifications back.
Use SSE when your MCP server needs to send real-time updates to the client — for example, file processing progress, live execution logs, or results that arrive gradually. SSE is natively supported by browsers and works with existing HTTP infrastructure, without requiring WebSocket.
Each transport has its strengths and weaknesses. The choice depends on the scenario: where the server runs, how many clients it needs to serve, whether streaming is needed, and what level of complexity is acceptable. Understanding the differences is essential for making the right choice when implementing your MCP server.
| Criterion | STDIO | HTTP | SSE |
|---|---|---|---|
| Location | Same machine | Anywhere | Anywhere |
| Speed | Very fast | Fast | Fast |
| Complexity | Minimum | Moderate | Moderate |
| Streaming | No | No | Yes |
| Multi-client | No | Yes | Yes |
| Ideal case | Local dev, IDEs | Cloud APIs | Real time |
Currently, STDIO is used by approximately 70% of MCP servers in production, precisely because it is the simplest to implement and test. HTTP appears in about 25% of cases — mainly in servers deployed in the cloud. SSE is still the least adopted (~5%), but its share is growing as more applications require streaming and real-time feedback. The trend is for HTTP and SSE to gain ground as the ecosystem matures and more servers migrate to remote environments.
In practice, choosing a transport comes down to answering a few simple questions: Where will the server run? How many clients need to connect? Is streaming needed? When in doubt, the golden rule is: start with STDIO. It’s the easiest to configure, test, and debug. When you need remote access, migrate to HTTP. When you need streaming, add SSE.
Decision guide for choosing a transport:
Always start with STDIO — is the easiest to test and debug. You can have a working server in minutes, without configuring ports, URLs, or certificates. Once you're satisfied with the server logic, migrating to HTTP or SSE is a change only to the transport layer — all the server code stays the same. That's the beauty of MCP's protocol/transport separation.
Don't overcomplicate things at the beginning. A common beginner mistake is wanting to use HTTP or SSE when STDIO solves the problem perfectly well. Setting up network transport adds unnecessary complexity in the early stages: ports, CORS, authentication, TLS, firewalls. Focus first on your server's logic — tools, resources, prompts — and only then worry about production transport. Optimize when there's a real need, not in anticipation.
Next Track: Track 2 - Development Environment