MCP 2026-07-28 Is Final: Nothing Breaks Today, Here’s What Changes

Verified as of 28 July 2026.

The Model Context Protocol shipped MCP 2026-07-28 today, its largest revision since launch. If you build MCP servers, your week is already planned and there are a dozen migration guides waiting for you. If you simply connect them — Gmail, Canva, Shopify, whatever sits in your Claude sidebar — here is the complete practical summary: nothing you use stops working today, and nothing you use stops working next month either. The maintainers said as much themselves before the release.

That could be the entire article. It isn’t, because “nothing breaks” answers the wrong question. The useful question is what this release makes possible over the next year, and that answer is considerably more interesting than the non-event of today.

What MCP 2026-07-28 actually is

MCP versions are dates, not numbers. The date marks the last day backwards-incompatible changes were made, which is why the version reads like a deadline. The version in force until today was 2025-11-25.

The maintainers put the growth in context: across the Tier 1 SDKs they are seeing close to half a billion downloads a month, with the TypeScript and Python SDKs each past a billion in total.

The release candidate was locked on 21 May and given a ten-week validation window so SDK maintainers and client developers could test it against real workloads. That window closes today. The revision bundles four things: a stateless protocol core, a formal Extensions framework, a package of authorization changes, and — for the first time in MCP’s history — a written deprecation policy.

Three of those four introduce breaking changes. None of those breaks reach you.

Why your connectors keep working

MCP clients and servers negotiate which version of the protocol they will speak. If one side doesn’t understand 2026-07-28, they settle on the older revision and carry on. The old version doesn’t get switched off; it gets outvoted, connector by connector, as vendors migrate at their own pace.

In practice this means there is nothing to reconnect, nothing to re-authorize, and no setting to change. Every connector in our MCP directory works this morning exactly as it worked yesterday.

One caveat worth keeping: if a connector does misbehave in the coming weeks, this release is a plausible cause and the fix belongs to the vendor, not to you. Resist the urge to delete and reinstall everything. Check the vendor’s status page or changelog first.

What actually changes, in the order you’ll notice it

1. Connectors that show you something instead of telling you

The headline for anyone who doesn’t write code is MCP Apps: connectors can render a real interface inside the conversation instead of returning a wall of text. MCP Apps did not arrive today — it already existed as an extension, alongside Enterprise-Managed Authorization. What today’s release does is formally lock the extensions framework into the specification itself, which is what turns a promising side project into something a vendor can safely build a product on.

We checked this against our own account rather than guessing. Six MCP connectors are live in our Claude today. Three of them already put an interface on screen: Canva shows an outline you approve before it generates anything, Supermetrics opens a picker with visual previews, and HyperFrames returns a video player and a progress indicator that updates itself.

An honest qualification: we cannot verify from the outside that these use the new extension rather than a vendor’s own solution to the same problem. That is precisely the point. Three companies each built their own answer to “how do I show the user a button.” The spec turns three answers into one.

One detail worth knowing before these interfaces start appearing everywhere: they are not a side door. The interface runs in a sandboxed frame, its template is declared in advance so the host can inspect it before anything executes, and every button you press inside it goes through the same permission and audit path as a normal tool call. A connector cannot use a pretty interface to do something it would not have been allowed to do in plain text.

What this means for you over the next months is a new quality signal. A connector that hands you a picker is a connector someone thought about. One that returns a paragraph asking you to type an ID is one that nobody did.

2. Slow jobs stop timing out

The Tasks extension gives long-running work a formal home: the server hands back a reference, the work continues in the background, and the client checks on it.

The same three connectors already behave this way, and we watched it happen while writing this. We asked Supermetrics for six days of ad data; it returned an opaque ID immediately and nothing else. The figures arrived on a second, separate request. HyperFrames does the same for video renders, and tells you how many seconds to wait before asking again.

Connector	Interface in chat	Background jobs
Canva	Yes	Yes
HyperFrames	Yes	Yes
Supermetrics	Yes	Yes
Airtable	No	No
Gmail	No	No
Windsor.ai	No	No

The split isn’t random. The three that need interfaces and background jobs are the ones that produce something — a design, a video, a report. The three that don’t are the ones that read and write records. If you’re wondering whether a connector you’re considering will benefit from this release, that’s the question to ask: does it make things, or does it move rows?

The practical gain is that heavy work becomes viable through a connector instead of dying at a timeout. We ran into exactly this ceiling testing a video connector last week.

3. More connectors, because running one gets cheaper

The stateless core is the change that dominates every technical write-up today, and it is the one you will never see. Sessions are gone. There is no handshake and no session identifier, so any request can be answered by any server instance behind an ordinary load balancer.

Translated: hosting a public MCP server stops requiring specialised infrastructure. That matters to you for one reason — the companies that haven’t shipped an official connector yet are often mid-sized firms without an infrastructure team. Two of the connectors we use most are custom builds precisely because the vendor never published one, X and Kit. This release lowers the bar they have to clear.

Expect the directory of available connectors to grow faster over the next year than it did over the last one.

4. Connecting gets more standard

A cluster of proposals aligns MCP’s authorization with the way OAuth and OpenID Connect are actually deployed. The user-visible consequence is fewer connectors that ask you to paste developer credentials into a form.

We met one this month: pulling X data through a third-party bridge still required four separate developer keys generated by hand. That pattern is a symptom of a protocol that hadn’t finished specifying authentication. It should become rarer.

There is a related change that deserves more attention than it is getting. Requests that used to travel from the connector to you — asking permission, asking for a missing detail — have been redesigned around what the spec calls Multi Round-Trip Requests. Instead of pushing a question down a connection it holds open, the connector answers your request by saying it needs something from you first. The practical effect is that nothing interrupts you out of nowhere: every prompt you see traces back to something you started. It also makes a good habit cheap to build. Supabase describes using it to have a tool confirm with you before it acts — before a query that would delete data, or before creating something that costs money.

There’s a second half to this that only matters if you work inside a larger organisation, and it is further along than today’s coverage suggests. The machinery for a company to centrally control which MCP servers its people may connect is already stable — it shipped in June as a separate extension called Enterprise-Managed Authorization. An administrator sets the policy once in the company’s identity provider, and the servers an employee is entitled to connect themselves at first login, with no per-server consent screen at all. Okta is the first identity provider supported, and among the servers that already support it is Canva, one of the connectors sitting in our own account.

That detail matters beyond the enterprise question, because it is the clearest evidence that the extensions model actually works. EMA was built, stabilised and adopted on its own schedule without waiting for a specification release. Making that path official is one of the quieter things today’s revision does. For now you connect what you like — inside a company, increasingly, you will connect what IT has already decided you may.

The change that matters most, and nobody is translating it

Buried under the architecture is the first formal feature lifecycle in MCP’s history. Every feature now has a defined state — active, deprecated, or removed — and a minimum of twelve months must pass between a feature being deprecated and the earliest date it can be removed.

For someone who builds workflows rather than servers, this is the most consequential line in the entire release. It is the first time the protocol has made a written promise about not breaking you, and it converts MCP from something you experiment with into something you can reasonably plan around.

Now the fine print, because it is being skipped everywhere: the policy protects protocol features, not vendors.

A twelve-month deprecation window says nothing about the company behind any individual connector. A connector can still be discontinued next Tuesday, repriced without notice, or quietly archived. We found one already dead — a functioning MCP server with published benchmarks whose repository went read-only in April. The protocol it was built on is now guaranteed stable. The server is still gone.

So the release makes the foundation safe and leaves the building your problem. That is a genuine improvement and it is only half the risk. The half that remains is the one worth planning for.

What to do today

Nothing urgent, which is the correct outcome of a well-run protocol release. But four things are worth carrying into the next few months.

• If a connector breaks in the coming weeks, assume the vendor’s migration before assuming your setup. Check their changelog before you touch anything.
• When you have a choice between an official connector and a custom one, the official one is now more likely to be maintained, not just easier to install.
• Treat an in-chat interface as a signal that someone is actively working on that connector.
• Keep a short written note of what you would lose if each connector you rely on disappeared tomorrow. The protocol won’t answer that question for you.

The short version

Most protocol releases are invisible to the people who benefit from them, and this one is no exception on day one. Its real effect is slower and duller than a broken workflow: the stack you assemble this year is meaningfully more likely to still be standing next year.

That isn’t exciting. It is close to the most useful thing a protocol can give you.

The official announcement is on the Model Context Protocol blog.

You Might Also Like

More on the connectors mentioned above, all tested in our own account before we wrote a word about them.