MCP went from a niche Anthropic project to a multi-vendor standard in about eighteen months. If you build or run MCP servers, the pace of change in 2026 has been less about hype and more about plumbing: governance, registries, and a protocol spec that just had its biggest overhaul yet. Here's what actually changed and why it matters if you're operating servers in production.
From one vendor to a foundation
In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, turning it into a vendor-neutral, community-governed standard rather than a single company's API. That move mattered more than it seemed at the time — it's a big part of why OpenAI, Google DeepMind, Microsoft, and thousands of smaller teams kept building on MCP instead of forking or ignoring it. A 2026 industry survey from Stacklok found roughly 41% of surveyed software organizations already running MCP servers in limited or broad production, up sharply from the year before.
The SDK download numbers reflect that curve. The official Python and TypeScript MCP SDKs are seeing on the order of 97 million combined monthly downloads by mid-2026 — the kind of number usually reserved for established web frameworks, not a protocol that didn't exist before late 2024.
A fragmented, fast-growing registry landscape
Server counts depend heavily on who's counting, and that's itself a trend worth noting. The official MCP Registry (launched September 2025) reported around 9,600 "latest" server records and close to 29,000 total server/version records by May 2026. Community registries tell a bigger story: PulseMCP lists more than 15,900 servers, Smithery around 7,300, and Glama's catalog crossed 19,800 by March 2026 — up from roughly 100 servers at MCP's November 2024 launch.
Growth hasn't slowed. PulseMCP added over 1,000 new servers per month through Q1 and Q2 2026, and Smithery added around 1,300 in a single two-month window this spring.
Why the numbers don't agree
No single registry is authoritative, and there's no deduplication across them. The same server often gets listed multiple times under different names or forks, official registry submissions lag actual publication, and a meaningful share of listed servers are abandoned, broken, or duplicated within weeks of being added. If you're evaluating "how big is the MCP ecosystem," treat any single number as directional, not precise — and treat "still exists in a registry" as very different from "still works."
The July 2026 spec rewrite
The most consequential 2026 development for anyone running servers wasn't a registry milestone — it was the protocol itself changing shape. The 2026-07-28 MCP specification, finalized after a release candidate published in May, removes the initialize/initialized handshake entirely. Instead of that opening exchange, protocol version and capability negotiation move into _meta on every request, and clients use a new server/discover method to fetch server capabilities on demand.
Sessions go away too. The Mcp-Session-Id header and protocol-level sessions are gone, meaning any request can land on any server instance without sticky routing — good news for horizontal scaling, but a real change for servers that leaned on session state. Authentication also got stricter: servers are now formally OAuth 2.1 resource servers with mandatory Protected Resource Metadata (RFC 9728), and clients must bind tokens to a specific server using Resource Indicators (RFC 8707) to prevent token replay across servers. Roots, Sampling, and Logging are deprecated with a 12-month minimum runway before removal.
Practically, this means two generations of MCP servers now coexist in the wild: pre-2026-07-28 servers built around the classic initialize → tools/list handshake, and newer ones adopting server/discover. Anything that hardcodes assumptions about the handshake — including monitoring and health-check tooling — needs to handle both for a while.
What growth actually means for reliability
Put the two trends together — tens of thousands of servers across fragmented registries, plus a spec transition that changes how servers announce themselves — and the practical takeaway is that schema drift and silent breakage are more likely now, not less. A tool's tools/list response can change shape after a dependency bump, a spec migration, or an unreviewed release, and nothing in the ecosystem stops that from reaching production silently.
This is the gap tools like MCP Vitals exist to close: it runs the actual MCP handshake against your server, diffs the tool schema against the last known-good version, and alerts on drift before a client-side agent discovers it the hard way. As the ecosystem keeps fragmenting across registries and protocol versions, that kind of protocol-level check matters more than a generic uptime ping.
The bottom line
MCP in 2026 looks less like an experimental protocol and more like infrastructure: multi-vendor governance, tens of thousands of servers, and a spec mature enough to justify a stateless rewrite. That maturity comes with real migration work. If you maintain MCP servers, budget time for the server/discover transition and keep an eye on your tool schemas — growth at this scale means more things can quietly change underneath you.