MCP stdio vs Streamable HTTP: setup and transport choices
Choose between MCP stdio and Streamable HTTP. Compare startup, hosting, authentication and troubleshooting, with the older SSE transport explained.
You have found a promising MCP server and need to decide how your client reaches it. Start with the interface documented by that specific server: an executable command for stdio or an endpoint for HTTP. Then verify that your client supports it. The decision changes who starts the process, where files live and which errors you investigate first. It does not automatically determine functionality, quality or the permissions granted to a connection.
stdio connects the client to a subprocess
With stdio, the client starts the server as a subprocess. Protocol messages use standard input and standard output; diagnostics can use stderr. Unrelated text on stdout interferes with protocol communication. Startup needs an available executable, its arguments and the correct environment. Record the runtime and full paths as well as the package identifier, so the same setup can be checked from the client rather than only from your terminal.
This route suits a process whose lifecycle is managed by your client. It may be a directly launched executable or a Docker container using stdio. Local describes the process arrangement; it does not promise that the server never calls external services. Also read what its tools do and which data sources they contact.
Streamable HTTP reaches an independent service
Streamable HTTP connects the client to an HTTP endpoint served by an independent process. Protocol revision 2025-11-25 describes HTTP requests and optional event streams. The earlier HTTP+SSE transport is a separate older mechanism. The presence of SSE in both contexts does not make their configurations interchangeable. Use the exact documented endpoint and check the protocol support of both sides.
An HTTP service can run on your own computer or remotely. Decide who is responsible for starting and operating it. A browser displays a response to its request; it does not perform a complete MCP initialization. Test the connection with the intended client. Authentication, session handling and network reachability belong to distinct checks. Record them separately so a network fix is not mistaken for proof of access to a particular resource.
Compare the practical setup differences
| Question | stdio | Streamable HTTP |
|---|---|---|
| What goes in the configuration? | Executable and arguments | Documented endpoint URL |
| Who starts the server? | Client starts a subprocess | Service operator |
| Where do you investigate first? | Environment, paths and process output | Endpoint, network and authentication |
| What demonstrates success? | Initialization and bounded operation | Initialization and bounded operation |
Open the client overview and check your configuration format. Select the same client in the configuration builder. Adopt a template only when its startup method matches the documented server version. Parsing JSON demonstrates its structure, not that an executable exists or that an endpoint is reachable. Keep configuration validation separate from the connection test.
To find candidates, use the registry categories for stdio and Streamable HTTP. Those categories depend on recorded declarations. Verify missing or older information against the original source. A registry entry is not a live connection test or a promise of current availability. When several entries look similar, compare their original repository and version before choosing one.
Move from a transport decision to an observed result
Record the client, server version and documented transport. Check the full path for HTTP, or the executable and arguments for stdio.
Prepare an uncritical resource and expected read result. Limit directories or account access to what this test requires.
Initialize the connection and inspect the tool inventory. A missing tool is a different finding from a process that failed to start.
Run the prepared operation and compare the result. Record what you observed and what remains unverified.
For failures, follow the connection troubleshooting guide. Changing transport should solve a defined requirement. If the cause is a wrong file path, a different HTTP URL does not repair it. Change one setting at a time and repeat the same test so you can identify which correction mattered. Keep the final working configuration alongside the recorded result for the next update.
- Does stdio mean offline?
- No. The transport between client and process does not determine which external services the server calls.
- Does HTTP always mean a cloud service?
- No. An HTTP endpoint can run on your computer or inside an internal network.
- Are SSE and Streamable HTTP the same?
- No. Streamable HTTP can use SSE for responses, but it is distinct from the older HTTP+SSE transport.
- Is one transport always better?
- No. Choose according to client support, the documented server interface and your operating requirements.
Official documentation checked on 1 October 2026. The test plans are editorial suggestions.
- MCP specification 2025-11-25: transports
Show retrieval command
curl -s https://modelcontextprotocol.io/specification/2025-11-25/basic/transports