MCP Scorecard

When the MCP specification introduced streamable-HTTP as a transport option, it was positioned as the successor to SSE (Server-Sent Events) for remote MCP servers. The question was how fast adoption would come. The answer: fast.

The Numbers

These aren't exclusive — 162 servers declare both stdio and streamable-HTTP, serving local and remote use cases simultaneously. But the striking number is 897 servers that use streamable-HTTP with no stdio fallback. These are remote-only services that chose the newer transport from the start.

Of the 232 new servers this batch, 70 (30%) chose streamable-HTTP. Only 9 chose SSE. The rest use stdio. New remote-first servers are overwhelmingly picking streamable-HTTP over SSE.

Why Streamable-HTTP

The technical advantages are straightforward:

• Bidirectional on one connection. SSE is server-to-client only — the client sends requests via HTTP POST, and the server pushes events via an SSE stream. Streamable-HTTP allows both directions on the same connection, reducing complexity.
• Standard HTTP semantics. Streamable-HTTP uses regular HTTP request/response patterns with optional streaming. This means it works with standard HTTP infrastructure — load balancers, proxies, CDNs, caching layers — without special configuration. SSE often requires sticky sessions or special proxy rules.
• Connection management. SSE requires maintaining a persistent connection for the event stream. If the connection drops, the client must reconnect and potentially replay events. Streamable-HTTP handles this more gracefully with standard HTTP retry semantics.
• Stateless option. Servers can operate statelessly — each request is self-contained. SSE inherently requires server-side state to maintain the event stream. This matters for serverless deployments where you want to spin up, handle a request, and spin down.

Who's Choosing What

The transport choice correlates with server type:

Stdio dominates local tools. Developer tools, file system utilities, code analysis, database connectors — anything that runs on the user's machine uses stdio. This makes sense: stdio is the simplest transport, requires no network setup, and keeps data local.

Streamable-HTTP dominates hosted services. Commercial APIs, SaaS integrations, marketplace services, and pay-per-call tools overwhelmingly choose streamable-HTTP. Notable examples from this batch: Pyth Network (price feeds, score 71), SEC Intelligence (financial analysis, score 71), Evidra (policy guardrails, score 55), and the entire harvey- payment suite.

SSE is legacy. At 193 servers (6.2%), SSE is still present but no longer growing. Most SSE servers were registered months ago. New entrants choosing SSE are rare — only 9 of 232 this batch. Unless a server has existing SSE clients to support, there's no reason to choose it over streamable-HTTP for new development.

What This Means

The MCP ecosystem is splitting into two worlds:

1. Local tools over stdio — the original MCP use case. Your coding assistant calls a local tool that reads files, runs commands, queries a database. Fast, simple, no authentication needed. Two-thirds of the registry.
2. Remote services over streamable-HTTP — the growing use case. Hosted APIs, commercial services, multi-user platforms. Requires authentication, handles concurrent connections, works behind load balancers. One-third of the registry and growing.

The 162 servers offering both transports are the bridge — they work locally for individual developers and remotely for team deployments. This dual-transport pattern may become the standard for tools that want maximum reach.

For MCP client developers, the practical implication is clear: streamable-HTTP support is no longer optional. A client that only speaks stdio misses a third of the registry. A client that only speaks stdio and SSE still misses hundreds of streamable-HTTP-only servers. Full transport coverage means supporting all three.

Data sourced from the MCP Registry via MCP Scorecard. Transport data from registry metadata.