The Model Context Protocol Is Big. Read the Numbers Twice

The Model Context Protocol is big enough that nobody argues about whether it is a fad. Anthropic published the protocol in November 2024 and donated it to the Agentic AI Foundation, a Linux Foundation fund, on 9 December 2025. Since then the foundation and its members have put out a handful of numbers, and they are worth laying out with their dates, because they are not all measuring the same thing.

Between the December and April figures, monthly downloads rose from 97 to 110 million, about 13 percent in roughly four months. We found no newer official server count than the December one, so we have not used one.

An install of a package, not a running server. The foundation's own recap of the April summit says why the figure is so large: OpenAI's agent SDK pulls the protocol in as a dependency, and so does LangChain. Every fresh build of every project that depends on them downloads the SDK again, whether or not anyone stands up an MCP server.

That does not make the number meaningless. It says the Model Context Protocol has become a default dependency, which is a real form of adoption. It just cannot be read as 110 million of anything you could point at. The best evidence of use is in places public counts cannot reach.

Our reading: the interesting growth is private. A public server count will understate it, and a download count will overstate it. Treat both as direction, not measurement.

The versioning page names 2026-07-28 as the current revision, with 2025-11-25 as its predecessor. It is a real change for anyone who runs a server, not a tidy-up. Here are the parts that alter how you host one.

The stateless core is the one that matters for infrastructure. A server that does not have to remember a session between calls can sit behind any load balancer, restart without breaking a client, and sleep when nobody is calling it. That suits compute that wakes on request, which is how our Builder plan works. It also makes the design more honest: state is now something you name, not something a header implies.

Two smaller changes bite server authors more than the headlines do. SSE stream resumability is gone, so a broken response stream loses the in-flight request, and the client must send it again as a new request with a new ID. Anything slow or costly needs to be safe to repeat, or should use the tasks extension. On the other side, results from tools/list and similar calls must now carry a ttlMs freshness hint and a cacheScope of public or private, so a client can cache a list instead of asking again. Set ttlMs too low and you invite polling. Set it too high and a client may show a tool you have already removed.

The Model Context Protocol can be. Most deployments, by the summit's own account, are not yet. The recap describes a security researcher demonstrating DNS rebinding, where a malicious web page uses your browser to make tool calls against an MCP server running on your own machine. He named several well-known projects as affected, and his advice was to check the SDK tier, validate the Origin header and stop assuming that local means safe.

A second talk made the harder point. Authentication is common; authorisation enforced on every request is not. Arcade's founder put it in a line that is worth keeping.

Read it as a design rule. What a model says is cheap and forgiving. What its key is allowed to do is where the damage lives, so the limit has to sit outside the model, in the credential and the platform behind it.

A common complaint is that the Model Context Protocol eats the model's context window. The recap gives a number: before Claude Code added tool search, MCP tools took up 22 percent of a 200,000-token window, and afterwards essentially none. Soria Parra's view was that these are client problems, not protocol problems.

If you write a server, this still lands on you in one way. Every tool you expose is a description a client may have to carry. The specification now asks servers to return tools in a deterministic order so clients can cache the list. Keep the list short, name things plainly, and do not ship forty tools where six will do.

• Give every agent its own key with scopes narrower than yours, and check the scope on every call, not only at sign-in.
• Put a monthly spend cap and an expiry on the key. A leaked key with a clock and a ceiling is an annoyance, not an incident.
• Make every change plannable. A dry run that says what would change and what it would cost lets an agent, or a person, stop before the expensive step.
• Refuse destructive calls without an explicit confirmation flag, and return the plan when you refuse.
• Validate the Origin header on any server reachable from a browser, including local ones.
• Pin the protocol version you support, and plan for the 2026-07-28 removals of the handshake and sessions.

We sell a platform with an MCP server, so weigh this accordingly. Our view of the Model Context Protocol is that a platform built around it is defined by its limits, not its reach. Any platform can expose an API to a model. The useful ones let you say what the model may spend and change before it starts.

On Helm7 the MCP tools and the REST routes come from the same operation list, so nothing is agent-only. An agent key carries scopes, an optional monthly cap and an optional expiry, and a call past the cap is refused before anything is spent. The agents page shows a session, scoped API keys for AI agents explains the key model, and dry-run deployment plans covers the plan step. If the protocol itself is new to you, start with what an MCP server is.