MCP transports

MCP defines two transports. stdio runs the server as a child process and speaks newline-delimited JSON over its standard input and output. Streamable HTTP runs the server somewhere else and speaks JSON-RPC over a single POST endpoint. Connect is remote, so it offers Streamable HTTP only, at /mcp.

Status: Reference What this means
Audience: developer
Last verified: 2026-09-10
Product version: 6.3.2

Choosing between them#

The choice is made by where the server lives, not by preference. A server that reads files on your laptop has to run on your laptop, and stdio is the natural fit: no port, no certificate, no origin, and the operating system's process lifetime is the session lifetime. A server that reads something on the internet has no reason to be launched as a subprocess, and shipping a binary to every client to proxy an HTTP call would be work in exchange for nothing.

	stdio	Streamable HTTP
Where the server runs	As a child process of the client	Anywhere reachable by URL
Framing	Newline-delimited JSON on stdin/stdout	JSON-RPC in an HTTP request body
Lifetime	The process	Per request — nothing is held between them
Who can reach it	Only the parent process	Anyone who can reach the URL
Origin checks	Not applicable	Required when an `Origin` header is present
Distribution	Client must install or launch the server	Client needs the URL only
Used by Connect	No	Yes — `POST /mcp`

What revision 2026-07-28 removed from the HTTP transport#

Earlier revisions gave the HTTP transport two features that looked useful and cost more than they returned. Both are gone.

Protocol-level sessions: A server used to mint an Mcp-Session-Id during initialize and expect it back on every later request. That made an ostensibly stateless HTTP endpoint stateful, which is a problem the moment there is more than one server process behind a load balancer. The header is now ignored.
The standalone GET stream: A client used to open GET /mcp and hold it as a server-to-client event stream, resuming with Last-Event-ID after a drop. Streams are no longer resumable and the standalone stream is gone; Last-Event-ID is ignored.

In exchange, every POST now carries what the server needs to know about it: the protocol version and client info in params._meta, mirrored into the MCP-Protocol-Version, Mcp-Method and Mcp-Name headers. A middlebox can route on the headers without parsing the body, and the server refuses any request where the two disagree, with -32020.

The practical effect is that a Streamable HTTP endpoint is now an ordinary POST endpoint. It can sit behind any load balancer, scale to any number of processes, and be tested with a single curl command that needs no prior handshake.

Does Connect use both transports?#

No. Connect's MCP server is remote and speaks Streamable HTTP only, at POST /mcp. There is no stdio build, no downloadable binary and no package to install: a client needs the URL and nothing else.

GET /mcp and DELETE /mcp answer 405 with Allow: POST. That is a deliberate answer rather than a missing route — an older client that opens the standalone stream is told plainly instead of waiting on a connection that would never carry a message.

A local proxy that wraps the HTTP endpoint in stdio, as several client ecosystems provide, works fine. Connect neither ships nor endorses a particular one; from the server's point of view a proxy is just another HTTP client.

Failure modes you will actually hit#

Point a client at https://connectbyjbrh.com/mcp and call tools/list.
Result A JSON-RPC result with ten tool descriptors. If you get 405, your client issued a GET.
Send more than 120 requests in a minute from one address.
Result 429, with the limit named in the error message. Back off; the window is a rolling minute, not a fixed one.
Send a JSON array of messages.
Result 400. Batching is not accepted — send one JSON-RPC message per request.
Send a body larger than 256 KB.
Result 413, refused before parsing.

One asymmetry catches people out: a notification — a message with no id — gets 202 and an empty body, not a JSON-RPC result. A client that waits for a response to notifications/initialized waits forever.

Questions#

Is Streamable HTTP the same thing as SSE?

Not any more. An earlier revision layered server-sent events over a separate GET stream, and people came to call the whole transport 'SSE'. Revision 2026-07-28 removed the standalone stream, so Connect's endpoint is a plain POST that returns a JSON body. See Streamable HTTP for the transport in detail.

Can I run Connect's MCP server locally over stdio?

There is no stdio build to run. The documentation tools read a generated corpus that is published on the website, so a local copy would have nothing to read that the URL does not already give you. A generic stdio-to-HTTP proxy from your client's ecosystem is the supported way to bridge, if your client only speaks stdio.

Does the transport decide whether a tool needs authentication?

No. The transport carries messages; authorisation is a separate concern. Connect's public documentation tools need no credential because of what they read, not because of how they are reached.