First things first, don’t panic. Nothing breaks on day zero (July 28th) with the new MCP release, although there is some real work to be done.
As we’ve covered extensively, the headline change is that MCP is going stateless, and session IDs are going away. If you’ve only ever run a server on your laptop, you can mostly ignore this. But if you build or operate MCP servers, the switch to the new protocol is real work.
The good news is that this migration isn’t a rebuild-your-life project. We recently migrated our own MCP implementation behind the scenes without too many sharp edges, and have some insights from being involved in writing the new specs. To help orient your mental model, I’ve put together this checklist, roughly in the order you’ll hit each step.
Step 1: Expect some weird traffic
Your server almost certainly speaks the old protocol today. As clients update, they’re going to start trying to speak the new protocol at you. The guidance now is that clients assume a server speaks the new protocol until they get an error and fall back to the old one. So you’ll see connection attempts in the new format arriving at a server that doesn’t understand them yet.
Most of the time, clients will negotiate down gracefully and everything keeps working. But depending on how you built your server, that early traffic could show up as errors, or as harmless noise, or as a flood of log messages. In the worst case, it could blow something up.
So the day-zero task is to make sure your server handles unexpected traffic gracefully, and put a mitigation in place if you’re worried about log noise going crazy. You don’t have to support the new protocol yet. You just have to respond gracefully.
Step 2: Decide whether you’ll augment or rewrite
Once you’re ready to actually support the new protocol, you’ll face an architecture decision.
You can augment your existing server so it speaks both the old and new protocols, or you can build two separate implementations and run them side by side. The second option is sometimes cleaner, but there’s no universal right answer. It depends heavily on how you built your server in the first place.
Either way, you’re keeping the old code path around for a while. More on that at the end.
One potentially happy note though: the folks operating some of the largest servers in the world have told us this process ended up deleting more code than it added. The new protocol is simpler. That’s always a good thing. But in the short term, you’re supporting both, and that’s the part that takes work.
Step 3: Check for deprecated and changed features
Before you start rewriting, take inventory of what your server actually uses, because a few things are moving.
Three features are slated for deprecation — roots, sampling, and logging — because frankly, hardly anyone uses them. If you’re one of the few whose server does, you’re not stuck. There are recommended alternatives, but you need a plan to get off them, because clients will eventually stop supporting them entirely.
Then there’s the flip side: features that aren’t going away but are changing. Elicitation is the big one. It still exists, but the mechanics are different. It used to be that a server could send an elicitation request at any time, for any reason. Now it can only happen in response to a client request, and there are constraints on when you can send one. Many people aren’t using elicitation yet, so this won’t hit every server, but if you are, check how the rules changed.
Step 4: Implement the new protocol
Now the core work. If you built on top of one of the official MCP SDKs, this step can be close to free. There’s a new major release available, you upgrade, and you get most of the new protocol mechanics for free.
The wrinkle is the session ID. It’s going away, and if any part of your architecture depended on it, you’ll need another way to get what you need about the client’s session. A common example is analytics: servers often leaned on the session ID to figure out which clients were calling them, because the client announced itself once at the start of the session and you had to remember it from then on. Now the client tells you who it is on every request, the same way a browser sends a user-agent header.
That’s actually simpler, but if the old behavior was wired into your metrics pipeline or routing logic, you’ll need to update that logic.
Step 5: Verify with the conformance suite
Don’t guess whether you got it right. Prove it!
The MCP project publishes an open-source conformance suite for exactly this. You download it, point it at your server, and it runs a battery of tests that tell you where you’re not sending the right response. It’s a deterministic, programmatic way to know you’re actually speaking the protocol correctly.
If you’re on an official MCP SDK, you’ll likely be green already, since the SDKs are tested against the suite. If you’re running another open-source implementation or something homegrown, this step is not optional.
Step 6: Plan for the dual-stack era
One thing that spans the whole migration is to plan for a period where you have to speak both protocols at once.
The client side of the ecosystem takes time to catch up. New versions ship, but not everyone auto-updates, and some people will be running an old version of Claude or another client for a while. Nobody knows exactly how long this lasts, but there will be a stretch where, if you don’t want to cut older clients off immediately, you’re running dual-stack.
If you’re an enterprise that controls what’s on every machine, maybe you just force the upgrade and skip this. But if you operate an internet-facing service open to the public, you’ll speak both for a while, watch the old-protocol traffic taper off, and eventually make a clean decision to cut it off. Plan for that window rather than getting surprised by it.
Step 7: Clean up
This is the fun part. Once you’re speaking the new protocol correctly, go back and delete what you no longer need.
You don’t need Redis sitting around just to store session IDs. You can drop a lot of session-management and tracking code. This is where that “deleted more than we added” comment comes from, and it’s a genuinely satisfying pass. After this, there’s no special long-term maintenance burden. The migration ends. What’s left is just the ordinary upkeep you’d have had anyway.
Where Arcade.dev fits in
There are of course plenty of details within those steps, but I feel confident that if you broadly follow this seven-step checklist, you’ll be able to switch over to the new spec with minimal pain and maximum gain.
I’d also be remiss if I didn’t point out that this is exactly why we’ve built Arcade.dev the way we have.
Arcade sits between your clients and your servers, and we’ve already implemented both the old protocol and the new stateless one. A client that hasn’t upgraded connects through us and still works. An upgraded client shows up, and we speak the new protocol to it regardless of whether your servers have migrated yet. The messy middle of this transition gets handled in one place you control, instead of across every server-client pair you run.
And the controls you can’t afford to fragment, like authorization, security policy, governance, don’t live in the protocol at all with Arcade. They run in the runtime, on every action, no matter which protocol version a client speaks. The transport churns underneath; your important controls hold steady.
The migration has a clear end. Until you get there, you shouldn’t have to babysit a compatibility matrix at 2 a.m. That’s the job we signed up for.
From explainers to step-by-step instructions, Arcade is your guide to the largest revision to the MCP spec since launch. Click here for all of our coverage.
