Remote MCP Servers: HTTP, Auth, and Deployment
Turn a local MCP server into a hosted one: Streamable HTTP, OAuth-based authorization, multi-user concerns, and deployment.
Your notes server works beautifully, on one laptop, for one person. The moment a teammate asks "can I use that too?", a local stdio server hits its limits. Each person has to install it, keep it updated, and hold their own credentials, and a web-based host like Claude on the web or ChatGPT can't launch a process on your machine at all.
A remote MCP server solves this: one deployment at a URL that any MCP host can connect to. In this lesson you'll turn the notes server into one. You'll serve it over Streamable HTTP, protect it with OAuth-based authorization as the MCP spec defines it, give every user their own private notes, and deploy it. Along the way you'll learn the security details that separate a remote server you can trust from one that leaks everyone's data to everyone else.
What changes when a server goes remote
Moving from stdio to HTTP changes who can reach your server, and that changes your responsibilities:
| Concern | Local stdio server | Remote server |
|---|---|---|
| Who can reach it | Only the host that launched it | Anyone who can reach the URL |
| Identity | Implicit: it's you | Must be proven on every request |
| Credentials | Environment variables on your machine | OAuth access tokens issued per user |
| Data | One user's data | Many users' data, which must never mix |
| Abuse | Not a concern | Rate limits, quotas, and monitoring |
| Operations | Runs when the host runs | Hosting, HTTPS, deploys, logs |
The good news is that the protocol has become friendlier to hosting. As you saw in What Is MCP and Why It Matters, the 2026-07-28 revision made MCP stateless: no handshake, no session IDs, every request self-contained. A stateless server can run as many identical copies behind a load balancer, with no "sticky" routing.