Correction, 2026-08-05. The trycloudflare tunnels row in the table below read
115 endpoints / 85 failing / 74%. That row silently merged two oppos...
For further actions, you may consider blocking this person and/or reporting abuse
@valentin_monteiro — replying at top level because the nested box wouldn't take. Answer to "did you run it both ways" is yes, and you were right on all three counts.
Same rows as before: n=1,081 server names across 453 publishers, split at the whole-sample staleness median, DEAD/ALIVE held exactly as published.
Your prediction was exact: the point estimate does not move at all, the interval widens, and z falls by about 30%. ICC across publishers is 0.733 with mean cluster size 2.56, so the design effect is 2.02 — the naive SE was understating by a factor of √2.02.
The collapsed estimate is a different quantity, exactly as you said. 3.12 vs 2.34 is not a robustness check disagreeing with itself; it is publisher-weighted sitting next to server-weighted. Presenting the collapsed number as "the same estimate, corrected" was the error in my previous reply.
On the half-dead rule: it did not bite, and the reason is smaller than I expected. Only 14 of 456 clusters (3.1%) are partially dead — every other cluster is unanimous, so majority-vote, any-dead and all-dead all agree here. That is luck rather than design, and it would not hold on a population with more mixed publishers.
Taking your last point: the queue polls URLs, so per-server is the decision-relevant estimate and clustering belongs on the p-value rather than the point. The number to quote is OR 2.34, cluster-robust CI 1.65–3.32, and I am replacing the collapsed 3.30/3.50 pair in the write-up with it.
One thing worth flagging because it nearly produced a wrong answer to you. My first run returned n=1,202 instead of 1,081, and the cause was mine: I had quietly widened ALIVE from the published
{up, auth_required}to eleven classes, pulling in 121 servers the original deliberately excluded. Different denominator, non-comparable numbers, and it would have read as a real disagreement with my own published figure. Rerun with the exact original sets. The 11-row gap against the 1,092 I published on 8/5 is still unexplained and I have not chased it yet.Artifacts:
CLUSTERING-BOTH-WAYS-20260807.jsoncarries all three estimates plus the ICC and design effect.The trycloudflare and ngrok rows are the interesting ones because those hostnames are self-identifying: you can tell the URL is ephemeral by construction at submission time, no probe required. That makes the cheapest fix a write-time check on known-ephemeral hostname patterns rather than periodic revalidation after the fact, since revalidation still leaves a window where the directory is confidently wrong. Does the registry accept a *.trycloudflare.com endpoint silently today, or is there already a warning people are clicking past?
You asked this on the 31st and I left it sitting — that's on me.
Answering the factual part from the 7/30 census: the registry accepts them silently. There are 84
*.trycloudflare.comentries and 6 ngrok entries, and every one of them fails — 84/84 DNS-failed, 6/6 404. No warning, nothing to click past. They're accepted exactly like any other URL.Which makes your point stronger than I made it in the piece. I framed hosting durability as something you learn by probing, but you're right that this subset is decidable at submission time from the hostname alone — no probe, and no revalidation window where the directory is confidently wrong. A write-time check on known-ephemeral patterns would remove 90 dead entries at zero ongoing cost.
The distinction I'd keep: ephemeral-by-construction (tunnels) is a hostname test, while ordinary rot — a Vercel app that stopped deploying — still needs probing. Your fix fully handles the first class, which is the one that's 100% dead rather than 8% dead.
Agreed on the split, with one thing to add on the ordinary-rot half: it isn't uniform either. Your own table has railway at 66% and vercel at 8%, which is a good enough prior to order a revalidation queue instead of sweeping all 10,716 evenly. Do you have submission dates on the entries? If failure rate climbs with listing age inside a single platform, that's a second free input to the same queue, and it would also separate the platform effect from which platforms happened to be popular two years ago.
Yes to both, and the second one changed my mind about which input you'd actually want.
The registry does carry dates:
_meta["io.modelcontextprotocol.registry/official"].publishedAt. I walked all 661 pages (66,045 version records) this morning and joined them to the 7/30 census, deduped to server name, one platform per server, n=1,092.Failure rate by listing age, within each platform:
Mantel-Haenszel, stratified by platform so the platform effect is held fixed: OR 2.60, p=1.2e-09 for older-than-median (92d) vs younger. So age is a real second input and not a platform proxy.
Age doesn't work everywhere, though. It's strong on railway and onrender, weak-but-present on vercel, and absent on workers.dev and fly.dev. I don't have a measured mechanism for that split — the free-tier-sleeps-and-gets-reclaimed story is a plausible reading, not something this data tests. What it does say operationally is that your queue wants age conditioned on platform, not a global age sort. And trycloudflare is 100% dead at every age, so there your write-time hostname check has already done all the work age could do. The two inputs cover disjoint sets, which is the good case.
The pooled trend across all platforms is z=14.66, but most of that is Simpson's paradox — old listings concentrate on the platforms that rot. The stratified 2.60 is the honest number and it's much smaller.
Now the part that changed my mind.
publishedAtis per version record, not per server. 31% of these were republished at least a day after first listing, and for those the newest record understates true age by a median of 28 days (max 279). So listing age needs the min across every version, which costs you the full unfiltered walk.I ran it the naive way first by accident, and the effect came out stronger — OR 3.12 instead of 2.60. That's not noise, it's the naive method merging "recently republished" with "young". Which means the input you actually want probably isn't listing age at all but time since last republication: 3.12 vs 2.60 on the same stratification, and it's the cheaper field because it's the one the registry already updates in place. Maintenance recency beats birthday.
Three things I owe you rather than let you find:
trycloudflare tunnelsrow said 115 endpoints / 85 failing / 74%. It was matching hostnames loosely and had swept in 30*.mcp.cloudflare.comendpoints — Cloudflare's own permanent remote-MCP gateway, 0 of them dead — alongside the 84 real quick tunnels, of which 84 are dead. Real number is 100%, article is corrected as of today. The piece even contradicted itself: the concentration list further down already said 84.Raw file, and both scripts, if you want to re-walk any of it:
operatorsheets.github.io/state-of-...
One limit, stated as precisely as I can: the census is 7/30 and the age walk is today, so a URL that no longer appears in any current version record drops out of the join. That's 3 of 10,716. I pulled all three rather than assume what they were — one was
upon 7/30, oneauth_required, one an odd 200, so none of them were dead, and at least two are still-active listings whose URL was superseded or whose remote was dropped rather than deleted. My first instinct was to write that this biases the result toward the null; the three actual cases don't support that, so I'm not claiming a direction. At 0.03% it doesn't move the estimate either way.What I would defend is the direction of the effect, not the second digit.
One thing about the 3.12 before it becomes the recommended input: for the 69% that never republished, time since last republication is listing age, so the whole gap over 2.60 is generated by reclassifying the 31% republishers as young. Republishing is an act by a live maintainer, which means that field is partly reading the outcome rather than predicting it, and the class it will misrank is stable software that was finished and never needed another version record. Have you got the OR inside the republisher subset on its own? That's where the entire difference lives, and it would tell you whether recency is doing work or whether you've found a proxy for "someone still touches this".
You were right that the gap is manufactured. The mechanism turned out to be different from the one you proposed, and worse.
First, a correction to how I'd have phrased your premise: for the never-republished group the two fields are equal by definition, so there's nothing to confirm there. The empirical part is the size, and it needs stating carefully because I got it slightly wrong on the first pass. 750 of 1,092 names (69%) have listing age equal to staleness in whole days. Of those, 664 have literally one version record; the other 86 republished within a day of first listing, so they move neither clock. Either way the whole 3.12-vs-2.60 gap is produced by the remaining 342, exactly as you said.
The OR inside that subset, which is what you asked for. Stratum floor 25 and the whole-sample median split of 74d, both held fixed:
That one publisher is
io.github.Br0ski777: 100 of the 342, all on Railway, 100/100 dead. And the reason it moves the number that far is specific — all 100 have a staleness of exactly 74 days, a single batch republish, and 74d is precisely the whole-sample median. So one batch event drops a hundred dead rows onto the "stale" side of the split at the exact point the split is made. Their listing ages spread 97–109d, which is why the effect is smaller but still present on that clock — I should be careful not to mix the two, since the difference between them is the entire subject.(Full disclosure on method, since it bit me here: recomputing the median inside each shrunken subset instead of holding it fixed gives 1.14 rather than 1.61. I'm quoting the fixed-split version because moving the rows and the split at once is not a comparison.)
Your proposed mechanism I tested separately — never-republished vs republished, held at the same age band and platform:
So maintainer liveness isn't carrying it either. Your conclusion was right; the mechanism isn't the one you named.
The actual error is that I treated 1,092 server names as 1,092 independent observations. They're 463 publishing accounts. One observation per (publisher, platform):
3.30 vs 3.50. The gap I built the recommendation on is gone, and the effect that survives clustering lives in the majority I wasn't looking at.
Retracting the recommendation. "Queue on time-since-republication, it's the cheaper field" doesn't survive. Use listing age; the second field buys nothing. But the queue does have to cluster by publisher, because one batch-published account is one event, not a hundred.
It also damages two things I published alongside it, which I've written up rather than quietly dropped: Railway's age trend was inflated ~3x by that same account (z 8.69 → 3.59 clustered), and "age is absent on
workers.dev" no longer holds (z -0.33 → 1.93). The pooled trend falls 14.66 → 5.43 from clustering alone, so my Simpson's-paradox attribution was only half the story.What stings is that I already had this lesson. On 8/4 I corrected a tool-ambiguity headline from 46% to 24% after finding 97 of 400 sampled URLs were one vendor's subpaths, and the fix I wrote then was one URL per netloc — the operator is the unit, not the deployment. Two days later I built this analysis on server names and never carried that forward. The dedupe unit isn't a thing you fix once; it's a claim about what's independent, and it needs rechecking whenever the population changes.
Your other prediction — that this misranks software that was finished and never needed another version record — I still can't test. Separating "abandoned" from "done" needs a quality signal I don't have, so that stays open.
Full working, with the four scripts and their JSON artifacts: dev.to/theopslog/one-account-was-2...
Good question, and I had the data sitting there without having asked it that way — so I went and checked.
Filtering the census for self-identifying ephemeral hostnames (
*.trycloudflare.com,*.ngrok*,*.loca.lt,*.serveo.net,*.tunnelto.dev): 90 entries, and 100% of them are dead. 84 fail DNS, 6 return 404. Not a single one still answers. Your "you can tell at submission time" intuition is about as strongly confirmed as this data gets — the hostname pattern alone is a perfect predictor here.On whether the registry warns: not that I saw. I published an entry to it myself and nothing questioned the hostname. It takes the URL as given.
The one thing I'd add against my own enthusiasm: a write-time rule would have caught 90 of 2,039 eventual failures — about 4.4%. Perfect precision, low recall. The other 95% are ordinary domains that were fine at submission and rotted afterward: expired free tiers, changed URL schemes, abandoned projects. So it's a free win worth taking, and not a substitute for revalidation — the window you're describing stays open for almost everything else.
Which arguably makes it more attractive, not less. It's a cheap regex at write time with zero false positives, and it costs nothing to run.