What's an MCP, what just changed, and what do you actually need to do about it

The MCPs we take for granted today didn’t exist in any usable form three years ago. Most of it didn't exist eighteen months ago. And, on 28 July 2026, the protocol that unassumingly holds the whole thing together shipped what its own maintainers are calling the most important release since it launched.

If you build with AI tools, use an AI assistant that connects to your other software, or have ever hired someone who says "we'll wire that up over MCP," this is the piece that explains what you're actually running on top of.

What MCP actually is

The Model Context Protocol is the open standard that lets an AI assistant call out to your other tools and data instead of guessing at what it can't see. Anthropic introduced it in November 2024 to solve what they called the M×N problem: if you have M different AI models and N different tools or data sources, you end up needing to build M×N separate custom integrations, one for every model-tool pairing. MCP replaces that with a single protocol both sides speak, the same way a USB-C port lets any compliant device talk to any compliant cable without a custom adaptor for every combination.

In practice, this is why an AI assistant can be told "check my Notion database" or "pull the latest rows from my Supabase project" and just do it, rather than you copying and pasting data back and forth by hand. The AI is the client. Your tool, Notion or Slack or your own product's database, exposes an MCP server. The protocol in between is what lets them understand each other.

The growth number is the part that actually surprised me. As of this release, MCP's TypeScript and Python SDKs have each crossed one billion total downloads, and the protocol is seeing close to half a billion downloads a month across its core SDKs. Eighteen months ago this was a spec on GitHub. It is now the plumbing underneath a meaningful share of the agentic AI industry, and it's no longer maintained solely by Anthropic. Governance sits with the Agentic AI Foundation, a Linux Foundation project, which is itself a signal of how fast this went from "one company's clever idea" to "infrastructure too load-bearing for one company to own."

What changed on 28 July 2026

The headline change is that MCP just gave up being a stateful protocol. Previously, an MCP client and server did a handshake (a formal initialize/initialized exchange), got issued a session ID, and had to keep talking to the exact same server instance for the life of that session, the same way an old-fashioned web app pins you to one server because that's where your login session lives. The new spec retires the handshake and the session ID entirely. Every request now carries everything it needs inside itself, which means any request can land on any server instance behind a plain load balancer with no shared session storage required. If a server genuinely needs to remember something between calls, it now mints an explicit handle and hands it back to the client to pass along as an ordinary argument, rather than hiding that state inside the transport layer where nobody except the infrastructure can see it.

A few of the other changes matter more than they sound like they should:

Real-time, mid-conversation requests, the kind where a tool needs to ask you "are you sure you want to delete this" before it acts, used to require a permanently open, bidirectional connection. That's genuinely hard to run at scale. The new spec replaces it with something called Multi Round-Trip Requests: the server replies "I need more information," the client answers, and the original call resumes. Same functionality, no held-open pipe.

Tool and method names now travel in dedicated HTTP headers rather than buried inside a JSON body, so anyone running a gateway, a rate limiter, or a firewall in front of their MCP servers can now route and meter traffic without having to parse every request's contents first.

Lists of available tools and resources can now be cached, with an explicit time-to-live attached, instead of being re-fetched on every single connection.

Authorization got noticeably stricter. Servers now have to return an issuer identifier that clients are required to check before they'll accept an authorization code, which closes a specific class of hijack where a malicious server tricks a client into redeeming a token meant for someone else. The old, informal way of registering a new client application is being phased out in favour of a more rigorous, document-based standard, though the old method keeps working for now.

And three features, Roots, Sampling, and Logging, are formally deprecated. They still work. They'll keep working for at least twelve months, because the new spec comes with a mandatory minimum deprecation window written into it for the first time. But new tools shouldn't be built on them, and the older HTTP+SSE transport method is on the same year-long exit ramp.

The plainest way I can put the whole release: MCP has stopped behaving like a clever prototype that happens to work when one person is talking to one AI assistant, and started behaving like ordinary, boring, scalable web infrastructure. That is a genuine compliment. The boring things are the things that hold up.

What you actually need to do about it

If you're a non-technical founder who uses AI tools that happen to run on MCP under the hood, the honest answer is: nothing, today. Every major Tier 1 SDK (TypeScript, Python, Go, C#) already speaks the new spec, the tools you already use are the ones responsible for keeping pace with it, and you've got a twelve-month runway on anything that's being retired outright.

Where it does become your problem is narrower and specific. If someone built you a custom MCP integration, an in-house tool connector, a bespoke server wired to your product's own database, ask whoever built it whether it depends on session state, on Roots, Sampling, or Logging, or on the older SSE transport, because those are the exact pieces now on notice. If you're evaluating an AI vendor and their pitch involves "we integrate with your tools," the honest hardened authorization model in this release is a legitimate thing to ask them about; a vendor who can speak fluently about issuer validation and client metadata documents has actually kept up, and one who can't, hasn't. And if MCP integration is part of what you're selling, this release is worth reading properly rather than skimming, because "stateless, cacheable, enterprise-auth-hardened" is precisely the language procurement teams at bigger customers want to hear before they'll sign.

I went back to watching my tool list finish loading after I'd read the spec notes properly. It kept working exactly the way it had five minutes earlier, which is rather the point. The best infrastructure upgrades are the ones you'd never notice unless you went looking.