I’ll be direct: the “97 million” headline is the easy number to lead with, and I’ll use it, but it’s not the story. The story is the document underneath.
The 2026 roadmap for Model Context Protocol was published on March 9 by David Soria Parra, the Lead Maintainer of the project. It reads in six minutes — and it’s the most honest strategic communication piece I’ve seen from an AI infrastructure project in a long time. What the document effectively says is this: MCP has already moved past its hobby phase, production deployments are exposing a predictable set of problems, and the maintainers are restructuring the project around those problems instead of around release dates.
That’s a different kind of roadmap than we’re used to seeing in AI tooling.
First the Number, Then Reality
The SDK download figure — around 97 million monthly downloads across the Python and TypeScript SDKs combined — is real, and it’s significant. It puts MCP in the same adoption category as protocols we now treat as infrastructure: OAuth, gRPC, HTTP in its early maturity. More than 10,000 active servers. First-class client support in Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code. In December 2025, Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation, eliminating the last doubt about vendor-lock governance.
That’s the context. Now the interesting part.
From Release Milestones to Priority Areas
The first thing that changed is how the roadmap is organized. Previous versions were structured around release dates — what ships next, what ships later. That framing made sense when the project was smaller. It doesn’t work anymore. Working Groups and Interest Groups are now the primary vehicle for protocol development, and the new document is organized around priority areas instead of timelines.
The maintainers are explicit about why: a releases-oriented roadmap implies a level of predictability that open standards work rarely has. Translation — they’re refusing to over-promise. That’s not a sign of weakness. It’s a sign of maturity.
The Core Maintainers ranked the candidate areas and arrived at a clear top four. These are the areas where SEPs — Spec Enhancement Proposals — receive expedited review and where the maintainers concentrate most of their capacity.
Priority One: Transport at Scale
Streamable HTTP is the transport that allows MCP servers to run as remote services instead of local processes. It unlocked a wave of production deployments — and it’s also where the first real pain hit.
The specific problems, stated directly in the roadmap: stateful sessions fight load balancers. Horizontal scaling requires workarounds. There’s no standard way for a registry or crawler to learn what a server does without effectively connecting to it.
The solution comes in two parts. First, evolve the transport and session model so that servers can scale horizontally without having to maintain state — more explicit mechanisms for handling sessions clearly. Second, a standard metadata format served via .well-known URLs so that server capabilities are discoverable without a live connection.
A deliberate non-move: the maintainers won’t add more official transports in this cycle. They’re going to evolve the one they already have. Keeping the transport set small is a design principles decision, not an oversight.
Priority Two: Close the Gaps in Task Lifecycle
The Tasks primitive — introduced in SEP-1686 — shipped as an experimental feature and works for what it was designed for. But early production use exposed a concrete list of lifecycle gaps: retry semantics when a task fails transiently, and expiry policies on how long results are retained after completion.
This is the kind of iteration you can only do once something is deployed and tested in the real world. The maintainers say explicitly that they plan to take the same approach with other parts of MCP: ship experimental, gather production feedback, iterate. That’s a conservative discipline in protocol design and it’s worth noting.
Priority Three: Fix the SEP Bottleneck
This is internal plumbing but it has real consequences for anyone who wants to contribute to MCP. Today, each SEP requires a complete Core Maintainer review regardless of domain. That’s a bottleneck. It slows down Working Groups that already have the expertise to evaluate proposals in their own area.
The proposed solution: a documented contributor ladder with a clear path from community participant to maintainer, and a delegation model that allows trusted Working Groups to accept SEPs in their domain without waiting for complete core review. Core Maintainers retain strategic oversight. Working Groups gain room to move.
If you’re following MCP as a strategic dependency — and with 97M monthly downloads, you probably should — the speed at which the protocol can absorb new proposals is directly tied to how quickly it can respond to production pain. This priority is really about scaling the project’s own operational capacity.
Priority Four: Enterprise Readiness — This Is Where It Gets Interesting
This is the priority that matters most to anyone evaluating MCP from a CIO or platform engineering role. The roadmap states it plainly: companies are deploying MCP and running into a predictable set of problems: audit trails, SSO-integrated auth, gateway behavior, and configuration portability.
This is the project’s first formal acknowledgment that MCP production deployments are running into real organizational friction — not just technical gaps.
Two things stand out in how this priority is framed:
First, it’s the least defined of the four. That’s intentional. The maintainers want the people experiencing these problems to help define the work. A dedicated Enterprise Working Group doesn’t exist yet. If you’re in enterprise infrastructure and this matters to your roadmap, the invitation to participate is explicit.
Second — and this is the detail I’d underline for any CIO or architect reading this — the maintainers expect that most of the enterprise readiness work will land as extensions rather than changes to the core spec. Their reasoning: enterprise needs are real, but they shouldn’t make the base protocol heavier for everyone else.
That’s a governance decision worth understanding. It means the core MCP spec will stay lightweight. Audit trails, SSO flows, gateway patterns, portable configuration — all of that will layer on top as optional extensions, not as baseline requirements. For teams evaluating MCP, it means you’ll need to think of the extensions layer as part of your adoption decision, not as a nice-to-have.
What This Means for Teams in LATAM
If you’re at a company evaluating whether to expose internal tools, databases, or APIs to AI agents via MCP, the 2026 roadmap tells you three things:
One — adoption risk is already low. Linux Foundation governance, 97M monthly downloads, every major AI provider shipping support. The protocol isn’t going anywhere.
Two — enterprise-grade auth and audit are in progress. OAuth 2.1 is already in the spec. Flows integrated with SSO, complete audit trails, gateway behavior — those are roadmap items, landing as extensions. If your compliance or security team needs those answers in writing today, you’re going to be building them from extension proposals instead of pointing to a finished spec.
Three — the window in which you can evaluate MCP before your CISO has strong opinions about it is closing. Once integrated SSO auth lands and the Enterprise WG produces official guidance, MCP will go through enterprise procurement like any other infrastructure protocol. That’s not bad — it’s exactly what should happen to critical infrastructure. But teams that start the internal conversation now will be the ones shaping how their organization adopts it, instead of reacting to it.
My personal read: the most important line in the entire roadmap isn’t any of the four priorities. It’s the framing at the beginning — “a release-oriented roadmap implies a level of predictability that open standards work rarely has.” That’s the MCP project telling you how to think about it. It’s infrastructure now. Treat it as such.
Are you evaluating MCP for your organization, or do you already have it in production? How would you prioritize these four axes? Let us know in the comments. 
Sources: MCP Blog (The 2026 MCP Roadmap) · WorkOS (Everything your team needs to know about MCP in 2026)