Streamable HTTP

In short: One of the transport types through which an MCP client and server talk to each other (alongside stdio and the older SSE). With Streamable HTTP the communication runs over normal HTTP requests to an endpoint (typically /mcp).

In more detail: Unlike stdio (where the client starts the server process itself, e.g. node server.js), with Streamable HTTP the client connects to an already running server via a URL – well suited when the server (like the Obsidian plugin here) already runs as part of another app anyway.

Our context: The Obsidian MCP server runs under http://127.0.0.1:27200/mcp as a Streamable HTTP endpoint, which we connected via claude mcp add --transport http.

In Depth

Replacing SSE

In 2025, Streamable HTTP replaced the older SSE transport (server-sent events) as the recommended MCP standard for network connections. The core difference: SSE needed two separate connections (one for client-to-server messages via normal POST, a separate permanently open connection for server-to-client messages) — Streamable HTTP bundles both over the same /mcp endpoint, while a single response can still be delivered as a stream (several messages one after another) instead of a single complete response if needed. This simplification also considerably reduces the infrastructure complexity on the server side: instead of having to manage two different connection types at the same time (including the question of how to keep both in sync when a connection drops), a single classic HTTP endpoint is enough.

stdio vs. network transports

For the stdio transport (the alternative without a network), the client starts the server process itself as a child process and communicates via its standard input/output — this only works if client and server run on the same machine. Streamable HTTP becomes necessary whenever the server runs independently of the client (like the Obsidian plugin here, which starts as soon as Obsidian itself runs, regardless of whether a Claude session is currently active) or when client and server are meant to sit on different machines. A practical advantage of stdio: since the client starts and stops the process itself, nobody has to take care of lifecycle management (the server only runs as long as it’s needed) — with network transports such as Streamable HTTP, on the other hand, the server has to run and stay reachable on its own, regardless of whether a client is currently connected.

Session management and authentication

Since Streamable HTTP runs over normal HTTP requests, standard web mechanisms can be reused directly: sessions can be managed via a session ID (e.g. as a header), and authentication runs via common HTTP patterns such as a bearer token in the Authorization header — just like a classic REST API. This is a practical advantage over stdio, where by nature no “authentication” in the classic sense is needed (the client started the server itself and runs in the same security context), but which in turn has no built-in mechanism for it should it ever become necessary.

When which transport makes sense

As a rule of thumb: stdio for servers that are started purely locally and once per client instance (e.g. a file-system access tool), Streamable HTTP for servers that exist as a standalone, permanently running service and are potentially used by several clients at the same time or over time — like an Obsidian plugin here, which runs independently of the lifecycle of any individual Claude Code session.

See also: MCP (Model Context Protocol), Bearer token, HTTP