MCP Fundamentals
MCP stdio vs SSE vs HTTP: Choose by Process Boundary
By MCP Beast·
Choose stdio when the client should launch and communicate with a server process through standard streams. Choose Streamable HTTP when the server should operate behind an HTTP endpoint supported by the intended clients. Treat legacy HTTP+SSE as a compatibility requirement to identify, not as another name for current Streamable HTTP.
The first useful question is where the server process and its data must live. The second is which transport and protocol revision the actual host supports. Streaming terminology comes after those decisions. A network endpoint does not automatically make a workflow more secure, and a local subprocess does not automatically confine the code it runs.
Resolve what “SSE” means in the conversation
The 2024-11-05 transport specification defines an HTTP+SSE arrangement with an SSE connection and a separate POST destination communicated to the client. That is an older protocol design.
The current transport overview identifies stdio and Streamable HTTP as standard bindings. Streamable HTTP can itself return SSE responses. Therefore, “the server uses SSE” does not tell you whether it expects the old transport or streams responses within the newer one.
Ask for the supported protocol revision and endpoint behavior. Keep that answer in the deployment record rather than translating every remote integration into a generic “SSE server” label.
| Option | Process relationship | Operational fit | Main compatibility question |
|---|---|---|---|
| stdio | Client launches a subprocess and owns its streams | Work tied to the client's execution environment | Can this host launch the required command safely? |
| Legacy HTTP+SSE | Independently running server with older event/post arrangement | Existing clients requiring the older binding | Which historical revision and endpoints are supported? |
| Streamable HTTP | Independently running server behind an HTTP endpoint | Shared or separately managed services | Which revision, headers and response forms does the client implement? |
The table describes common operating choices, not universal performance rankings. A benchmark on one machine does not establish which transport will be fastest or least expensive for a different workflow.
Start with the data and execution location
Consider a fictional code-review assistant that needs to inspect a developer's uncommitted working files. If the server must read those files directly from the developer's environment, a client-launched process may fit the requirement. Review exactly which files the process can access and under which operating-system account it runs.
Now consider a report service used by several independent automation workers. If the service reads a centrally managed data source and needs its own deployment lifecycle, an HTTP endpoint may fit better. It still needs explicit identity, network exposure, authorization and operational ownership.
A remote worker that launches a subprocess is still using stdio between that worker and child process. Conversely, an HTTP server can run on the same machine as its client. “Local versus remote” and “stdio versus HTTP” are related design considerations, not interchangeable labels.
Before choosing, draw the path in plain terms: host, client, server process, downstream system. Mark who launches each process and where each credential becomes available. Use the credential-boundary guide to inspect that path without copying secrets into client configuration or documentation.
Understand the stdio operating contract
The 2026-07-28 stdio binding carries newline-delimited JSON-RPC through the child's input and output streams. Standard output must contain valid protocol messages; diagnostics can use standard error. A stderr message is not automatically an error condition, and hosts may handle that stream differently.
This makes launch behavior part of the integration. Record the executable, argument boundaries, working directory and required environment-variable names. Use the host's documented configuration format; there is no universal client config file guaranteed to work everywhere.
For an evaluation, launch from the actual host rather than relying only on an interactive shell. A command can succeed in a terminal because that shell supplied a search path, working directory or environment value that the host does not provide. Resolve the discrepancy explicitly instead of teaching users to restart until it works.
Also inspect dependencies that print startup banners or install packages during launch. If ordinary text reaches stdout before the first protocol message, the client may fail to parse the stream. Pin and prepare the intended runtime through your normal deployment process so launching a tool does not unexpectedly become a package-management operation.
Understand the HTTP operating contract
For current Streamable HTTP, verify the complete network route: client, proxy or gateway, server and downstream dependency. Check request metadata forwarding, accepted content types, authentication and response streaming. The Streamable HTTP walkthrough provides a versioned example and response-diagnosis matrix.
HTTP introduces boundaries that stdio does not have in the same form: DNS, TLS, endpoint routing, intermediaries and network timeouts. It can also separate service updates from a client's local runtime. Decide who owns those boundaries before using a shared endpoint as an operational shortcut.
For the fictional report service, a useful acceptance exercise is a synthetic read under the intended identity through the real gateway path. Repeat with a denied identity and an unavailable downstream dependency. Record whether the failure is understandable to both the user and the operator. A publicly reachable health page does not prove those cases work.
Do not assume a browser address bar is a valid protocol test. Opening a URL with GET is different from sending the MCP request expected by the endpoint. Likewise, an HTTP 200 page can be a login screen or a generic application response rather than an MCP result.
Treat adapters as another boundary to test
A bridge can expose a subprocess through HTTP or connect a host to a service it does not natively support. That can solve a placement problem, but it adds responsibilities: process ownership, identity mapping, capability propagation, response handling and cancellation.
For a shared bridge, determine whether callers receive separate downstream identities or share one. Ask what happens when the subprocess exits during a call and how callers distinguish an interrupted result from a completed operation. If the bridge changes protocol revisions, test the interactions your workload requires rather than assuming basic forwarding proves full compatibility.
The gateway, proxy and router guide helps separate these roles. Select an adapter because its verified behavior meets the workflow, not because its name includes “gateway” or “proxy.”
Make a decision you can revisit
Complete this transport decision record for one host/server pair. The two columns are fictional constraint examples, not verified product configurations or a ranking. Replace the release/revision and evidence blanks with facts from your own intended path before accepting the choice.
| Decision field | Uncommitted working-files example | Shared-report example |
|---|---|---|
| Required data location | Developer's working tree; uncommitted content must remain in that environment | Centrally managed report data accessed by independent automation workers |
| Host and release | Desktop host: ___; release: ___ | Automation host: ___; release: ___ |
| Supported protocol revision | Verified host/server revision: ___ | Verified host/server revision: ___ |
| Process launcher / hosting owner | Desktop client launches the child; endpoint owner maintains its runtime | Service platform launches the report server independently of workers |
| Credential owner | Endpoint owner controls process access; any downstream credential has a separately named owner: ___ | Service owner controls server credentials; worker identity owner controls endpoint access |
| Proposed transport | stdio, subject to actual host support and file-access checks | Streamable HTTP, subject to actual host/revision and route checks |
| Rejected alternative and concrete reason | Proposed remote endpoint cannot read the required uncommitted files without an unapproved transfer | Per-worker child servers would duplicate a service lifecycle that this team requires to be centrally operated |
| First success / failure evidence | Authorized fixture read: ___; denied file-access case: ___ | Authorized synthetic report: ___; denied identity or unavailable dependency: ___ |
| Reconsideration trigger | Required data moves to an approved shared source, or the host loses safe process-launch support | Service no longer needs a shared lifecycle, or intended hosts cannot support the approved HTTP path |
These choices follow the stated constraints. They do not imply that stdio is inherently safer or HTTP universally faster. Record a different choice if your observed host support, data boundary or ownership requirements differ.
Then validate one normal operation and one failure through the intended path. If the operation can change external state, determine how an interrupted result will be reconciled before enabling automatic retries. Transport cancellation is not a guarantee that a downstream write was undone.
Keep these facts in the MCP server inventory. Revisit the decision when the execution location, client support or access boundary changes. A transport choice does not need recurring ceremony when the underlying requirement has remained stable.
Frequently Asked Questions
Is SSE the same as Streamable HTTP?
No. Legacy HTTP+SSE is an older transport arrangement. Streamable HTTP can use SSE for responses, so the presence of an event stream alone does not identify the protocol revision or endpoint behavior.
Does stdio mean the server runs on my laptop?
Not necessarily. It means the client launches a subprocess and communicates through its streams. That client can run on a workstation, a remote worker or another managed environment.
Is HTTP always better for production MCP servers?
No. Choose according to execution location, client support, identity boundaries and operational ownership. A managed local workflow and a shared network service can have different valid requirements.
Can a bridge convert stdio to HTTP?
An adapter can connect those boundaries, but its identity mapping, process lifecycle, capabilities, cancellation and failure behavior need verification for the intended workload.
Write down where one server must execute and which host must call it. Verify that pair before choosing an adapter or changing the deployment architecture.