StreamableHTTP Transport
MCPDefinition
An MCP transport that communicates over HTTP with Server-Sent Events (SSE) for streaming. Runs as an independent network service — not a subprocess. Enables multiple simultaneous clients, per-request authentication, and remote deployment. The correct transport for shared, cloud-hosted, or containerised MCP servers.
Example Usage
Deploy a shared internal-tools MCP server on Kubernetes and register it in .mcp.json with a StreamableHTTP URL — all developers connect to the same instance with their own auth tokens.
Why It Matters for the CCA-F Exam
Exam questions probe whether candidates understand the multi-client capability as the decisive factor for choosing StreamableHTTP over stdio. Questions often describe an enterprise scenario — a centralized internal API gateway, a shared code-search server, a production tool on Kubernetes — and ask which transport applies. StreamableHTTP is always the answer when 'shared,' 'remote,' or 'multiple users' appears. Also know that StreamableHTTP uses SSE (not WebSockets) for streaming.
In Depth
StreamableHTTP is the network-capable MCP transport. Unlike stdio — where the client spawns a server subprocess — StreamableHTTP runs as an independent HTTP service. The client opens HTTP connections to a URL; the server has its own lifecycle, scaling, and can serve many clients at once.
Protocol Mechanics
The client sends JSON-RPC requests as HTTP POST bodies to the server's endpoint. The server can respond in two ways depending on the operation:
- Standard JSON response for simple request-reply interactions (e.g., listing tools, calling a fast tool).
- Server-Sent Events (SSE) stream for long-running tools that emit incremental results. The server sets
Content-Type: text/event-streamand pushesdata:events as the work progresses. SSE is a unidirectional server-to-client push channel over a long-lived HTTP response — distinct from WebSockets, which are bidirectional.
This flexibility — JSON for simple calls, SSE for streams — is why the transport is called *streamable* HTTP.
Multi-Client Architecture
Because the server is an independent service, any number of clients can connect simultaneously. A team of 20 engineers can all have their IDEs pointed at the same internal GitHub MCP server without each running a local copy. The server manages its own connection pool, rate limiting, and state — the client just holds a URL.
Per-Request Authentication
Since there is a real network boundary, StreamableHTTP servers require explicit authentication — something stdio servers never need because the client owns the process. Credentials are typically passed as Authorization: Bearer <token> headers on each request. This enables per-user audit logging, token scoping, and revocation — none of which are possible with the process-ownership model of stdio.
When to Choose StreamableHTTP
Choose StreamableHTTP when:
- Multiple users or agents need to share the same server instance
- The server is deployed in a container, VM, or cloud environment
- You need per-user authentication and audit trails
- The server has independent state or scaling requirements
Choose stdio for single-developer tooling, CI environments, or any case where the server should live and die with the client process. See MCP Server for how to write a server that branches between both transports.
Example
.mcp.json showing a StreamableHTTP server (remote, shared, auth via header) alongside a stdio server (local, subprocess). The transport field differentiates them. ${ACME_MCP_TOKEN} is expanded from the shell environment at session start.
// .mcp.json — registering a StreamableHTTP server alongside a local stdio server
{
"mcpServers": {
"shared-internal-tools": {
"transport": "streamable-http",
"url": "https://mcp.internal.acme-corp.com/tools",
"headers": {
"Authorization": "Bearer ${ACME_MCP_TOKEN}"
}
},
"local-file-server": {
"command": "node",
"args": ["./mcp-servers/file-ops/index.js"]
}
}
}How It's Tested & Common Confusions
Patterns to watch for:
- Scenario: "A company deploys an MCP server as a Docker container that all developers connect to." Which transport? → StreamableHTTP.
- Scenario: "A solo developer wants the fastest way to wire up a personal productivity tool that only they use." → stdio is the better fit — StreamableHTTP adds unnecessary complexity here.
- Distinguish SSE streaming from WebSocket: MCP's StreamableHTTP uses SSE (unidirectional server-to-client push), not WebSockets (bidirectional). This distinction appears in questions about the underlying mechanism.
- Authentication: questions about token-based auth or per-user permissions in MCP always map to StreamableHTTP, never stdio.
Frequently Asked Questions
Does StreamableHTTP require a persistent connection?
No. Each request-response pair is a standard HTTP round-trip. Streaming responses use SSE, which is a long-lived HTTP response, but the connection is not required to persist between separate tool invocations. This makes StreamableHTTP more firewall-friendly than WebSocket-based approaches.
Can a StreamableHTTP server also support stdio clients?
No — transport is a server-side implementation choice. A server implements one transport (stdio or StreamableHTTP), and clients must use a matching transport configuration. You can run two server instances — one per transport — if you genuinely need both, but a single server process exposes one transport type.
What is the difference between SSE and WebSockets in the MCP context?
SSE (Server-Sent Events) is a unidirectional channel: the server pushes data to the client over a long-lived HTTP response. WebSockets are bidirectional. MCP's StreamableHTTP transport uses SSE for streaming — the client sends each new request as a fresh HTTP POST, and the server streams the response back. This design keeps the transport stateless at the request level while still supporting incremental results.