MCP server transports: STDIO, Streamable HTTP, and SSE

The Model Context Protocol (MCP) supports three primary transport mechanisms for communication between Code Assistant and MCP servers: standard input/output (STDIO), Streamable HTTP (the modern standard), and Server-Sent Events (SSE) (a legacy method). Each has its own characteristics, advantages, and ideal use cases.

STDIO transport

The STDIO transport runs locally on your machine and uses standard input and output streams.

How STDIO works

1. The client (Code Assistant) starts the MCP server as a child process.
2. The communication takes place through process streams: the client writes to the server's STDIN, and the server responds via STDOUT.
3. Each message is separated by a newline character.
4. Messages are formatted as JSON-RPC 2.0.

Client                    Server
   |                         |
   |---- JSON message ---->| (via STDIN)
   |                         | (processes the request)
   |<---- JSON message ----| (via STDOUT)
   |                         |

STDIO features

• Locality: Runs on the same machine as Code Assistant.
• Performance: Very low latency and overhead due to the absence ofas there is no network communication involved.
• Simplicity: Direct inter-process communication without network configuration.
• Interaction: One client to one server.
• Security: This transport is more secure as there is no network exposure.

When to use STDIO

STDIO is ideal for the following use cases:

• Local integrations and tools running on the same machine.
• Operations with strict security requirements.
• Low-latency scenarios.
• Single-client scenarios with one Code Assistant instance per server.
• Command-line tools or IDE extensions.

STDIO implementation example

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server({name: 'local-server', version: '1.0.0'});
// Registering tools...

// Using STDIO transport
const transport = new StdioServerTransport(server);
transport.listen();

Streamable HTTP transport

Streamable HTTP is the modern standard for remote MCP server communication, replacing the legacy HTTP+SSE transport. Operating over HTTP/HTTPS, it enables more flexible server implementations.

How Streamable HTTP works

1. The server provides a single HTTP endpoint (the MCP endpoint) that supports POST and GET methods.
2. The client (Code Assistant) sends requests to this endpoint using HTTP POST.
3. The server processes the request and sends a response.
4. Optionally, the server may use Server-Sent Events (SSE) to stream multiple messages or notifications to the client.

Client                             Server
   |                                  |
   |---- HTTP POST /mcp_endpoint ---->| (client request)
   |                                  | (processes the request)
   |<--- HTTP Response / SSE Stream --| (server response / stream)
   |                                  |

Streamable HTTP features

• Modern standard: This is the preferred method for new remote MCP servers.
• Remote access: You can host it on a different machine from Code Assistant.
• Scalability: Supports multiple concurrent client connections.
• Protocol: Operates over standard HTTP/HTTPS.
• Flexibility: Supports both simple request-response interactions and advanced streaming.
• Single endpoint: Uses one URL for all MCP communication.
• Authentication: May use standard HTTP authentication mechanisms.

Streamable HTTP implementation example

The settings.json configuration:

"mcp.servers": {
  "StreamableHTTPMCPName": {
    "type": "streamable-http",
    "url": "http://localhost:8080/mcp"
  }
}

For server-side implementation, refer to the MCP SDK documentation for StreamableHTTPClientTransport.

Backward compatibility with HTTP+SSE

Starting with protocol version 2024-11-05, clients and servers can maintain backward compatibility with the legacy HTTP+SSE transport.

To support older clients on your server, continue exposing both the legacy SSE endpoint (/events) and the legacy POST endpoint (/message) alongside the new MCP endpoint delegated to Streamable HTTP.

SSE Transport (legacy)

Server-Sent Events (SSE) is a legacy method for remote communication over HTTP/HTTPS. For new implementations, we recommend using Streamable HTTP. SSE remains available only for compatibility with older MCP servers.

How SSE works

1. The client (Code Assistant) connects to the server's SSE endpoint via an HTTP GET request.
2. A persistent connection is established, allowing the server to send events to the client.
3. For client-to-server communication, the client sends HTTP POST requests to a separate endpoint.
4. The communication takes place over two channels:
   • Event stream (GET) for server-to-client updates.
   • Message endpoint (POST) for client-to-server requests.

SSE implementation example

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
import express from 'express';

const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Registering tools...

// Using SSE transport
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
  console.log('MCP server listening on port 3000');
});

Local deployment vs hosting

Your choice between STDIO and SSE transports directly impacts how you deploy and manage your MCP servers.

STDIO local deployment

STDIO servers run locally on the same machine as your Code Assistant. This has several important implications:

• Installation: You need to install the server executable on each user's machine.
• Distribution: You have to provide installation packages for different operating systems.
• Updates: Each installation must be updated individually.
• Resources: The solution consumes local machine resources (CPUs, RAM, and disk space).
• Access control: The solution relies on local OS file permissions.
• Integration: Seamless integration with local system resources (files and processes).
• Execution lifecycle: Starts and stops together with Code Assistant as a child process.
• Dependencies: All runtime dependencies must be installed on the user's machine.

Hands-on example

An STDIO-based local file search tool will:

• Run on the user's computer.
• Have direct access to the local file system.
• Start on Code Assistant's request.
• Require no network configuration.
• Need to be installed alongside Code Assistant or via a package manager.

Streamable HTTP or SSE hosting

You can deploy Streamable HTTP (recommended), as well as legacy SSE servers, on remote servers to access them over a network:

• Installation: Deployed once on a server accessible to many users.
• Distribution: Single deployment serves multiple clients.
• Updates: Centralized updates affect all users immediately.
• Resources: Consumes server resources, not local machine resources.
• Access control: Managed through authentication and authorization systems.
• Integration: More complex integration with user-specific resources.
• Execution: Runs as an independent, often long-running service.
• Dependencies: Managed on the server, not on user machines.

Hands-on example

Here are the features of an SSE-based database query tool:

• Runs on a central server.
• Connects to databases using server-side credentials.
• Continuously available to multiple users.
• Requires proper network security configuration.
• Deployed using containerized or cloud technologies.

Hybrid approaches

Some use cases benefit from hybrid architectures:

• STDIO with network access: a local STDIO server acting as a proxy to remote services.
• SSE with local commands: a remote SSE server that can trigger operations on the client machine via callbacks.
• Gateway pattern: STDIO servers handling local operations while connecting to SSE servers for specialized functionality.

Selecting a transport type