The most consequential thing in the 2026-07-28 MCP specification is not a feature. It is the decision to formally separate the core protocol from everything else.
That sounds like governance trivia. It changes what you can safely build on.
Why an Extensions Framework Matters
Before this, every promising idea had to either enter the core protocol or live as a private hack. Core protocols must stay small to remain implementable, so good ideas queued behind a very high bar.
The extensions framework lets capabilities ship, get used and mature without bloating the thing every client must implement. It also comes with a formal feature lifecycle: features are Active, Deprecated or Removed, and a deprecated feature must remain available for at least twelve months before removal.
For anyone building on MCP, that twelve-month floor is the actual headline. You can now plan upgrades instead of reacting to them.
Extension One: MCP Apps
Launched in January 2026 as the first official extension. It moves MCP beyond returning text and data, toward servers that can present real interface elements inside a client.
The practical effect is that a tool can ask for structured input properly rather than hoping the model phrases a question well. Design tooling was an early adopter, because choosing colours or selecting a layout through prose was always a poor fit.
Use it when your tool genuinely needs structured human input rather than a sentence.
Extension Two: Enterprise-Managed Authorization
The extension that unblocks corporate adoption. It brings MCP authorisation into line with how enterprises actually manage identity, so an organisation can centralise governance, identity and observability across many servers rather than approving each one individually.
Large platform vendors describe using exactly this pattern: a unified endpoint that brings tools together while keeping governance central.
Use it when you have more than a handful of servers and a security team who reasonably wants one place to look.
Extension Three: Tasks
Tasks moved out of the experimental core into its own extension, with poll-based retrieval and an update method. Change notifications moved to a single subscription stream clients opt into per notification type.
This is the answer for work that outlives a request. A build, a large analysis, an overnight job. Contributed with input from cloud providers who needed reliable long-running agents at scale.
Use it when your tool cannot finish inside a normal request and the client needs to check back.
How to Decide What to Adopt
| You need | Extension | Adopt when |
|---|---|---|
| Structured user input | MCP Apps | Prose input is producing bad arguments |
| Central governance | EMA | You pass five servers or hit a security review |
| Work over minutes or hours | Tasks | Your tool currently times out |
| None of the above | Core only | Which is most first servers, honestly |
Conclusion
Build on the core protocol first and add extensions when a specific limitation actually bites. MCP Apps for structured input, Enterprise-Managed Authorization once governance becomes a real question, Tasks when work outlives a request. The twelve-month deprecation floor means adopting an extension is now a planned commitment rather than a gamble, which is exactly what was missing a year ago.
Frequently Asked Questions
Do all clients support all extensions?
No, and that is the point of separating them. Check client support before depending on one, and degrade gracefully when it is absent.
Will extensions eventually move into the core?
Some may, if they become universal. The framework exists so that decision can be made on evidence rather than on enthusiasm at proposal time.
Is it safe to build on an extension today?
Safer than before, thanks to the lifecycle and the twelve-month deprecation window. Still check the status of the specific extension rather than assuming stability.