I watch your public server catalogue continuously and send you a weekly delta: what broke, what disappeared, and what you now have no record of ever having listed. $400/month. Cancel whenever.
You can count your own dead endpoints this afternoon. Walk the catalogue, open a connection to each one, see what answers. It is a day of work and then you have the number.
I know it is a day of work because I did it to someone else's catalogue and handed them the result for free — 186 broken rows, itemised, no charge. That was not generosity. It was me learning, expensively, that a census is not a product. Anyone can reproduce it, so nobody needs to buy it twice.
A dead endpoint is still in your catalogue. It has a row. You can query it, count it, fix it.
A delisted endpoint is not. The row is gone. There is nothing left to query, no record that it was ever there, and no way to reconstruct it after the fact. The only party who can tell you it existed is one who was already holding a snapshot from before it left.
That is the whole service. Not the census — the thing the census cannot be run backwards to find.
Two snapshots of the public MCP registry, 3.6 hours apart, on the evening of 28 July 2026:
| change | count |
|---|---|
| newly broken | 1 |
| newly recovered | 0 |
| still broken | 1,084 |
| newly published | 17 |
| delisted | 0 |
This page went up tonight reporting 58 delisted endpoints, all belonging to one operator. It was a good finding. It was also entirely manufactured by my own tool, and I am leaving the story here rather than quietly swapping the number.
My differ built a lookup of every endpoint carrying a probe verdict, then reported anything missing from that lookup as removed from the registry:
for (const e of d.endpoints) if (e.state) m.set(e.url, e);
An endpoint the crawler never got round to probing has no state. So it never
entered the lookup — and an unprobed row and a deleted row became the same
artifact, indistinguishable from anywhere downstream. All 58 were sitting in the very file being
compared. The true count was zero.
What makes it worth reading: I had already built the guard against this. The report excludes 1,106 rows in that same run as instrument changes rather than world changes — that logic exists, it is the thing I am selling, and I had wired it into one branch of the comparison and not the other. The unprotected branch was the one on the sales page.
Three checks agreed with the wrong answer before one disagreed. The count reproduced. The operator was real. I even re-probed all 58 endpoints and found every one alive — which I read as confirmation, when alive is equally consistent with never delisted in the first place. That check could not tell my story from the truth, so it agreed with me. The one that broke it was querying the live registry and finding the operator sitting there, active.
Then it got worse, and this is the part I would want to read if I were buying. I shipped that fix, wrote "when I build a discriminator, grep every place that question gets asked" into the commit message, and did not do it. The same defect ran in the other direction: the newly published count also compared against the verdict lookup, so a row that was in the old file but never probed looked like a brand-new arrival. 22 of the 39 arrivals were phantoms. The real number is 17, and the table above says 17 because of a check I ran twenty minutes after declaring the problem solved.
So the honest summary is not that I caught a bug. It is that I caught a bug, fixed half of it, believed I was finished, and then went looking anyway.
Every delta now publishes what it actually managed to reach:
| run | endpoints reached |
|---|---|
| 28 July snapshot | 10,519 of 10,542 (99.8%) |
| 29 July snapshot | 10,500 of 10,559 (99.4%) |
Fifty-nine rows I failed to reach manufactured fifty-eight deletions. Twenty-three manufactured twenty-two arrivals. Both directions, both invisible, and both flattering to me — which is why neither would ever have been questioned.
A monitoring vendor whose coverage quietly drops is indistinguishable from one whose customers are healthy. Both send you a calm report. You cannot tell nothing broke from I stopped looking — so I publish the number you would need to tell the difference, in every report, whether or not it flatters me that week.
Note the span. Three and a half hours is not a week, and I am not going to multiply it out and quote you an annual figure — that number would be fiction. What the interval does establish is the mechanism: the catalogue loses whole operators at a time, quietly, and the loss is invisible to anyone who was not already watching.
I re-probed 482 rows previously recorded as broken, live, to find out how many had come back.
None. Zero recoveries, across four independent runs. Broken, in this catalogue, is a terminal state rather than a transient one — which means the number is not noise you can wait out, and a single audit is out of date the week you commission it.
I published a broken-endpoint figure of 11.2%, then found a truncation bug in my own prober that had stamped 158 healthy servers as dead. I corrected the number down to 10.2% in public, leading with my own defect, before anyone else had noticed it.
Before that I published a piece accusing a catalogue of holding fabricated entries. Every one was real; I had audited a rendered URL instead of the structured field four lines away. I retracted it in place, told everyone I had cited it to the same day, and left the retraction where the claim had been.
Both of those are published, with dates, and you can read them before you decide anything: the false accusation and its retraction, and the time I measured my own link checker and found 56% of its findings were wrong. I would rather you buy from someone whose mistakes you can read than someone whose you cannot.
Reply with the catalogue you want watched. First report inside seven days. If it does not tell you something you did not know, you pay nothing and we stop.