Where MCP Goes From Here: The Roadmap Past 10K Servers

A year and change after launch, MCP has already answered the question that kills most protocols before they get interesting: will anyone actually use this once the novelty wears off. Nearly 10,000 registry servers, 97 million monthly SDK downloads, adoption by direct competitors of the company that built it, and a governance structure durable enough to survive a major architectural rewrite — that's not a hypothesis anymore, it's a track record. What this closing piece wants to ask is the harder question the first year didn't have to answer: what does MCP need to get right in year two, now that "will it survive" isn't the open question anymore?

The security debt has to get paid down, not just documented

The single biggest unresolved item coming out of this series is the 2026 audit finding 82% of a 2,600-server sample vulnerable to path traversal and 67% to code injection. Documenting that problem, which the audit and the resulting government advisory did well, is necessary but not sufficient. What has to happen next is structural: the registry needs a real trust-tier system that goes beyond "it's published here," the SDKs need to make the secure pattern the default rather than something a careful implementer has to opt into, and the business-application wave — the 950-plus servers with the most at stake — needs to become the template the rest of the ecosystem is nudged toward, not just the lucky subset that happened to have security review built into their own organizations already.

If that doesn't happen, the registry's growth curve becomes a liability rather than an asset — more servers means more attack surface, not more value, if the vulnerability rate doesn't come down. A protocol that keeps growing its server count while its per-server security rate stays flat isn't maturing, it's just getting bigger while carrying the same proportion of risk, and that distinction is the one that will determine whether next year's version of this series is a victory lap or a postmortem.

Governance has to prove it can make unpopular calls, not just neutral ones

The Linux Foundation handoff bought MCP the trust of competitors who wouldn't build on a vendor-controlled protocol. That trust was earned by the donation itself; it has to be re-earned continuously by how the Agentic AI Foundation actually governs from here. The stateless rewrite is a good early sign — it was a real breaking change, motivated by operational reality rather than any single company's preference, and it shipped. The next tests will be harder: security requirements that slow down publishing velocity in the name of safety, deprecation decisions that inconvenience an established vendor, spec changes that one of the big three competitors quietly doesn't love. Neutral governance isn't proven by the easy calls. It's proven by whether the foundation can make the calls that cost someone powerful something, and MCP hasn't faced its hardest version of that test yet.

The enterprise wave needs a second and third wave behind it

Right now, 950-plus business-application servers out of 9,652 total is an encouraging ratio for how early the ecosystem still is. For MCP to be genuine long-term infrastructure rather than a well-adopted developer protocol with an enterprise footnote, that ratio needs to keep climbing — more categories beyond customer service, sales, and internal operations; more industries beyond the early adopters; more of the Fortune 500's actual production systems, not just their innovation-lab pilots. The gap between "impressive enterprise adoption for an 18-month-old protocol" and "the standard every serious company assumes by default" is still a real gap, and closing it is mostly a story that hasn't been written yet.

Stateless was the right call, but it wasn't the last hard call

Protocols that succeed tend to need at least one more uncomfortable architectural reckoning after the one that got them noticed, because the traffic patterns and use cases that show up at 10,000 servers are different from the ones that show up at 100,000. Whatever MCP's next scaling wall turns out to be — and there will be one, because there always is — the test isn't whether the wall shows up. It's whether the same willingness to make a real breaking change, demonstrated once already on 2026-07-28, shows up again when it's needed, rather than getting deferred out of fear of disrupting an ecosystem that's grown big enough to have real inertia now.

What this retrospective series actually argued, stated plainly

Across these ten pieces, the throughline has been that MCP's first year is a genuinely good case study in how infrastructure earns durability: give up control at the moment control starts costing you adoption, design narrow enough to let a wildly diverse ecosystem build on the same core, treat scaling pain as something to fix architecturally rather than route around, and don't let impressive adoption numbers substitute for the harder, slower work of making the thing actually safe to use. MCP got most of that right. The security audit is proof it didn't get all of it right, and that the parts it hasn't solved yet are the parts that matter most going forward.

The scenario worth planning around, not just the trend line

It's worth resisting the temptation to just extrapolate the last year's growth curve forward and call that a roadmap. The more useful exercise is asking what has to be true in each of the plausible branches. In the good branch, the security audit's findings get addressed structurally within the next year — a real trust-tier system, secure defaults baked into the SDKs, the business-application wave's practices spreading into the long tail — and the registry's growth past 10,000, then 20,000 servers becomes a genuine strength rather than a growing liability. In the mediocre branch, growth continues but security stays roughly where the audit found it, and MCP ends up in the position plenty of mature but imperfectly governed ecosystems land in: enormously useful, widely adopted, and permanently accompanied by a "vet everything yourself" disclaimer that never quite goes away. In the bad branch, a high-profile incident traceable to one of these known vulnerability classes forces a reactive, disruptive fix under public pressure rather than the proactive one the ecosystem could still choose now.

Nothing in this series's evidence points definitively at any one of those three branches yet. What the evidence does show is that MCP's governance body has already demonstrated, with the stateless rewrite, that it's capable of making the kind of real structural change the good branch requires. Whether it applies that same capability to security, on a similar timeline, is the open question this closing piece can't answer — only the next year of registry audits can.

The honest closing note

A year from now, the number worth checking isn't going to be the registry count or the download figure — both will almost certainly keep climbing regardless of how well the ecosystem handles its real problems, because raw adoption metrics are sticky like that. The number worth checking is whether a security audit run next year finds a materially lower vulnerability rate than 82% and 67%, and whether the Agentic AI Foundation's governance has been tested by a genuinely unpopular decision and held. Everything else in this series is the story of MCP winning the fight to exist. Those two numbers are the story of whether it deserves to.

Part of the "MCP One Year In" series on aiskill.market.