Loomal

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.