Streamable HTTP Transport
Streamable HTTP transport is the current MCP transport for remote servers, using HTTP POST with optional server-sent event streaming over a single endpoint.
Also known as: streamable HTTP, MCP remote transport
What is Streamable HTTP transport?
Streamable HTTP is the modern transport the Model Context Protocol uses for remote servers, replacing the earlier HTTP+SSE design. A client sends JSON-RPC requests to a single HTTP endpoint, and the server answers each request with either a plain JSON payload or — when it needs to send multiple messages or stream progress — a server-sent event stream on that same response.
The defining feature is the single endpoint. Where the old SSE transport split the conversation between a long-lived GET stream and a separate POST endpoint, Streamable HTTP keeps every exchange inside one ordinary HTTP request/response cycle.
How a session works
The client POSTs an initialize request to the server's MCP endpoint and receives a session identifier, which it includes on subsequent requests. Each tool call, resource read, or prompt request is its own POST; the server decides per response whether to reply with JSON or upgrade to an event stream for long-running work.
Servers can be stateless or stateful. A stateless server treats every request independently, which suits serverless platforms; a stateful one maintains session context. Either way, nothing about the transport requires a held-open connection, so it deploys cleanly behind load balancers, CDNs, and edge runtimes.
Why it replaced HTTP+SSE
The two-endpoint SSE design fought standard web infrastructure: proxies time out idle streams, serverless platforms bill for held-open connections, and correlating POSTed requests with the right stream added server complexity. Streamable HTTP removes the standing connection while keeping streaming available when a response genuinely needs it.
Most clients retain SSE fallback for older servers, but the specification treats Streamable HTTP as the current standard, and new remote servers in mid-2026 should target it exclusively.
Why it matters for monetization
Because every exchange is plain HTTP, a Streamable HTTP server can sit behind the same middleware as any web API — including payment middleware. That is the hook the x402 protocol uses: a paid tool call first receives an HTTP 402 Payment Required response carrying the price and payment address; the agent's wallet signs a USDC payment and retries; the payment settles on Base in about two seconds, and only then does the handler run.
This per-request gate is impractical on stdio (no HTTP surface) and awkward on legacy SSE (the stream is already open). Streamable HTTP is effectively the transport that makes per-call MCP pricing possible.
Streamable HTTP on the Loomal Index
The Loomal Index identifies which listed MCP servers expose remote endpoints, and live-probes tool lists from servers that do. When a maintainer claims a listing, attaching x402 pricing — minimum $0.01 per call, settled in USDC with signed Ed25519 receipts — assumes a Streamable HTTP endpoint, since that is where the payment gate lives.
If your server is stdio-only today, deploying a Streamable HTTP version is the prerequisite step before pricing it; the open-source local package can keep shipping unchanged alongside it.