What Is Streamable HTTP and Why Did FastMCP Adopt It?
Streamable HTTP is the recommended production transport for MCP (Model Context Protocol) servers, replacing legacy SSE (Server-Sent Events) transport for service-to-service communication.
SSE works well for streaming to browsers. For service-to-service communication between Engine and MCP server, it introduces unnecessary complexity.
Skyflo migrated to Streamable HTTP for a simple reason:
Reliability and lifecycle management should be boring.
What Problems Did SSE Transport Create?
SSE for service-to-service communication works but comes with sharp edges:
| SSE Problem | Impact |
|---|---|
| Complex connection management | Must handle reconnection, backoff, keep-alives |
| Awkward cleanup | Connections linger under concurrency |
| Proxy incompatibility | Buffering issues with common proxies |
| CancelledError storms | High load causes cascade failures |
These issues meant spending engineering time on transport reliability instead of tool functionality.
What Got Simpler After Migration?
The migration to Streamable HTTP simplified:
| Component | Before (SSE) | After (Streamable HTTP) |
|---|---|---|
| MCP server startup | SSE configuration, keep-alive tuning | HTTP server, standard config |
| Engine MCP client | Custom connection handling | Clean context manager |
| Deployment | Special proxy configuration | Standard HTTP |
The difference isn't just performance—it's the difference between "works in staging" and "works in any cluster topology."
Why Does Transport Reliability Matter for Tool Execution?
Tool execution is where an AI agent interacts with real systems. It's where:
- Timeouts happen — kubectl commands against large clusters
- Retries matter — Transient failures in external systems
- Cancellation matters — User clicks "stop" mid-operation
If your tool transport is fragile, the entire agent feels fragile.
Streamable HTTP didn't make Skyflo "smarter." It made it calmer—and calm systems are the ones operators trust during incidents.
How Do You Migrate from SSE to Streamable HTTP?
MCP Server changes:
# Before: SSE transport
mcp = FastMCP(transport="sse")
# After: Streamable HTTP (now default)
mcp = FastMCP() # HTTP is defaultClient changes:
# Before: SSE client with reconnection logic
async with sse_client(url) as client:
# Complex error handling...
# After: Clean HTTP context manager
async with http_client(url) as client:
result = await client.call_tool(...)Proxy configuration: Standard HTTP proxy settings work. No special SSE buffering configuration needed.
Related articles:
FAQ: FastMCP Streamable HTTP Migration
What is Streamable HTTP in MCP? Streamable HTTP is the recommended transport for MCP servers that provides clean request/response semantics with optional streaming, replacing SSE for service-to-service communication.
Why was SSE problematic for service-to-service communication? SSE was designed for browser streaming and brings unnecessary complexity (connection management, proxy issues, cleanup challenges) when used between backend services.
Does this affect browser streaming? No. Browser-facing streaming (e.g., the Engine → UI stream) still uses SSE. This change only affects Engine → MCP server communication.
What are the performance benefits of Streamable HTTP? Primary benefits are reliability and simplicity, not raw performance. Fewer connection issues, simpler error handling, and better behavior under load.