Once you decide to turn a capability into an MCP server, the first question to settle isn’t “which tools do I expose” but “which transport do I use.” That choice decides where your service runs, who can reach it, and whether you have to handle authentication.
I walked through this when choosing a transport for Langhuan. Here is the reasoning, and a conclusion on when each transport fits.
Three transports
stdio
stdio starts the server as a subprocess of the client and communicates over standard input and output. It’s the original MCP transport and the simplest: no port, no DNS, no certificates. The client spawns it and it just works.
The cost is that it only works locally. Server and client live in the same process tree, so remote clients can’t reach it, and there’s no cross-process identity boundary: whoever can start it locally is trusted.
Best for: local development, single-machine tools, and local extensions for desktop clients like Claude Desktop or Cursor.
HTTP with SSE
This is the early HTTP transport: the client POSTs a request and the server pushes streaming results back over SSE (Server-Sent Events). It was the first way to run MCP on a server and let remote clients reach it.
But it uses two endpoints with two sets of semantics, which makes it fiddly to implement, and the specification now marks it as a legacy transport. I wouldn’t start a new project with it.
streamable HTTP
This is the currently recommended HTTP transport, the one that supersedes SSE in the MCP specification. It unifies everything onto a single /mcp endpoint: POST a JSON request, and the response is either plain JSON or an SSE stream, negotiated by request headers. Because it’s standard HTTP, auth can ride on the Authorization header.
Best for: a shared service deployed on a server, multiple clients, and anything that needs network isolation or authentication.
How to choose
My judgment comes down to three rules:
- Only using it locally for one desktop client: use stdio, it’s the least work.
- Running it on a server to share with multiple clients: use streamable HTTP.
- Don’t start a new project with SSE; it’s legacy.
Think about the security boundary too. stdio’s trust boundary is “the local process”; HTTP’s is “the network plus authentication.” The first barely needs managing; the second has to be taken seriously.
Why Langhuan uses MCP over HTTP
Langhuan is a knowledge service deployed on a server, not a local plugin for one desktop client. It has to serve several agents and clients at once, so it must use HTTP rather than stdio.
Concretely, Langhuan serves MCP over HTTP at /mcp, using a Workspace API Key as a Bearer token. The full tool list is verifiable in the Langhuan repository.
If your MCP server will eventually be reached by a second client or another machine, start with streamable HTTP instead of building stdio and migrating later. Transport is a decision that’s cheap to make early and expensive to change late.