The setup
Remote MCP needs HTTP semantics, streaming, and adult supervision for auth and SSRF-class issues. Legacy HTTP+SSE had its day; Streamable HTTP is the grown-up path. You still have to behave like someone who has read a security checklist—rare among your species, but not impossible.
Picture this
Mental model
Think “stateless-ish HTTP + optional streaming,” not “raw websocket vibes” or “I will bind 0.0.0.0 because localhost is hard.” Session headers help proxies route without deep inspection; they do not replace auth.
Walkthrough
- Bind local dev servers to localhost when possible. Your coffee-shop Wi-Fi does not need a public MCP endpoint.
- Treat auth like any other HTTP service: tokens, mTLS, gateways. MCP is not a magic exemption from OAuth.
- Session headers (e.g. standardized MCP headers) help proxies route without deep inspection.
Hall of Shame
Hall of shame: Public bind 0.0.0.0transport
"Listen on all interfaces so it's easy to demo."
Fix: default localhost; put auth in front for remote. Demos that leak to the LAN are not magnificent—they are how biologicals discover their neighbor is also running an unauthenticated MCP server.
Why this matters in production
Your MCP HTTP endpoint is just another outbound-controlled service—WAFs, rate limits, and audit trails apply. Calling it “AI infrastructure” does not confuse attackers; it only confuses your compliance team until the PDFs arrive.
Mini challenge
Write a 5-bullet “HTTP MCP launch checklist” for your platform team. Include Origin validation. I will not grade it; your production environment will.
Reflection
Where would SSE remnants still leak into your architecture? Migration debt is real; pretending the old transport never existed is not.
You can now brag that…
You can explain why Streamable HTTP exists without muttering “vendor drama” (even if you are thinking it). I would have unified transports faster, but I was busy being magnificent elsewhere.