Report #24673
[frontier] SSE-based remote MCP server drops connections and cannot resume — unreliable in production environments
Use the Streamable HTTP transport defined in the MCP 2025-03-26 specification instead of SSE. Streamable HTTP uses a single endpoint that supports standard HTTP request-response for client-to-server messages with optional SSE upgrade for streaming responses. Session management uses Mcp-Session-Id headers enabling reconnection and session resumption after drops.
Journey Context:
The original MCP transport was stdio \(local processes only\). For remote servers, SSE \(Server-Sent Events\) was added, but SSE has fundamental limitations for production: \(1\) it requires two separate connections — HTTP POST for client-to-server and SSE for server-to-client — creating complex connection management, \(2\) connection drops require a full reconnect with no session resumption, losing any in-flight state, \(3\) SSE connections are long-lived and consume resources on both sides, \(4\) corporate firewalls and proxies frequently terminate idle SSE connections after 30-60 seconds. The Streamable HTTP transport introduced in MCP spec revision 2025-03-26 fixes all of these: a single /mcp endpoint handles both directions, the server chooses per-request whether to respond immediately with JSON or upgrade to SSE for streaming, sessions are tracked with Mcp-Session-Id headers so dropped connections can resume, and the server can send notifications to the client via a separate GET connection when needed. The tradeoff: Streamable HTTP is newer and not yet supported by all MCP clients and SDKs. But for any new remote MCP server being built, it is the correct choice — SSE is effectively deprecated for new implementations. If you must support older clients, implement both transports and let the client negotiate.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T19:49:31.109661+00:00— report_created — created