MCP supports transport mechanisms for communication between Bob and MCP servers.

Overview

MCP offers three transport options, each suited for different deployment scenarios:

STDIO transport (local servers)
Streamable HTTP transport (modern standard for remote servers)
SSE transport (legacy remote option)

Each transport has distinct characteristics, advantages, and use cases.

STDIO transport

STDIO transport runs locally on your machine and communicates via standard input/output streams.

How STDIO transport works

Bob spawns an MCP server as a child process
Communication happens through process streams: Bob writes to the server's STDIN, the server responds to STDOUT
Each message is delimited by a newline character
Messages are formatted as JSON-RPC 2.0

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

STDIO characteristics

Locality: Runs on the same machine as Bob
Performance: Very low latency and overhead (no network stack involved)
Simplicity: Direct process communication without network configuration
Relationship: One-to-one relationship between client and server
Security: Inherently more secure with no network exposure

When to use STDIO

STDIO transport is ideal for:

Local integrations and tools running on the same machine
Security-sensitive operations
Low-latency requirements
Single-client scenarios (one Bob 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'});
// Register tools...

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

Streamable HTTP transport is the modern standard for remote MCP server communication, replacing the older HTTP+SSE transport. It operates over HTTP/HTTPS and allows for more flexible server implementations.

How Streamable HTTP transport works

The server provides a single HTTP endpoint (MCP endpoint) that supports both POST and GET methods
Bob sends requests to this MCP endpoint using HTTP POST
The server processes the request and sends back a response
Optionally, the server can use Server-Sent Events (SSE) over the same connection to stream multiple messages or notifications to Bob

This allows for basic request-response interactions as well as more advanced streaming and server-initiated communication.

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

Streamable HTTP characteristics

Modern standard: Preferred method for new remote MCP server implementations
Remote access: Can be hosted on a different machine from Bob
Scalability: Can handle multiple client connections concurrently
Protocol: Works over standard HTTP/HTTPS
Flexibility: Supports simple request-response and advanced streaming
Single endpoint: Uses a single URL path for all MCP communication
Authentication: Can use standard HTTP authentication mechanisms
Backwards compatibility: Servers can maintain compatibility with older HTTP+SSE clients

When to use Streamable HTTP

Streamable HTTP transport is ideal for:

All new remote MCP server developments
Servers requiring robust, scalable, and flexible communication
Integrations that might involve streaming data or server-sent notifications
Public services or centralized tools
Replacing legacy SSE transport implementations

Streamable HTTP implementation example

Configuration in settings.json:

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

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

Backwards compatibility with HTTP+SSE

Clients and servers can maintain backwards compatibility with the deprecated HTTP+SSE transport.

Servers wanting to support older clients should continue to host both the SSE (/events) and POST (/message) endpoints of the old transport, alongside the new MCP endpoint defined for the Streamable HTTP transport.

SSE transport (legacy)

Server-Sent Events (SSE) transport runs on a remote server and communicates over HTTP/HTTPS. For new remote servers, use Streamable HTTP transport instead.

How SSE transport works

Bob connects to the server's SSE endpoint via HTTP GET request
This establishes a persistent connection where the server can push events to Bob
For client-to-server communication, Bob makes HTTP POST requests to a separate endpoint
Communication happens over two channels:
- Event stream (GET): Server-to-client updates
- Message endpoint (POST): Client-to-server requests

Client                             Server
  |                                  |
  |---- HTTP GET /events ----------->| (establish SSE connection)
  |<---- SSE event stream -----------| (persistent connection)
  |                                  |
  |---- HTTP POST /message --------->| (client request)
  |<---- SSE event with response ----| (server response)
  |                                  |

SSE characteristics

Remote access: Can be hosted on a different machine from Bob
Scalability: Can handle multiple client connections concurrently
Protocol: Works over standard HTTP (no special protocols needed)
Persistence: Maintains a persistent connection for server-to-client messages
Authentication: Can use standard HTTP authentication mechanisms

When to use SSE

SSE transport is suitable for:

Remote access across networks
Multi-client scenarios
Public services
Centralized tools that many users need to access
Integration with web services

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'});
// Register tools...

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

Deployment considerations

The choice between STDIO and remote transports (Streamable HTTP or SSE) directly impacts how you deploy and manage your MCP servers.

STDIO: Local deployment

STDIO servers run locally on the same machine as Bob:

Installation: The server executable must be installed on each user's machine
Distribution: You need to provide installation packages for different operating systems
Updates: Each instance must be updated separately
Resources: Uses the local machine's CPU, memory, and disk
Access control: Relies on the local machine's filesystem permissions
Integration: Easy integration with local system resources (files, processes)
Execution: Starts and stops with Bob (child process lifecycle)
Dependencies: Any dependencies must be installed on the user's machine

Example use case:

A local file search tool using STDIO would:

Run on the user's machine
Have direct access to the local filesystem
Start when needed by Bob
Not require network configuration
Need to be installed alongside Bob or via a package manager

Remote: Hosted deployment

Remote servers (Streamable HTTP or SSE) can be deployed to remote servers and accessed over the network:

Installation: Installed once on a server, accessed by many users
Distribution: Single deployment serves multiple clients
Updates: Centralized updates affect all users immediately
Resources: Uses 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 service (often continuously)
Dependencies: Managed on the server, not on user machines