Ecosystem
MCP Just Became Modular. 'MCP-Compliant' Is About to Stop Meaning Anything
The 2026-07-28 spec splits MCP into a stateless core plus optional extensions like Tasks and MCP Apps. Two servers can both be 'compliant' and support completely different things — which turns 'what does this server actually do?' into the ecosystem's hardest question.
MCPOrbit Team
MCPOrbit
- Published
- Updated
- · Updated
- Read time
- · 6 min read
The next Model Context Protocol (MCP) spec — release candidate out now, final on July 28 — is the biggest revision since MCP launched. Most of the coverage is about what's new. The more important story is what it quietly does to a single word: compliant.
One protocol becomes a core plus a menu
Until now, 'supports MCP' was close to binary: a server spoke the protocol or it didn't. The 2026-07-28 release reorganizes MCP into a small, stateless core and a framework of optional extensions. Tasks adds long-running work. MCP Apps adds server-rendered UI. Enterprise-Managed Authorization adds identity-provider-controlled access. Each one is opt-in, negotiated per server.
'MCP-compliant' is now a matrix, not a checkbox
Two servers can both truthfully claim compliance and share almost none of the same capabilities. Before you wire either into an agent, the questions that actually matter are no longer answered by the word 'compliant':
In an ecosystem that has already crossed 5,800 community-published servers — where the loudest take on the MCP subreddit is that '95% of MCP servers are utter garbage' — the bottleneck was never the protocol. It's discovery: knowing which server to trust before you connect it. Modular extensions make that strictly harder.
The bottleneck is no longer the protocol itself; it's discovery.
Capability has to become discoverable metadata
The fix isn't reading every server's source or trusting its README. Capabilities need to be declared and inspectable before connection — the same way a Server Card at .well-known/mcp.json advertises a server's identity today. A useful capability record makes four things visible up front:
- Extensions supported (Tasks, Apps, EMA, and the rest)
- Target spec revision and deprecation status
- Authentication model
- When each capability claim was last verified
This is exactly the layer MCPOrbit builds: a registry where every server's real capability matrix is visible and continuously verified, so agent builders choose on evidence instead of README claims.
What to do before July 28
The protocol won. The next race is discovery — and modular extensions just raised the stakes.
About the author
MCPOrbit Team
MCPOrbit
The MCPOrbit team builds the control plane for Model Context Protocol — one view of every server in your stack and where each one sits on the migration curve.
