Why MCP servers need to move beyond SSE
The Model Context Protocol (MCP) standardizes how AI models connect to external tools and services, and it's now widely supported by clients such as Cursor, Claude, and Windsurf. Platforms like Zapier, Composio, Vapi, and Solana have built their own MCP servers to make their capabilities available across this ecosystem. As adoption grows, however, the original transport mechanisms are showing their limits.
When MCP's first specification shipped in November 2024, it defined two transports: Standard IO (stdio), which required running the server locally, and Server-Sent Events (SSE), which enabled remote hosting. The problem with SSE is that it holds a persistent connection open between client and server, even when no data is flowing. That makes it a poor fit for high-traffic, remotely hosted MCP servers.
Streamable HTTP becomes the standard transport
In March 2025, a revised MCP specification introduced Streamable HTTP as the recommended transport, effectively replacing SSE. Streamable HTTP removes the need for persistent connections, supporting both stateless and stateful server models over standard HTTP requests. That makes it a far more sustainable option for production MCP deployments.
Despite the spec change, adoption has been slow. Many existing MCP clients still only support stdio and SSE, and server developers have been hesitant to invest in yet another transport. Developers using the Vercel MCP adapter, however, get built-in support for both Streamable HTTP and SSE. The SSE transport can be disabled if you want to align strictly with the newer spec:
app/[transport]/route.ts
import { createMcpHandler } from '@vercel/mcp-adapter';
const handler = createMcpHandler(server => {
server.tool(
'roll_dice',
'Rolls an N-sided die',
{ sides: z.number().int().min(2) },
async ({ sides }) => {
const value = 1 + Math.floor(Math.random() * sides);
return { content: [{ type: 'text', text: `🎲 You rolled a ${value}!` }] };
}
);
});
export { handler as GET, handler as POST, handler as DELETE };
An example MCP server with a single tool call. Running it this way means the server works with modern Streamable HTTP-capable clients immediately, while SSE support covers older clients.
Bridging the gap for legacy clients
For clients that haven't implemented Streamable HTTP yet, the mcp-remote npm package can act as a proxy, translating Streamable HTTP into stdio. A small configuration change on the server side, similar to what Solana uses, lets you point mcp-remote at your server URL. This gives you the efficiency of Streamable HTTP today, without waiting for the client ecosystem to catch up. Once native support is widely available, mcp-remote can be dropped entirely.
The efficiency gains are real. One MCP server deployed on Vercel switched over to Streamable HTTP entirely and cut CPU usage by more than half, even while continuing to grow its user base:
Building for both current and future clients
The MCP ecosystem is evolving quickly, and transport support is fragmented across clients. By building on top of the MCP adapter—with Fluid compute underneath—you can deploy MCP servers that work with today's SSE-based clients while positioning them for the Streamable HTTP future. That dual support, combined with the mcp-remote proxy for stdio-only clients, covers the full spectrum of the current client landscape.
For teams looking to get started, the Next.js MCP template offers a straightforward path to a running MCP server, with the adapter package handling the transport details either way.
