We analyzed the MCP registry: most servers stop updating

The official MCP Registry is where every vendor’s Model Context Protocol server gets listed, and the question worth asking isn’t how many are there. It’s how many are still being worked on. As of September 24, 2026, the official MCP Registry listed 35,491 MCP servers from 20,581 publishers, with 114,876 versions published between them. We downloaded the whole registry and checked, server by server, who’s still publishing to it.

Every SaaS vendor is racing to ship an MCP server right now, often to show it’s keeping up with AI, and that’s a reasonable thing to announce. The harder part comes later. Once customers have wired their agents to that server, the vendor has to keep it running for years, and the timing isn’t really its own to decide. It depends on when those customers are ready to move, and on how fast the API underneath the server keeps changing.

Why every vendor has one this quarter

An MCP server is the fastest way for a vendor to say it belongs in the agent era. Ship it, announce it, move on. Much of that pressure is about showing modernization and keeping up with the speed of AI, more than about the agent traffic a vendor sees today.

That’s exactly the kind of rush that produces servers sitting in the registry with a single version. Something built fast for a launch post becomes something somebody has to run, indefinitely, whether or not anyone keeps building on top of it. It’s the same gap between what AI can generate and what a team can responsibly operate long-term that we laid out in AI as a thinking partner, not an execution layer: shipping fast and owning the result are different jobs, and it’s easy to fund the first without anyone owning the second.

Smarter models are starting to route around it

Anthropic’s own engineering team found that having an agent write code that calls its tools, instead of calling each tool directly, cut token use on one task from 150,000 to 2,000. Cloudflare put the finding more bluntly: “LLMs are better at writing code to call MCP, than at calling MCP directly.” Its own version of that idea covers more than 2,500 API endpoints in about 1,000 tokens.

Stripe’s MCP docs open with a different instruction now: “Start here: Integrate with Stripe using skills and plugins.” MCP sits inside that bundle. It isn’t the headline anymore.

The model doing the calling is starting to prefer the API underneath the MCP server to the server itself, which mirrors the argument in what AI assistants can actually execute: the interface decides what capability turns into, and MCP is losing that role to the raw API underneath it. New agent development is drifting toward the interface vendors already had, not the one they just spent a year building. Y Combinator’s Garry Tan wrote that MCP “eats too much context window” and replaced it with a CLI wrapper he built in 30 minutes.

What we found in the MCP registry

The registry data breaks down into three patterns.

Most servers stop after one version. Of the 13,554 servers listed for at least 90 days, 54.5% have only ever published one version to the registry. A registry version isn’t a code release, and a hosted server can change behind the same URL without a new one showing up, so this measures publishing to the registry, not necessarily the underlying code.

The 90-day window looks the same everywhere. Of those same servers, 78.7% published no new version in the 90 days to September 24, 2026, and the pattern isn’t limited to individual developers: the rate is 82.5% for publishers that verified a domain, 77.5% for GitHub organizations and 80.4% for personal GitHub accounts. Domain verification proves control of a domain, not that the publisher is a company, and the differences between those three groups aren’t statistically significant.

The July spec rewrite didn’t change the pattern. Of the 18,676 servers listed before the July 28, 2026 revision of the MCP specification, 81.2% have not published a new version since, and that is normal rather than a reaction: in three comparable 58-day windows earlier in 2026, between 84.0% and 87.0% of listed servers published nothing new. The MCP spec allows version negotiation, so a server built on the older protocol can keep answering clients that haven’t updated either. A quiet server in the registry can still be doing its job.

New publishers kept arriving through all of this: the number of new publishers each month grew from 277 in September 2025, the month the registry opened, to 3,962 in August 2026, while new server listings grew from 456 to 6,655. The first of those months only covers the registry’s September 8 opening, and some of that growth is the registry itself getting adopted rather than new demand for MCP, but the installed base connecting to the registry keeps expanding at the same time most of what’s in it has gone quiet.

Vendors have done this before

SaaS vendors rarely retire the interfaces customers already built on. They stop building on those interfaces themselves and keep the lights on for whoever’s still wired in.

PayPal still describes its NVP and SOAP APIs as legacy, and still supports them. WordPress turned XML-RPC on by default in 2012, added a REST API to core in 2016, and XML-RPC still ships in WordPress core today, a decade later. Neither company wanted a second interface running forever. Their customers made that decision for them by wiring things to the first one.

The glue connecting AI to SaaS has already turned over four or five times in three years. ChatGPT plugins launched in March 2023 and were shut down about a year later. OpenAI’s Assistants API ran for nearly three years before it was switched off on August 26, 2026, and the call that retrieved the conversations stored in it no longer works. Apps built on MCP arrived in late 2025, and OpenAI deprecated its Agent Builder eight months after launching it. Zapier’s AI connector is on its third generation since 2023: a ChatGPT plugin, then AI Actions, now Zapier MCP. Every generation left an installed base behind it when the next one arrived. MCP is the current generation. Betting it’s the last one means betting this cycle stops here.

MCP itself already needs a legacy tier, and it’s barely two years old. The official SDK ships a frozen copy of the old v1 transport, kept for migration purposes only, and it’s still pulled 272,904 times in a single week. Atlassian runs its v1 and v2 MCP endpoints side by side; the endpoint it marked “no longer supported” after June 30, 2026 was still responding on the day we pulled this data. GitHub’s deprecated MCP server still gets 88,163 downloads a week, 17 months after GitHub deprecated it. The protocol built to replace the old glue is already carrying its own old glue. The July 2026 spec revision itself removed features co-creator David Soria Parra called foundational: “A lot of things that made MCP are gone.”

A legacy MCP server isn’t free to keep running

An MCP server isn’t a frozen artifact sitting quietly on a machine. A vendor’s MCP server is usually a layer on top of the vendor’s own API (Stripe’s, for example, gives agents tools to “interact with the Stripe API”). When an agent asks it to do something, it turns that request into API calls, and that API has its own version clock, set by the vendor’s own release cycle, not by MCP’s.

Meta ships a new Graph API version every few months and supports each one for about two years. LinkedIn ships versions monthly and guarantees each one a minimum of one year. Stripe said in 2017 that it had kept every API version since 2011 working, across almost a hundred backwards-incompatible upgrades. Every MCP server sitting on top of those APIs inherits the fastest of those clocks. Keep a legacy MCP server running, and you’re keeping two moving parts in sync at once: the protocol version a customer’s agent still speaks, and the vendor API version underneath it that keeps shifting on its own schedule.

What this means before you wire an agent to a vendor’s MCP server

We wrote before that the question that matters is whether the API belongs to someone else. If it does, you’re not adopting a feature. You’re adopting a dependency you can’t schedule.

The same test applies to MCP. Ask for the vendor’s deprecation policy before you wire anything to its server. Ask how it versions the server. And ask whether it ever renames a tool out from under the agents already calling it. A vendor with real answers to those questions is one that’s planning to carry the interface, not just ship it.

Where Oktopost sits

Oktopost runs headless today through its own MCP server and REST API. Carrying the networks’ API changes, on their schedule, without breaking what customers already built on top of us, is the job we’ve done for over a decade, long before MCP existed. Our own content team runs its Oktopost work through an AI agent on that layer, with every post still reviewed and approved. See how that works.

The interface connecting AI to SaaS is going to keep changing. What you’re buying, when you pick a vendor to wire an agent to, is whoever’s committed to carrying that change for you.

See how the Oktopost MCP server works

In summary: How we analyzed the MCP registry

On September 24, 2026, we downloaded every entry in the official MCP Registry (registry.modelcontextprotocol.io), excluding entries marked deleted, and checked it against a second full download. A server is one registry name, dated by its earliest version. Publisher type comes from the registry’s verified namespace: a domain, a GitHub organization or a personal GitHub account. “New version” means a new registry entry. Hosted servers can change without one, and about 13% of sampled inactive package-based servers had released a newer package anyway.

The post We analyzed the MCP registry: most servers stop updating appeared first on Oktopost.

About the Author

Leave a Reply

Your email address will not be published.

You may also like these