Remote servers and where the protocol is heading

Remote servers and where the protocol is headed

So far we've built local servers: programs that run on your own machine and that only you use. This lesson explains why the world is moving toward remote servers (hosted on the internet), and what the MCP team is preparing so that this works at scale. No code: it's a map lesson — so you know where you're headed.

What you'll learn

• The difference between a local and a remote server, in plain words.
• Why remote matters: many users at once and discovery (letting others find your server without installing it by hand).
• The big themes of the roadmap that the co-creator covers in the video.
• How this connects with what you've already seen (transports) and what's coming (auth).

From local to remote, explained

A local server uses the stdio transport: the host launches it as a process on your computer and talks to it through "standard input and output." It's perfect for learning and for personal tools, but it has a limit: it only works on that machine, for that person.

A remote server lives on an internet server and responds over HTTP — the same protocol as web pages. In MCP that transport is called Streamable HTTP. Huge advantage: thousands of people can use the same server without installing anything, and you can update it for everyone at once. The downside: now you have to think about scale (handling lots of people) and security (who gets in and what they can do). That's what the roadmap is about.

The roadmap themes, without jargon

• Better transports for scaling. The proposal is for the server to be stateless: it shouldn't have to "remember" each user between one message and the next. That way it's cheaper to have many copies of the server serving lots of people in parallel.
• Asynchronous tasks (tasks). A new primitive for jobs that take a while (for example, a long report): the server says "I'm working on it" and lets you know when it's done, instead of leaving you waiting.
• SDK v2 (TypeScript + Python). Revamped official toolkits so that building servers is simpler and more consistent across both languages.
• Cross-app access. A single login with your company's identity provider (its "IdP") that works for several apps — without creating a new account each time.
• Server discovery. Finding servers automatically via well-known URLs (a standard, predictable address), instead of configuring them by hand.

Key moments in the video

• 13
  — Scaling with Streamable HTTP. Why they propose a stateless transport: to serve a huge number of users without each copy of the server carrying everyone's memory. It's the direct evolution of the transports you already studied.
• 15
  — Cross-app access (single login). The idea of signing in once with your organization's identity and accessing several applications — the bridge to the next lesson on authentication.

Quick glossary

• Local vs remote: running on your machine (just you) vs hosted on the internet (lots of people).
• Streamable HTTP: MCP's transport for remote servers, over HTTP.
• Stateless: the server keeps no memory of the user between messages; easier to scale.
• Task (async task): a primitive for long jobs that respond "later."
• SDK: the official toolkit for building servers (v2: TS + Python).
• IdP (Identity Provider): the system that verifies who you are (your company's login).
• Cross-app access: a login that works for several apps at once.
• Well-known URL: a standard, predictable address for discovering a server.

To download

• 📄 Cheat sheet — Remote servers and roadmap (1-page PDF: local vs remote and the roadmap themes at a glance).

Before moving on

If you keep one idea: remote is MCP for the many, and the whole roadmap — stateless transports, tasks, SDK v2, single login, discovery — pushes toward that. And since putting your server on the internet opens the door to anyone, the next thing you need is to control who gets in: that's authentication, the next lesson.