Docker MCP Transport Types: stdio, SSE, and Streamable HTTP

mcpdockerprotocolai-tools

The Model Context Protocol (MCP) defines how AI assistants communicate with external tools and data sources. When running MCP servers in Docker containers, understanding transport types is critical for choosing the right architecture.

The Three Transport Types

1. stdio (Standard I/O)

The simplest and most common transport. Communication happens through Unix pipes—stdin for input, stdout for output.

{
  "mcpServers": {
    "my-server": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "my-mcp-server:latest"]
    }
  }
}

Key characteristics:

• Client spawns server as a subprocess
• Messages are newline-delimited JSON-RPC
• No network exposure (inherently secure)
• Container lifecycle tied to client connection
• Requires -i flag in Docker for stdin

Best for: Local development, single-client scenarios, security-sensitive deployments.

2. SSE (Server-Sent Events) — Deprecated

The original HTTP-based transport, now deprecated in favor of Streamable HTTP.

How it worked:

• Two endpoints: POST for requests, SSE stream for responses
• Unidirectional streaming from server to client
• Session management was complex

Why deprecated: The dual-endpoint architecture complicated error handling and deployment. New implementations should use Streamable HTTP instead.

3. Streamable HTTP (Modern Standard)

The current standard for remote MCP access, introduced in protocol version 2025-03-26.

# docker-compose.yml
services:
  mcp-server:
    image: my-mcp-server:latest
    ports:
      - "8080:8080"
    environment:
      - MCP_TRANSPORT=http
      - PORT=8080
      - HOST=0.0.0.0

Key characteristics:

• Single HTTP endpoint handles both POST and GET
• Supports SSE streaming within responses (optional)
• Handles multiple concurrent clients
• Proper session management via Mcp-Session-Id header
• Works through proxies and load balancers

Best for: Production deployments, multi-client access, cloud environments.

Choosing a Transport for Docker

Rule of thumb: Start with stdio for development, graduate to Streamable HTTP when production demands grow.

Bridging Transports

Most MCP clients expect stdio, but you may need HTTP for remote servers. Gateway tools like mcp-proxy bridge between transports:

Client (stdio) → Gateway → Server (Streamable HTTP)

This pattern lets you run scalable HTTP servers while supporting stdio-only clients.

Security Considerations

• stdio: No network attack surface—communication stays within the machine
• Streamable HTTP: Always use TLS in production; validate Origin headers to prevent CSRF
• Docker MCP Gateway: Provides interceptors that filter MCP tool calls at the protocol level, working across all transport modes

The transport you choose shapes your entire MCP architecture. For Docker deployments, stdio’s simplicity wins for local tools, while Streamable HTTP unlocks production scalability.