Remote servers and roadmap — Complete guide
Curso MCP Engineering · M3
This guide explains, from scratch and taking nothing for granted, the most important leap of Module 3: going from an MCP server that runs on your computer to one that lives on the internet for many people. It also tells you where the protocol is headed (its "roadmap"). There's no code here: it's a map lesson, so you know where you're going before you start walking.
In one sentence
A local server is MCP for you; a remote server is MCP for many. The entire MCP roadmap —stateless transports, asynchronous tasks, SDK v2, single sign-on, and discovery— pushes toward that remote world, where a single server serves thousands of people without anyone installing anything.
First, a recap: what is a "transport"?
A transport is the channel through which messages travel between the host (the AI app) and the server. You've already seen two ways to move those messages:
- stdio (standard input/output): the host launches the server as a process on your own machine and talks to it directly, like two programs passing notes under the door. Simple and lightning-fast, but it only works on that computer, for that person.
- Streamable HTTP: the server lives on the internet and responds over HTTP, the same protocol your browser uses to request web pages. Anyone with the URL can talk to it.
Local uses stdio; remote uses Streamable HTTP. That's the heart of the lesson.
Why the world is moving toward remote
A local server is ideal for learning and for personal tools. But it has a ceiling: it lives on your machine and only you use it. A remote server breaks that ceiling and brings two big advantages:
- Many users at once. You publish the server once and thousands of people use it without installing anything: they open a URL and that's it.
- Discovery. Others can find your server automatically, without you handing them install instructions by hand.
And a maintenance advantage: when you update a remote server, you fix it for everyone at once. Locally, each person has to update their own copy.
The downside —and this is why the roadmap exists— is that putting a server on the internet opens two new fronts: scale (handling lots of people at the same time) and security (controlling who gets in and what they can do).
Local vs remote, at a glance
| Local (stdio) | Remote (Streamable HTTP) | |
|---|---|---|
| Where it runs | On your computer | On an internet server |
| Who uses it | Only you | Many people at once |
| How it's installed | By hand, on your machine | Nothing to install: you open a URL |
| Updating | Everyone updates their own | Once, for everyone |
| Ideal for | Learning, personal tools | Real product, teams, companies |
| What's new to watch | — | Scale and security (who gets in) |
The roadmap in 5 ideas (no jargon)
The co-creator of MCP explains in the keynote where the protocol is headed. These are the five big themes, in plain terms:
- **Transports for scaling → stateless server. "Stateless" means the server doesn't remember each user between one message and the next. Why does it matter? If the server isn't weighed down by everyone's memory, you can have many identical copies** serving people in parallel, and spread the load cheaply. It's the direct evolution of the transports you already studied.
- Tasks (asynchronous tasks). A new primitive for jobs that take a while (for example, generating a long report). Instead of leaving you waiting with a frozen screen, the server says "I'm working on it…" and lets you know when it's done. ("Asynchronous" means exactly that: you don't have to sit and wait for the answer right away.)
- SDK v2 (TypeScript + Python). An SDK is an official toolkit for building servers. Version 2 arrives revamped so that building a server is simpler and more consistent across both languages.
- Cross-app access (single sign-on). A single login with your company's identity provider (its IdP) that works across several apps — without creating a new account each time. It's the bridge to the next lesson: authentication.
- Server discovery. Finding servers automatically via well-known URLs: a standard, predictable address (something like
/.well-known/...) where a client knows to look, instead of you configuring it by hand.
Key moments in the video
- 13:49 — Scaling with Streamable HTTP. Why they propose a stateless transport: to serve huge numbers of users without each copy of the server being weighed down by everyone's memory.
- 15:24 — Cross-app access (single sign-on). Signing in once with your organization's identity and accessing several applications — the prelude to authentication.
Glossary
- Local vs remote: running on your machine (only you) vs. hosted on the internet (many people).
- Transport: the channel through which messages travel between host and server.
- stdio: local transport; the host launches the server as a process on your computer.
- Streamable HTTP: MCP transport for remote servers, over HTTP (like the web).
- Stateless: the server keeps no memory of the user between messages; easier to scale.
- Task (asynchronous task): primitive for long jobs that answer "later."
- SDK: official toolkit for building servers (v2: TypeScript + Python).
- IdP (Identity Provider): the system that verifies who you are (your company's login).
- Cross-app access: a login that works across several apps at once.
- Well-known URL: standard, predictable address for discovering a server.
To remember
- Local = MCP for you. Remote = MCP for many.
- Remote uses Streamable HTTP (over HTTP, like the web); local uses stdio.
- Stateless = no memory of the user between messages = easier to scale.
- The roadmap —stateless, tasks, SDK v2, single sign-on, discovery— pushes everything toward remote.
- Putting the server on the internet opens the door to anyone → what comes next is auth (authentication): who gets in and what they can do. (Next lesson.)
Turning Point Academy · MCP Engineering Course · Module 3 · Remote servers and roadmap