Why MCP Dropped SSE for Streamable HTTP: A Deep Dive

Since its introduction, the Model Context Protocol (MCP) has rapidly evolved, improving how AI agents communicate with external services. A major change announced in the March 26, 2025 MCP specification replaces Server‑Sent Events (SSE) with Streamable HTTP as the preferred transport for remote MCP servers.

Version note: The TypeScript SDK 1.10.0 released on April 17, 2025 is the first version supporting Streamable HTTP, superseding the SSE transport used in the November 5, 2024 protocol version.

Original method: Server‑Sent Events (SSE)

When MCP first launched, it relied on SSE with two separate endpoints:

A SSE endpoint ( /sse) for establishing a persistent connection to receive responses.

A separate message endpoint ( /sse/messages) for the client to send requests.

This dual‑endpoint design introduced several challenges:

Connection management complexity: Maintaining two connections increases implementation difficulty.

Scalability limits: Long‑lived SSE connections consume resources and are hard to scale.

Reliability issues: If an SSE connection drops during a long operation, the response is lost.

Implementation overhead: Both server and client must coordinate the separate connections.

For developers implementing an MCP server, this means more complex code, additional error handling, and careful correlation of requests and responses across endpoints.

Enter Streamable HTTP: Simpler and More Powerful

Streamable HTTP uses a single endpoint for bidirectional communication, offering a cleaner solution that addresses SSE’s limitations while remaining backward compatible.

1. Single‑Endpoint Communication

Clients now interact with the MCP server via a single endpoint (typically /mcp) instead of managing two separate connections, simplifying implementation and connection management.

// Replace two endpoints:
// - /sse (for receiving)
// - /sse/messages (for sending)

// Now use a single endpoint:
// - /mcp (for both sending and receiving)

2. Dynamic Connection Upgrades

Streamable HTTP can adapt dynamically:

For simple, fast operations it behaves like a standard HTTP request/response.

For long‑running or streaming responses it automatically upgrades to an SSE‑like streaming connection.

This flexibility optimizes both simple queries and complex tasks.

3. Bidirectional Communication

Unlike traditional HTTP or SSE, Streamable HTTP enables true bidirectional communication, allowing the server to push notifications or request additional information over the same connection.

4. Improved Error Handling

Unified request/response channels simplify error handling, making debugging and monitoring easier.

Backward Compatibility

The MCP TypeScript SDK provides seamless compatibility between Streamable HTTP and the older SSE transport.

Client‑Side Compatibility

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { SSEClientTransport } from "@modelcontextprotocol/sdk/client/sse.js";

let client = undefined;
const baseUrl = new URL(url);

try {
  // First try Streamable HTTP
  client = new Client({ name: 'streamable-http-client', version: '1.0.0' });
  const transport = new StreamableHTTPClientTransport(new URL(baseUrl));
  await client.connect(transport);
  console.log("Using Streamable HTTP transport");
} catch (error) {
  // Fallback to SSE
  console.log("Streamable HTTP failed, falling back to SSE");
  client = new Client({ name: 'sse-client', version: '1.0.0' });
  const sseTransport = new SSEClientTransport(baseUrl);
  await client.connect(sseTransport);
  console.log("Using SSE transport");
}

Server‑Side Compatibility

import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";

const server = new McpServer({ name: "backwards-compatible-server", version: "1.0.0" });

const app = express();
app.use(express.json());

const transports = { streamable: {}, sse: {} };

// Modern Streamable HTTP endpoint
app.all('/mcp', async (req, res) => {
  const transport = new StreamableHTTPServerTransport(req, res);
  transports.streamable[transport.sessionId] = transport;
  res.on("close", () => { delete transports.streamable[transport.sessionId]; });
  await server.connect(transport);
});

// Legacy SSE endpoint
app.get('/sse', async (req, res) => {
  const transport = new SSEServerTransport('/messages', res);
  transports.sse[transport.sessionId] = transport;
  res.on("close", () => { delete transports.sse[transport.sessionId]; });
  await server.connect(transport);
});

// Legacy message endpoint for old clients
app.post('/messages', async (req, res) => {
  const sessionId = req.query.sessionId as string;
  const transport = transports.sse[sessionId];
  if (transport) {
    await transport.handlePostMessage(req, res, req.body);
  } else {
    res.status(400).send('Session ID not found');
  }
});

app.listen(3000);

Why Deprecate SSE?

Although SSE initially served the MCP ecosystem well, several architectural constraints make it unsuitable for complex AI agent interactions:

1. Connection Management Overhead

The dual‑endpoint model adds unnecessary complexity and more potential failure points.

2. Scaling Challenges

Persistent SSE connections consume resources even when idle, stressing infrastructure at scale.

3. Limited Recovery Options

There is no built‑in way to resume a dropped long‑running SSE connection, risking data loss.

4. Compatibility with HTTP/2 and HTTP/3

Some SSE implementations struggle with newer HTTP protocols, limiting performance gains.

5. Bidirectional Communication Limits

SSE’s one‑way nature forces separate channels for client‑to‑server messages.

Future Roadmap: Upcoming Improvements

While the current Streamable HTTP implementation matches SSE functionality, the MCP specification outlines several forthcoming capabilities:

1. Recoverability

Future versions will allow clients to resume operations after an unexpected disconnect, eliminating the need to keep connections open for long‑running AI tasks.

2. Cancelability

An explicit cancellation mechanism will let clients cleanly terminate operations, improving resource management.

3. Session Management

Secure sessions with unique IDs will maintain state across multiple connections, enabling more sophisticated multi‑request interactions.

Which Will Become the Standard?

Given its architectural advantages and the direction of the MCP spec, Streamable HTTP is poised to become the standard transport for remote MCP servers. Its simplicity, flexibility, and advanced capabilities make it the natural choice for future development.

SSE will remain supported for backward compatibility, ensuring a smooth transition period for developers migrating to the new transport.

Recommendations for Developers

As the MCP ecosystem evolves, consider the following advice:

For New MCP Servers

Start with Streamable HTTP: Build your implementation using the new transport from the outset.

Follow the spec closely: The MCP specification is rapidly evolving.

Implement robust error handling: Design your server to gracefully handle connection issues and client errors.

For Existing MCP Servers

Add dual support: Implement both SSE and Streamable HTTP transports.

Plan a migration path: Determine how you will eventually transition to Streamable HTTP‑only.

Update client libraries: Ensure your clients support both transport methods.

For MCP Client Developers

Add Streamable HTTP support: Update your client to use the new transport when available.

Retain SSE fallback: Keep SSE for compatibility with existing services.

Leverage new capabilities: Design your client to take advantage of upcoming features as they are released.

Conclusion

Moving from SSE to Streamable HTTP represents a significant architectural improvement for the MCP ecosystem. By simplifying the connection model, enabling bidirectional communication, and laying the groundwork for recoverability and cancelability, Streamable HTTP addresses many of the limitations of the original SSE implementation.

In the short term both transports will coexist for backward compatibility, but Streamable HTTP is clearly the future direction for MCP. Its single‑endpoint model aligns better with modern network architectures and provides a more robust foundation for the complex interactions required by AI agents.

Developers should now embrace this transition, ensuring their implementations support both transports while planning to adopt Streamable HTTP as the primary method moving forward.