Transports: stdio and Streamable HTTP

Local pipes or remote HTTP

MCP defines how messages travel. With stdio the host launches the server as a child process and exchanges newline-delimited JSON messages over standard input and output (log to stderr, never stdout, or you corrupt the stream). It is simple and local: the server runs with the user's permissions on their machine. Streamable HTTP uses HTTP so servers can run remotely, serve many clients, and stream responses (using Server-Sent Events where needed). Remote servers must handle authentication, session management, rate limits and TLS; the specification recommends OAuth-based authorisation for protected remote servers. An older HTTP+SSE transport existed and has been superseded, so check which your SDK version supports.

stdio versus Streamable HTTP

A comparison to guide the choice.

                 stdio                               Streamable HTTP
where it runs    child process on the user's machine  remote service (or local HTTP)
clients          one (the parent host)                many
auth             inherits the OS user                  OAuth / tokens required for protected data
logging          stderr only (stdout = protocol)       normal server logs
scaling          none needed                           load balancers, sessions, rate limits
best for         local tools, dev, files               shared/team/SaaS tools

Quick check: Why must a stdio MCP server log to stderr?

• Logs are forbidden
• stderr is faster
• stdout carries the protocol messages and logs would corrupt it
• It encrypts the logs