MCP stdio vs Streamable HTTP: which one your client needs

Every MCP config answers one question first: how does the client reach the server? That is the transport. The MCP specification defines two standard transports, stdio and Streamable HTTP, and an older third, HTTP+SSE, that you still meet in copied snippets. You do not need to know the wire format to configure a client, but you do need to recognize which transport a snippet uses and whether your client supports it. This guide is written for people who configure clients, not for server authors.

What a transport is

MCP messages are JSON-RPC: a request such as tools/list or tools/call, and a response. The transport is the pipe those messages travel through. The tools are the same over either pipe. A fetch tool behaves identically whether it is reached through stdio or over HTTP; what changes is where the server runs, how it is started, how it authenticates you and where pages are fetched.

stdio: a local process

With stdio, the client starts the server as a child process and writes messages to its standard input; the server answers on standard output. The config is a command:

{
  "mcpServers": {
    "fetch": { "command": "uvx", "args": ["mcp-server-fetch"] }
  }
}

That is the reference fetch server from the MCP project, run with Python's uvx. Consequences for you:

• Install. Each machine needs the runtime (Python or Node) and the package.
• Auth. There is none at the transport level. The process runs as you; any secrets it needs come from environment variables.
• Network. Every page is fetched on your machine.
• Logs. Anything the server prints to standard error ends up in the client's log, which helps when debugging.
• Lifetime. The client starts and stops the server. If the command is wrong, nothing connects and the only clue is in the log.

Streamable HTTP: a URL

With Streamable HTTP, the server is already running somewhere, and the client sends each message as an HTTP POST to one endpoint. The server can answer with a single JSON response or open a stream for longer work. The config is a URL plus headers:

claude mcp add --transport http live-web-data https://fetchmcp.net/mcp \
  --header "Authorization: Bearer $LIVE_WEB_DATA_API_KEY"

Consequences for you:

• Install. None. Any client that supports HTTP servers can connect.
• Auth. The MCP authorization spec applies to HTTP transports: a bearer header or an OAuth flow. See the authentication guide.
• Network. Pages are fetched by the hosted service. Some services, Live Web Data API among them, let you choose the country a page is fetched from.
• Sessions. The spec allows a server to keep a session ID across calls. A fetch tool does not need one, because every call is complete on its own, so a stateless server is a natural fit. Stateless servers are simpler to run and recover cleanly when a connection drops.

SSE: deprecated, still around

The original remote transport, HTTP+SSE, used two endpoints: one long-lived Server-Sent Events stream and one POST endpoint. The 2025-03-26 spec revision replaced it with Streamable HTTP. Claude Code's docs mark --transport sse as deprecated, and VS Code tries HTTP first and falls back to SSE only for older servers.

How to spot an outdated snippet:

• --transport sse in a claude mcp add line,
• "type": "sse" in a VS Code or Claude Code JSON entry,
• a URL ending in /sse.

If the server also offers a Streamable HTTP endpoint (often the same URL ending in /mcp), use that. Keep SSE only for servers that offer nothing else.

The mcp-remote bridge

Some clients can only start local commands. Claude Desktop's config file is the common case. mcp-remote fills the gap: the client starts it over stdio, and it forwards each message to the remote server over HTTP.

npx -y mcp-remote https://fetchmcp.net/mcp \
  --header "Authorization: Bearer YOUR_KEY" --transport http-only

--transport http-only tells the bridge to use Streamable HTTP and not try SSE. Use the bridge when:

• the client has no HTTP option in its config file,
• the client's built-in remote option does not support the auth your server uses (for example, a static bearer header),
• you want to see the forwarded traffic in one place while debugging.

Drop it when the client connects to HTTP servers natively: Claude Code, Cursor and VS Code all do. The bridge needs Node.js, adds one more process to debug, and has a Windows quirk with spaces in arguments that the setup guide shows how to avoid.

Which one for a fetch tool

Neither transport is "better". Pick by what you need:

Whichever you pick, set a result size cap before the first real call. The token budget guide explains why.

A remote example

Live Web Data API, made by Teneo Labs, runs a stateless Streamable HTTP server with a bearer key, the same key as its REST API. Its two tools are get_page_contents and get_account_status. The current client configs are in the MCP docs.