The Real Timeline
Before any of the technical stuff — the most important thing to understand is when this actually matters, and how much of it has already shipped versus how gradually real-world servers are actually picking it up.
Everything you've built in this entire course still runs, unchanged, today. Nothing you learned is wasted. What follows is a look at what already exists in the newer spec — not a correction of what you already know.
Here's the actual timeline:
The modern (2026-07-28) revision genuinely finalized and published on that date — that's now behind us, not ahead. What matters more than the date itself is how it shipped: every source confirms adoption is opt-in. Existing legacy implementations were not switched off or broken on that date, and there is no blanket forced-migration deadline — only a handful of specifically named features (covered a few pages from here) that carry their own twelve-month clock.
The spec is final. The SDKs support it. And your legacy-model servers keep running exactly as they do today, with nothing forcing you to change anything, unless you specifically choose to opt into the newer capabilities.
Even when nothing is forcing a change, rewriting a working system to use new capabilities is still real engineering work — new patterns to learn, new code paths to test, real production traffic to be careful with. That's exactly why large ecosystems move gradually even when there's no hard cutoff pushing them: teams migrate when it's genuinely worth their time, not on a countdown.
"You didn't learn something that got replaced. You learned the model that's still fully supported today, with no deadline forcing you off it."
The Big Shift, Simply
Every single change on the pages that follow comes from one idea. Understand this once, and the rest stops feeling like a list of random new rules.
Remember me
You shake hands once. After that, the server remembers who you are for the whole conversation.
Tell me every time
No handshake. Every single message carries everything about itself — who's asking, what version, what's needed.
Think of a co-working space. In one building, the same receptionist greets you every morning and just waves you through, because she remembers your face. In another building, everyone taps an ID badge at every single door — the entrance, the lift, the meeting room — because no one person is keeping track of who's who anymore. Slightly more tapping, but any door in the building can let you through, any day, whoever happens to be working that door.
Why bother? A system that has to "remember" a specific person can only really be handled by whoever met them first. A system that just reads your badge every time can be handled by any door — which means the building can open more entrances whenever it gets busy, without needing a specific person to remember every face.
"Remembering you is convenient — until the person who remembers you is busy, or has the day off."
Remembering You
This is the single change everything else in this artifact builds on. Toggle between the two to feel the difference.
You call customer support about an order. You get connected to one specific agent, and they remember everything as you talk. But if the call drops, that's it — you call back, get a completely different agent, and have to explain your whole issue again from scratch, because nothing you said was written down anywhere the new agent can see.
That's the old Mcp-Session-Id. Whichever server first "picked up the call" is the only one that remembers your context — which makes it hard to just add more servers behind the scenes to handle busier days.
Now picture submitting a support ticket instead — with your full order number and issue written in it. Any agent who opens that ticket can pick it up immediately and help you, because everything they need is right there in the ticket itself, not held in one person's memory of your earlier phone call.
That's the modern model. There's no session id at all — the full details travel with every single request, so any server can handle it, not just the one that "answered the call" first.
Yes, this means slightly more information travels with every request. But for most real systems, that small extra cost is worth it — being able to add more servers freely, without anyone needing to "remember" you, turns out to matter a lot more once things get busy.
Asking Mid-Task
If nothing is "remembered" anymore, how does a server ever ask you a question in the middle of doing something? This is the neat part.
You order a custom dish at a restaurant. While it's actually being cooked, the kitchen might reasonably send the waiter back to your table to ask "how spicy do you want it?" — because your order is already in progress. What the kitchen can't do is walk up to a random, empty table and start asking cooking questions before anyone there has ordered anything at all.
That's the whole rule, really: a server can only ask you something while it's already working on a request you sent it. It can never just show up out of nowhere.
| Rule | In plain words |
|---|---|
| The "already cooking" rule | A server can only ask a question while actively handling something you asked for |
| The "real question" rule | When it does ask, the reply always has to contain an actual question — never a vague, empty "something's needed" message |
"No surprise questions. If the server's asking you something, it's because you already asked it to do something first."
Confirming and Continuing
So the kitchen asks its question. You answer. But there's no session anymore to remember your order was ever placed — so how does it pick back up? Press play below.
You've placed an online order, and right before it finalizes, the app asks for an OTP sent to your phone. You weren't stuck on a call this whole time waiting — you just grab the code, come back, and enter it along with your order reference. The order completes, quite possibly handled by a completely different backend server than the one that first took it.
Because the "ticket" carries everything needed, whichever assistant asked the question is free to go do something else entirely while it waits for your answer — instead of just sitting there, stuck. Whoever's free when your answer comes back can pick it up.
"Nothing was ever really forgotten. It was just written down carefully enough that anyone could pick it back up."
Faster Routing
A small, practical addition — every request now carries two little labels that make life easier for anything managing traffic.
At a busy airport, staff don't stop and ask every traveler where they're headed — they glance at the colored tag on your boarding pass and wave you toward the right lane instantly. Economy, priority, connecting flights — all sorted by a quick glance at one small label, not a full conversation each time.
Every request now includes an Mcp-Method and Mcp-Name label, right in the headers. Anything managing traffic between you and a server — a load balancer, for instance — can glance at just those two labels and route the request instantly, without needing to open up and inspect the whole thing.
Smarter Caching
A server can now tell a client exactly how long to hold onto an answer before asking again — and whether that answer is safe to share.
A weather app doesn't re-download the whole world's forecast every time you open it — it keeps your city's forecast cached for maybe an hour, so opening the app feels instant. Once that hour's up, or the forecast genuinely changes, it quietly refreshes in the background.
The new fields are ttlMs (how long an answer stays fresh, in milliseconds) and cacheScope (whether that cached answer is safe to share across many people, or private to just you). Less unnecessary re-asking, faster responses.
Finding What Broke
When many small systems are working together, "something went wrong" isn't very useful on its own. This change is about actually knowing where.
Imagine a package that travels through three different companies to reach you — a local pickup service, a long-haul transport company, and a last-mile courier. If it goes missing, "it's lost" doesn't help much. But one tracking number that follows the package through all three companies lets you pinpoint exactly which handoff dropped it.
That's what this adds: a standard way (built on the existing W3C tracing standard) to carry context across every hop a request takes, so if something breaks three services deep, it's traceable back to exactly where.
Apps, Like a Console
This one's already real, not just a direction — a named, shipped extension of the spec. Worth understanding, because it explains a lot of the newer vocabulary you'll start seeing.
A game console on its own doesn't do much — almost everything you actually spend time on are the individual games built for it. MCP is now set up the same way: it's meant to be the console underneath, while most people actually interact with specific "games" built on top of it — a hotel-booking one, a database connector, whatever someone's built.
Extensions now get named like app publishers often do too — a reversed domain name (like com.yourcompany.tool) so two different people's extensions never clash by accident. And these "apps" can be genuinely interactive — showing you a real interface, like tapping through hotel options and confirming a booking, not just plain text back and forth.
Gone vs Going Away
Two words that sound similar but mean very different things — worth being precise about.
Not there at all, anymore
These simply don't exist in the modern spec: the old handshake, ping, logging/setLevel, the old session header.
Still works, on a clear timeline
Roots, Sampling, Logging, the old HTTP+SSE transport — these keep working until at least July 2027, by MCP's own published twelve-month policy, counted from when the deprecation was announced.
That twelve-month window is the spec's own minimum promise — it's not a guarantee every library honors down to the day. A specific SDK is free to drop a deprecated feature's code sooner if its maintainers choose to. That's exactly what happened with sampling in a recent FastMCP release, covered in detail a few pages from here — worth knowing the difference between "the spec says it'll work" and "the exact library version you've installed still has the code."
"Deprecated" isn't a countdown to breakage — it's MCP's own rule that anything marked this way gets a minimum of twelve months from its announcement before it's even eligible to be removed. That clock started in July 2026, so there's still real runway left from today. Plenty of time to plan, none of it urgent.
What You Should Actually Do
The honest, simple answer — no hedging.
Keep building on legacy
- It's what's actually running
- Everything from this course applies directly
- Adoption of the new model is opt-in, not forced
The shape of the modern spec
- Stateless, self-contained requests
- Questions answered by retrying, not by waiting
- A real, published deprecation policy for the few older pieces — nothing sudden
"You don't need to rebuild anything today. You just needed to know, clearly, what's already here — and now you do."
What Actually Broke
Everything up to here has been the spec's own story. This section is different — it's what actually happened when real client code from this course was run against the real, currently-installed library.
Nothing here means the earlier client lessons were wrong. It means the ground shifted slightly under a few specific features, in exactly the way this whole artifact has been warning you it might.
A walkie-talkie lets either side jump in and say something, any time, mid-conversation. Mailing a letter doesn't — you write everything down, send it, and wait for a reply; you can't interrupt a letter that's already in the post. The modern protocol is the letter, not the walkie-talkie: once a request is sent, there's no channel left for the server to jump back in and ask the client something mid-task, for anything at all.
A few client-side features from earlier in this course were built assuming the walkie-talkie was always available. Before looking at what happened to them, here's what each one actually is, in plain terms:
| Feature | What it actually is |
|---|---|
| Sampling | A way for a server to ask the client's own connected AI model to help it out — say, to turn some raw data into a natural-language summary — instead of the server needing its own separate AI subscription |
| Elicitation | A server pausing mid-task to ask the actual person a real question — for example, confirming an unusually large action before going ahead with it |
| Ping | The simplest possible check — one side asking the other "are you still there?", with no other information exchanged |
Once the installed library actually negotiates the modern, letter-only protocol by default, those specific features hit real, reproducible errors — not because the code was wrong, but because the channel they relied on genuinely isn't there anymore on that connection.
| Feature | What happens now |
|---|---|
Sampling (ctx.sample()) | The method itself no longer exists in the installed library |
Elicitation (ctx.elicit()) | Still exists, but raises an error on the modern connection |
Ping (client.ping()) | Still exists, but raises "Method not found" on the modern connection |
"The letter didn't break the mail system. It just doesn't leave room for a mid-sentence question — and a few lessons were quietly assuming it would."
Two Kinds of Fix
Not every broken feature needed the same fix — worth telling these two apart before touching any code.
Sampling
- The method was removed from the library's code entirely
- No setting or flag brings it back
- Fix: rewrite the tool to not need it
Elicitation & Ping
- The code still exists in the library
- It just needs the old-style connection to work
- Fix: ask for that connection explicitly
If Python itself complains the method doesn't exist at all (an AttributeError), that's Class A — nothing you pass in will bring it back. If the method exists but the server or client complains about the connection type at the moment you call it, that's Class B — usually fixable without touching your actual logic at all.
"One of these needed a rewrite. The other just needed to ask for the old counter by name."
Sampling: Look It Up Yourself
This is Class A — genuinely gone. Here's what sampling actually is, what changed, and why the fix is a genuinely good one, not just a workaround.
A tool running on a server sometimes needs an AI model's help mid-task — to turn some raw data into a natural-sounding summary, say. Sampling is the server asking the client's own connected AI model to do that piece of work, instead of the server needing its own separate AI access. Useful because a lightweight server doesn't need its own API key or model subscription — it can borrow whatever intelligence the client already has on hand.
Picture a translator who used to phone a specific passenger's own multilingual friend whenever a tricky word came up mid-conversation. Now, instead of making that call, the translator just checks their own dictionary directly. Slightly less personal, but it works every time, and doesn't depend on that one friend being reachable.
| Before | After | |
|---|---|---|
| Who answers | The connected client's own LLM | The server calls a provider (like Anthropic) directly |
| Where the API key lives | N/A — the client already had one | On the server process itself now |
| Does this match where MCP is heading? | — | Yes — this is the spec's own suggested migration path |
This isn't a downgrade. "Integrate directly with an LLM provider API" is the migration path the MCP spec itself recommends for sampling. The forced rewrite happens to point exactly where things were already heading.
"The server stopped phoning a friend for the answer, and started keeping its own dictionary instead."
The One Old Counter Still Open
This is Class B — elicitation and ping. Nothing about their logic changed. They just need to ask for the old-style connection by name.
Elicitation is a server pausing mid-task to ask the actual person using it a real question — for instance, confirming an unusually large action before going ahead with it, rather than silently guessing. Ping is far simpler: one side just asking the other "are you still there?", with nothing else exchanged, to confirm the connection is alive.
A store switches almost everyone over to self-checkout. It's faster, and it's the default now. But one staffed counter stays open, specifically for the handful of things self-checkout genuinely can't handle. You don't get sent there automatically — you have to walk up and ask for it.
Asking for that counter, in code, is one keyword:
| Before | After |
|---|---|
Client("main.py", elicitation_handler=...) | Client("main.py", elicitation_handler=..., mode="legacy") |
That one addition restores the classic handshake this whole course originally taught — the exact back-and-forth from the Lifecycle section — and with it, the back-channel that elicitation and ping both genuinely need. No change to the handler functions themselves, no change to the server's tools.
Elicitation does have a native replacement built for the modern, letter-only connection — but it asks a tool to be rewritten so it can pause and be called again later with the answer, which is a meaningfully bigger change than most lessons need. Asking for the old counter is the simpler, honest choice when a tool's shape genuinely doesn't need to change.
"Nothing about elicitation broke. It just moved behind a counter you now have to specifically ask for."
The Subprocess Doesn't Hear You
A completely separate bug from everything else in this section — easy to miss, and worth knowing about on its own.
When a client connects to a local server over stdio, it isn't reaching out to something already running elsewhere — it's actually starting that server itself, as a brand-new, separate program running alongside it. That freshly-started, separate program is what "subprocess" means here.
You mention something important out loud in your own room. Then you send your kid to run an errand in another room. Your kid doesn't automatically know what you just said — unless you specifically wrote it on a note and handed it to them on the way out.
When a client starts a local server as a subprocess (the stdio transport this whole course has used), that subprocess does not automatically inherit your full terminal environment. Only a small, safe list of variables comes along by default. Anything else you've set yourself — an API key, for instance — gets silently left behind, even though it's genuinely sitting right there in your own shell.
The fix: hand it over explicitly, on the way out, like the note in the analogy:
| Instead of assuming it's inherited | Pass it explicitly: env={"ANTHROPIC_API_KEY": "..."} to the transport that launches the server |
Never paste a real API key directly into a chat window, a ticket, or a commit — treat any key that's ever been typed somewhere like that as already compromised, and generate a fresh one. A key belongs in a local, untracked .env file or your shell's own environment — nowhere it could be copied, logged, or seen by anyone else.
"The room and the errand aren't the same room. Whatever your kid needs to know, you have to actually hand them."
The One-Line Mental Model
Everything in this section, compressed into one sentence worth remembering.
The modern protocol has no back-channel at all — a server can no longer interrupt a client mid-task, for anything. Features that depended on that either got removed outright (sampling — the server looks the answer up itself now) or still exist, just waiting behind an old counter you have to specifically ask for by name (mode="legacy").
Worth mentioning to anyone curious about the road not taken: all of this could have been sidestepped entirely by pinning the installed library back to an older version, where every original demo still runs completely unmodified. That path was deliberately not taken here — it would have moved this course further from where MCP is actually heading, and the real value for learners is in seeing exactly what that direction looks like in practice, errors included.
"You didn't just learn what changed. You watched it actually happen, against real code, and fixed it for real."