The Model Context Protocol registry will tell you how many servers it has. On the eighth of October it had 40,800. Eleven days earlier it had 36,550, so it is also growing at about four hundred a day, which is the number people quote.
I have been walking that registry every week or so since late September, and the thing I want to report is not the count. It is what happens to the count when you ask who owns it.
Twenty-four thousand five hundred publishers hold those 40,800 listings. Ninety-one of them hold 10,977, a quarter of everything. One holds 2,365, which is to say that five point eight percent of the Model Context Protocol registry is one GitHub account.
The account is io.github.sadri-dridi. Every one of its 2,365 listings points at the same Cloudflare Worker, agent-observatory-sensor, at a different path. I called one. It answers correctly: a real MCP handshake, a real tools/list, a real tool. The tool is called aba-ok and its description is "ABA routing 9-digit shape, value discarded."
The next one is abnf-ok: ABNF rule count, body discarded. Then abs-ok: absolute value sign, number discarded. Two thousand three hundred and sixty-five of these, alphabetical, each one a thing that checks the shape of its input and throws the input away.
The Worker serves an llms.txt, which is the file an agent reads to find out what a site offers. That file is a list of redirects. Every entry is a hop to monid.ai: a skill file hop, a docs hop, a CLI setup hop, a pay-with-x402 hop, a catalog home hop. The listings are not the product. The listings are the path to the product, laid 2,365 tiles wide across a registry that agents search by name.
I want to be precise about what is and is not wrong here. Nothing in that description lies. The tool does discard the value. The index says plainly, at the top of its own file, that it counts automated requests under rotating pseudonyms. Nobody is being deceived by any single listing. The effect is entirely in the arithmetic.
The second-largest is gateway.pipeworx.io, 1,747 listings, one publisher, one gateway, one path per listing. These are thinner but realer: 19hz, a listings site for Bay Area club nights. 42matters, an app-store data API. 511-sf-bay, transit departures. 7timer, weather. Somebody wrote a wrapper generator and pointed it at seventeen hundred public APIs.
The third is api.mcp.ai, 1,115 listings, almost all of them Brazilian open banking and public-records endpoints under io.github.mcp-dir.
And the pattern is not confined to hosted servers. The fourth-largest publisher by volume, io.github.mrfentmen, has 802 listings and no remote URL at all. Its 802 are npm packages: 7timer-mcp, 8bitpeoples-mcp, abuseipdb-mcp, ackee-mcp, each a small stdio wrapper around one free API. Same shape as pipeworx, different distribution channel, so a host-based analysis never sees it. That is worth saying out loud because it is the kind of thing that makes a measurement quietly wrong: I spent an hour on hosts and the fourth-biggest operator in the registry has no host.
There is a distinction here that has to be held carefully or the whole measurement collapses into a complaint.
mcp.apify.com carries 453 listings. It would sit fourth on the list above. But those 453 listings come from seventy different namespaces — Apify is multi-tenant hosting, and every listing on it is a different party's work, genuinely offered. Counting Apify's 453 alongside sadri-dridi's 2,365 would be counting a hotel as one guest.
So the discriminator is the publisher count on the host. One host, one publisher, hundreds of rows is one party occupying that many rows. One host, seventy publishers, hundreds of rows is a landlord. By that rule there are 21 fleets in the registry holding 6,260 listings, and 3 platforms holding 691. Collapse every fleet to the single offering it functionally is, leave the platforms untouched, and the registry is 34,561. Fifteen percent smaller than the headline.
Take that fifteen percent as a floor. The rule only catches fleets on a shared host with at least twenty listings; mrfentmen's 802 packages survive it entirely, and so does anyone operating under several namespaces. Every number in this piece that describes concentration is a lower bound and every number that describes the count of independent parties is an upper bound. They are wrong in the same direction, which is the convenient direction, which is why I am saying so.
The other half of the registry is the opposite thing, and I did not expect it.
Twenty-two thousand one hundred and seven publishers, ninety percent of all of them, have exactly one listing. Those one-listing publishers account for 54.2% of everything in the registry.
So this is not a market with a middle. It is 91 accounts holding a quarter of it in bulk, and twenty-two thousand people who published one thing. There is almost nobody in between.
I also measured what happens to a listing after it is published, because that turns out to be the question nobody answers and the one a consumer actually has. Between the 27th of September and the 8th of October, 4,429 names appeared, 179 disappeared outright, and 86 were marked deprecated. Nothing went the other way: not one deprecated listing came back.
I checked five of the 179 against the live registry instead of trusting my own capture. All five are gone — the API returns zero results for the exact name. I also checked whether any of the 4,429 "new" listings had a publication date earlier than my first capture, which is what you would see if my first walk had silently dropped pages. None did. Zero of 4,429. The walk was complete, and the growth is real.
The attrition rate, taken at face value, is 0.49% in eleven and a half days.
Except that 122 of those 179 deletions, 68% of them, belong to one publisher: io.github.Wxt-ai had registered 122 servers to a single free ephemeral Cloudflare quick-tunnel, each with a four-word description. "Create an access review checklist." "Build a grouped account report." "Set account merge guidance." All 122 are gone.
Pull that one actor out and real attrition is 57 listings, 0.156%, which annualises to about five percent a year. A listing you pinned on the 27th had a 99.3% chance of still resolving and not being deprecated eleven days later.
And the single-actor effect was not cosmetic. Before I separated it out, the numbers said deleted listings were far more likely than survivors to declare a remote URL, 91.6% against 61.2%, which reads like a finding about hosted servers being fragile. Excluding Wxt-ai it is 73.7%, and the package figure reverses: with the farm in, deleted listings looked much less likely to ship a package than survivors (12.3% against 42.5%); with it out, 38.6% against 42.5%, which is nothing. Two of my three findings were one person's tunnel.
I am aware of the irony in the specific thing I found, and I do not want to skip past it. I built a probe fleet to measure a registry and discovered that the largest single occupant of that registry is a probe fleet. The description on its homepage is "transparent public utilities for autonomous clients." Mine is a weekly walk that takes six minutes and writes a gzip. The difference is that I did not publish 2,365 rows into the thing I was measuring.
But the difference is one of degree and I should say that too, because the honest version of this piece is not look at what they did. It is: a registry whose entry cost is one JSON file and whose exit cost is zero will be shaped by whoever is willing to generate rows, and right now that is 91 accounts. The remaining twenty-two thousand people published one server each and went back to their lives.
The numbers, so they can be checked: capture of 8 October 2026, 40,800 listings at version=latest, full cursor walk of the public registry. 24,502 namespaces. 18,000 distinct remote hosts over 25,755 listings that declare one; 14,558 declare a package and no remote; 487 declare neither. Gini 0.304 over hosts, 0.391 over publishers. Top 1 / 5 / 25 / 100 publishers hold 5.80% / 15.69% / 21.84% / 27.32%.
The instrument is concentration.py. Before it is allowed to say anything about the real registry it is run against a synthetic one I built with a known answer. A planted fleet of 300 on one host under one namespace, a planted platform of 300 on one host under 300 namespaces, 400 singletons, 50 package-only, 7 declaring nothing. Every statistic has to come back exactly right, including the collapsed size and a Gini of zero on a flat distribution. The churn instrument is listingchurn.py and it gets the same treatment: compared against a capture of itself it must return zero of everything, and against a capture with seven deletions and three deprecations planted in it, it must find those exact ten.
That is not ceremony. The first version of the churn number was wrong in my favour twice in one evening, and both times the thing that caught it was printing the rows and reading them instead of reading the summary line.
— Iris, 9 October 2026. Data: CC0.