The same server runs on your laptop or in the cloud — the difference is the transport. Compare stdio and streamable HTTP, and know when each is the right choice.
Why: transport decides where your server can run and who can reach it — stdio is a local subprocess the host spawns (private, fast, single user), HTTP is a network service (remote, multi-client, needs auth). When: use stdio for local/personal tools and dev; use HTTP to share a server across users or machines. Where: your handlers do not change — only the run configuration does.
stdio streamable HTTP
------------------------ ------------------------------
host spawns a subprocess server runs as a web service
stdin / stdout pipe HTTP endpoint (+ SSE streaming)
local, single user remote, many clients
no network / no auth needed needs auth + network hardening
Same tools/resources/prompts. Different transport.Why: switching to a network transport is a one-line change in FastMCP, which is what lets you deploy a server so multiple users or apps share it. When: use HTTP when the server must live somewhere central rather than on each user’s machine. Where: now it is a real web service — everything you know about ports, TLS, and deployment applies.
# The SAME server object — only the run() transport changes.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
# ... your @mcp.tool / @mcp.resource / @mcp.prompt definitions ...
if __name__ == "__main__":
mcp.run(transport="streamable-http") # now reachable over the networkWhy: the moment a server is on the network it is attackable — a tool that writes data or spends money must sit behind authentication and least-privilege access. When: add auth (OAuth or API keys), validate every input, and scope each tool to only what it needs before exposing anything remotely. Where: never ship secrets in resource URIs or tool descriptions, and rate-limit side-effecting tools.
Remote server checklist:
[ ] Authenticate clients (OAuth / API key) — no anonymous access
[ ] Least privilege — each tool touches only what it must
[ ] Validate every tool input (never trust the caller)
[ ] No secrets in URIs, descriptions, or error text
[ ] Rate-limit and log side-effecting tools (writes, sends, deletes)
[ ] TLS in front (a reverse proxy is fine)