The MCP Deprecation Clock Starts July 28th. Here's Your 12-Month Migration Checklist

In five days, on July 28th, the largest revision of the Model Context Protocol since it launched becomes the official specification. The same day, a 12-month deprecation clock starts ticking on the older protocol versions your MCP servers are speaking right now.

If your company is one of the 78% of enterprise AI teams running MCP-backed agents in production, that clock is now your clock.

This is not a drill, and it's also not a catastrophe. It's something much more useful: a deadline. And deadlines are the only thing that ever gets demo-era infrastructure cleaned up.

Nobody hardens a system because they should. They harden it because something forces them to touch it.

What actually changes on July 28th

The short version: MCP grew up.

The spec revision is the biggest since Anthropic open-sourced the protocol, and it lands on an ecosystem that has exploded past 10,000 servers with roughly 97 million SDK downloads a month. The release candidate has been baking for ten weeks precisely so SDK maintainers and client vendors could validate it against real workloads.

And alongside it, the piece that matters most for anyone running this in a real company: the Enterprise-Managed Authorization extension was promoted to stable. That's the extension that routes MCP server access through your organization's identity provider - and it already has support from Anthropic across Claude, Claude Code and Cowork, from Visual Studio Code, and server-side from Asana, Atlassian, Canva, Figma, Linear and Supabase.

Read that adopter list again. When the protocol itself, the biggest AI vendor, and half the SaaS industry agree that "who is calling?" should be answered by your IdP, the shared API key sitting in your team's config files officially became technical debt.

The checklist

Here's what to actually do with your 12 months. Most of it is one honest afternoon of inventory followed by decisions you were postponing anyway.

1. Inventory every MCP server you're running. Not the ones you think you're running - the ones that exist. Demo-era MCP has a habit of multiplying: a hackathon server here, a proof-of-concept there, each one quietly wired to something real. You cannot migrate what you haven't listed.

2. Record the protocol version each one speaks. The deprecation clock applies per protocol version. Anything on an older version has a hard ceiling of July 2027. Your SDK vendors will ship updates; your job is knowing which servers need them.

3. Kill the shared secrets. This is the big one. If your agents authenticate with a long-lived bearer token pasted into a JSON file, you have a password that never rotates, is shared by everyone who copied the config, belongs to no actual user, and is invisible to your identity systems. The EMA extension going stable means the replacement is now a standard, not a science project. Every MCP session should belong to a real, named user with a token that expires.

4. Scope the tool catalogs. Ask the uncomfortable question: does every agent connecting to your server see every tool the server has? Read the database and drop the database, same catalog, same caller? Every serious treatment of MCP security this year lands in the same place - the tool list an agent receives must be filtered by what that agent's user is allowed to do. An agent can't be talked into calling a tool it cannot enumerate.

5. Move enforcement server-side. If any security decision in your MCP stack lives in a system prompt - "please only use tools responsibly" - it is not a security decision. It's a suggestion. Prompt injection through tool results is the standard attack on agents, not the exotic one. The authorization check has to run at the endpoint, on every call, regardless of what the model believes it's doing.

6. Re-audit before the clock runs out. Migration without verification is how demo-era problems survive migrations. When you're done, you should be able to answer one question, per user, precisely: what exactly can this agent do, and who said so?

Steps 1 and 2 are the migration. Steps 3 through 6 are the reason the migration is a gift.

The part where I get to be a little smug

Here's what that checklist looks like on Magic Cloud: it's already done. Not because we predicted the spec calendar, but because we refused to build MCP security as a separate thing in the first place.

In Magic, every MCP tool is an HTTP endpoint with its own authorization requirement. The access token is a real JWT tied to a real user with real roles - the same authentication that protects the API protects the MCP surface, because they are the same surface. When an agent connects, the tool list it receives is the list of endpoints its user's roles permit, and nothing else. When it invokes a tool, the role check runs server-side, before any logic, on every single call. And underneath it all, generated code executes inside a whitelisted runtime that physically cannot reach beyond what it was granted.

There is no "MCP security model" to configure, drift, or forget during a migration. If a user can't call an endpoint over HTTP, their agent can't call it over MCP. One contract, enforced once, in one place.

So when the spec moves, we update one protocol layer - and your auth model, your role definitions, and your tool scoping don't move at all, because they were never bolted to the protocol in the first place.

The honest version

I won't pretend July 28th is doomsday. Nothing breaks that morning; the 12 months exist precisely so nothing has to break. Your current servers will keep working while you migrate, and if your MCP surface is three read-only tools over a reporting database, your "migration" is an afternoon and a coffee.

But the teams that treat this as only a protocol-version bump are wasting the single best excuse they'll ever get. You have to touch every MCP server you own within a year anyway. Touching it without fixing the shared keys and the wide-open tool catalogs means doing the work twice - and the second time will be scheduled by an incident, not a calendar.

Being in the 78% stopped being a differentiator the day it became 78%. Being in the minority that can answer "what can this agent do, and who said so?" - that's the differentiator now.

Get started with Magic Cloud, or talk to us if you'd rather we walk through your MCP inventory with you.