MCP at 97 Million Downloads: the Protocol Won, but Sessions and Sandboxes Are Still Open Problems

In sixteen months, the Model Context Protocol went from 2 million monthly SDK downloads to 97 million. Somewhere in that climb — past OpenAI's adoption, past Microsoft's, past the Linux Foundation donation — MCP stopped being an integration experiment and became infrastructure. Ten thousand public servers now answer agent tool calls in production, from individual developer tools to Fortune 500 deployments.

And yet, if you run agents in production, you know the feeling: the protocol won, but the hard parts moved. Adoption numbers and production-readiness numbers are answering two different questions. This post names both questions, with numbers — and then works through the two gaps the download count doesn't cover: stateful sessions that still can't scale horizontally, and the fact that every agent framework still ships its own sandbox.

The adoption curve, in four numbers​

The growth curve is worth stating precisely, because it is the "won" side of the ledger:

• November 2024 — Anthropic launches MCP. Roughly 2 million monthly SDK downloads at launch.
• April 2025 — OpenAI adopts MCP. Downloads climb to about 22 million a month.
• July 2025 — Microsoft integrates MCP into Copilot Studio. Roughly 45 million a month.
• March 2026 — 97 million monthly SDK downloads across the Python and TypeScript SDKs, with 10,000+ active public servers in production — a 10x year-over-year increase — and more than 500 MCP clients across Claude, ChatGPT, Cursor, VS Code, Gemini, and Copilot.

In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI — the governance move that turned a vendor project into a neutral standard. Google Cloud's shorthand stuck: MCP is the "USB-C port for AI-to-tool connectivity."

That is a genuine victory, and it has a precise shape. Before MCP, connecting N models to M tools was an N×M integration problem. MCP collapses it to N+M: each model implements one client, each tool implements one server, and they all speak JSON-RPC 2.0 over a standard transport. The download count proves that argument is over. Nobody is seriously proposing a rival tool-call wire format in 2026.

But "agents can call tools" was never the whole production question. It was the handshake. Everything after the handshake — keeping ten thousand sessions alive across replicas, giving agent code somewhere safe to run, trusting the tool on the other end — is where the download count stops telling you anything.

Gap 1: stateful sessions still can't survive a load balancer​

MCP's Streamable HTTP transport — the one remote servers actually use — shipped with protocol-level sessions. The server assigns an Mcp-Session-Id on initialize, the client replays it on every request, and streams stay resumable via Last-Event-ID. Reasonable design. One problem: the reference SDKs store those sessions in process memory.

Follow that to its production conclusion. You put two replicas behind a load balancer. initialize lands on Pod A, which mints the session id and registers the transport in a local map. The next request lands on Pod B, which has never heard of that session — and answers 404 Session not found. Your options, until very recently, were sticky sessions at the load balancer, a single replica, or running stateless and giving up everything sessions provide. This isn't theoretical: it has bitten real deployments in public issues — horizontal-scaling failures against per-pod session maps, operators pinning replicas: 1 with comments explaining that Streamable HTTP sessions are per-pod, teams flipping their transports to stateless mode because hosted clients don't reliably thread the session id anyway.

Rolling deploys wipe every session, because the session lives in the process being replaced.

The honest caveat — and it's important — is that the spec already answered. The July 28, 2026 revision removed protocol-level session tracking outright: no more initialize handshake as a session gate, no more session header, with version, client identity, and capabilities carried per-request in a _meta parameter. MCP is now stateless at the protocol layer by design, which is exactly the property a load-balanced fleet needs.

But a spec revision is not a migrated ecosystem. That change is about seven weeks old. Every stateful server, SDK default, and deployment guide written before late July still describes the sticky-session world, and servers don't get rewritten the week a revision lands. There is now a long tail of stateful servers in that 10,000-strong fleet that will fail the same way under a load balancer until their operators migrate. The adoption number counts them as wins. The readiness number has to count them as pending.

Gap 2: every framework still ships its own sandbox​

The second gap is the one the title promises, so let's be concrete. MCP standardized how an agent calls a tool. Nothing has standardized where agent code runs — and every framework has filled that vacuum itself:

Meanwhile the sandbox vendors — E2B, Daytona, Modal, Runloop — each race to integrate with every framework row individually. E2B's approach shows both the promise and the problem: Firecracker micro-VMs booting in about 150 ms, an @e2b/mcp-server package that exposes sandboxed code execution to any MCP client, and sandboxes that can run 200+ Docker MCP Catalog servers inside isolated VMs.

That is directionally the shared layer the ecosystem needs. But it is one vendor's product, not a protocol — adopting it is a purchasing decision per framework, not a standard the frameworks converge on.

Count the integration matrix and you see the pre-MCP shape repeating. MCP turned N models × M tools into N+M. Agent execution is still N frameworks × S sandbox vendors, with each cell a bespoke integration somebody maintains. Until there is a standard "run this code somewhere safe" interface with the same neutral standing as the tool-call protocol, every new framework rediscovers sandboxing, every sandbox vendor re-integrates every framework, and self-hosters assemble the matrix themselves. The download count can't capture that tax. It counts SDK installs, not the integration nobody wrote yet.

The security footnote that isn't a footnote​

A third data point, briefly, because it sharpens the "two different questions" thesis: the March 2026 systematic threat model of MCP (STRIDE and DREAD across five protocol components, peer-reviewed that May) identified 57 distinct threats, with prompt injection scoring a maximum 50/50 on DREAD and tool poisoning 46.5/50. April brought CVE-2026-32211 — the Azure DevOps MCP server listening without authentication, CVSS 9.1.

The MCPTox benchmark built adversarial variants of 353 real tools drawn from 45 live servers to measure how silently tool descriptions can steer agents. Microsoft now warns that tool metadata is part of agents' software supply chain.

None of this contradicts the adoption story. It is the adoption story's second half: protocols get attacked at scale precisely because they won. But a fleet operator can't spend download counts on any of it. Verified-server supply chains, tool-description provenance, tenant-scoped auth on every listener — that work is measured in audits closed, not SDKs installed.

What "production-ready" would actually look like​

So here is the reframe the numbers demand. MCP's adoption metrics measure interface convergence: one wire format, every provider, ten thousand servers. Production readiness is a different ledger, and for an MCP fleet it currently has three open line items:

1. Stateless-by-default servers. Migrate off pre-July stateful Streamable HTTP behavior so any replica can serve any request. Audit your fleet for Mcp-Session-Id affinity, single-replica pins, and deploys that wipe sessions — then schedule the migration the way you'd schedule any breaking transport upgrade.
2. A shared execution interface. Stop accepting the N×S framework-sandbox matrix as permanent. Whether it converges as a protocol extension, a neutral runtime API, or one open runtime everybody embeds, the goal is the same: "run this agent code somewhere safe" should be one integration, not one per framework per vendor.
3. A verified-server supply chain. Treat tool descriptions as executable supply-chain content: pin server versions, verify provenance, scope tokens per tenant, and assume any unverified server is hostile until shown otherwise.

None of these diminish what 97 million downloads mean. A neutral, provider-agnostic tool-call standard, sixteen months from launch to 97 million downloads, is one of the fastest infrastructure wins in recent memory. But infrastructure is judged by what it carries, not what it counted. The protocol won the handshake. Sessions, sandboxes, and supply chain are the three fights still on — and the fleet that tracks those three numbers alongside the download count is the one that will actually be ready when its ten-thousand-and-first server comes online.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your agents need somewhere to run their MCP servers and sandboxes that you control, star the repo on GitHub or deploy your first app today.

Sources​

• Model Context Protocol adoption figures (97M monthly SDK downloads, 10,000+ servers, provider timeline) — ecosystem briefings aggregated across April 2026 reports
• Anthropic donates MCP to the Agentic AI Foundation under the Linux Foundation (December 2025) — Toloka/AAIF coverage, 2026
• MCP Streamable HTTP stateful-session scaling failures (per-pod session maps, sticky-session requirements) — mcp-grafana #749, mcp-framework #187, IBM mcp-context-forge session-affinity work
• MCP July 28, 2026 revision removes protocol-level sessions; per-request _meta — TrueFoundry wire-protocol notes, July 2026
• E2B sandboxed execution MCP server (Firecracker micro-VMs, MCP gateway inside sandboxes) — e2b-dev/mcp-server
• LangGraph 1.0 / LangChain 1.0 durable agent framework release (October 2025); Microsoft Agent Framework (AutoGen + Semantic Kernel merger)
• MCP systematic threat model: 57 threats via STRIDE/DREAD (arXiv:2603.22489, March 2026; journal version May 2026) — OWASP AISVS research notes
• CVE-2026-32211: Azure DevOps MCP server missing authentication (CVSS 9.1, April 2026); Microsoft warning on MCP tool-description supply-chain risk
• MCPTox benchmark: adversarial variants of 353 tools from 45 live MCP servers (arXiv, August 2025) — CSA research note, July 2026