What is the difference between MCP stdio and HTTP transports?

stdio runs the MCP server as a local subprocess and exchanges JSON-RPC over standard input/output — ideal for local tools on the same machine. HTTP transports run the server as a remote service over the network. Remote agents and hosted clients need an HTTP transport; stdio can't be reached remotely.

Is SSE transport deprecated in MCP?

The original standalone HTTP+SSE transport (two endpoints, a GET SSE stream plus a POST channel) has been superseded by streamable HTTP, which uses a single endpoint that can return either a plain JSON response or an SSE stream per request. New remote servers should implement streamable HTTP; SSE responses still exist within it.

Which MCP transport should a remote server use?

Streamable HTTP. It's a single HTTPS endpoint that accepts POSTed JSON-RPC and replies with JSON or an SSE stream, supports optional sessions via the Mcp-Session-Id header, and is what current clients expect from remote servers.

MCPPulse

Guide · Updated July 2026 · 6 min read

MCP transports explained

Direct answer: MCP has one message format (JSON-RPC 2.0) carried over different transports. Three matter: stdio (local subprocess), the older HTTP+SSE (two endpoints, now superseded), and streamable HTTP (one endpoint, JSON or SSE per request). Remote servers should use streamable HTTP.

stdio — local subprocess

The client launches the server as a child process and exchanges JSON-RPC over stdin/stdout. Zero network, lowest latency, dead simple — but only reachable on the same machine. Perfect for local dev tools and desktop clients; useless for a hosted agent that needs to reach your server over the internet.

HTTP + SSE (legacy) — two endpoints

The first remote transport: the client opens a long-lived GET Server-Sent-Events stream for server→client messages and POSTs to a separate endpoint for client→server messages. It works, but the two-endpoint design is awkward to host and scale, and it has been superseded. You'll still meet older servers speaking it.

Streamable HTTP — one endpoint (current)

The current remote transport collapses everything to a single HTTPS endpoint:

The client POSTs JSON-RPC with Accept: application/json, text/event-stream.
The server replies with either a plain JSON response or an SSE stream — per request, whichever fits.
Optional sessions via the Mcp-Session-Id response header, echoed on later requests.

This is what MCP Pulse speaks when it scans, and what current clients expect from a remote server.

Which should you use?

Scenario	Transport
Local tool, same machine	stdio
New remote/hosted server	Streamable HTTP
Maintaining an old deployment	HTTP+SSE (plan to migrate)

Common transport bugs

Returning SSE but never emitting a data: event with the JSON-RPC result — the client hangs.
Issuing an Mcp-Session-Id but not accepting it back on the next request.
Missing the text/event-stream accept handling, so streaming responses break.
Serving over plain HTTP — remote clients refuse it.

MCP Pulse detects the transport, parses JSON and SSE responses, and flags exactly these failures.

Not sure your transport is right?

Scan the endpoint — we handshake over streamable HTTP and tell you what's wrong.

Scan my server →