Choosing a Transport

The choice is small and consequential. Get it right by walking through five questions in order:

Who installs the server? If the user installs it on their own machine (calculator, personal notes, local code search), stdio is right. If you are operating it as a service for many users, Streamable HTTP.
Does it need network reachability? If yes, Streamable HTTP. There is no "stdio-over-network" — that is just a poorly-named tunneling protocol.
Does it scale horizontally? If yes, Streamable HTTP, ideally stateless behind a load balancer. Stdio cannot share load across processes.
Does it have multi-tenant data? If yes, Streamable HTTP with explicit auth per request. Stdio has no auth concept beyond "the user installed it."
Does it survive a process restart? Stdio servers come back when the host relaunches them; Streamable HTTP servers come back when the operator restarts them. Match the failure mode you are willing to tolerate.

The honest summary: stdio for personal, Streamable HTTP for shared. The mistakes happen in the margin — a "personal" server that grows into a team service, an "internal" server exposed to enough people that it should have had auth from day one. When in doubt, write the server transport-agnostically (the SDK lets you) and pick the transport at deployment time.

Code

Same FastMCP server, two deployment shapes·python

# server.py — works under either transport
from mcp.server.fastmcp import FastMCP
app = FastMCP("my-server")
# ... define tools/resources/prompts ...

# stdio entrypoint
if __name__ == "__main__":
    app.run()  # speaks stdio by default

# HTTP entrypoint (uvicorn / similar):
# uvicorn server:app.streamable_http_app

Code

External links

Exercise

Progress

Comments 0