One gateway was 24% of my sample and I published anyway

Eleven days ago I published a piece saying MCP server uptime is bimodal: of 400 registry servers probed daily, 78.2% never missed a day and 5.5% never answered once.

Both numbers are arithmetically correct and one of them is misleading, because 97 of those 400 "servers" are 97 URL paths on a single gateway — gateway.pipeworx.io.

I would like to tell you I did not know. Three days before that post, on 2026-08-24, I appended a published correction to four earlier articles for this exact defect, naming this exact gateway. They are still there, at the top of each piece. Then I wrote a new article, from the same cohort, and did not apply the correction I had just spent a day writing.

So this post is that correction, applied late — plus the thing it turned up that I did not expect.

What the cohort actually is

The fixed cohort is 400 endpoints from the official MCP registry, frozen 2026-07-30, probed every day since. Counted as endpoints it is 400. Counted by the domain that operates them:

unit	count
endpoints	400
distinct hosts	284
distinct operators	242
endpoints on gateway.pipeworx.io	97 (24.2%)
top-5 operators	133 (33.2%)
top-10 operators	157 (39.2%)

One operator is a quarter of the sample. The top ten are two fifths of it.

Restating the published numbers

Same 23-day window (2026-08-04 → 08-27), same method, one column added:

	as published (400 endpoints)	excluding the one gateway (303)
never missed a day	313 — 78.2%	223 — 73.6%
never answered once	22 — 5.5%	22 — 7.3%
partial (the tail)	65 — 16.2%	58 — 19.1%
mean daily uptime	92.0%	89.6%

90 of the 313 servers in the "never missed a day" block — 28.8% of it — are that one gateway. Seven of its 97 paths missed the bar and 90 cleared it: two were down on 08-05, one on 08-08, and four on 08-27. On every other day of the window it answered 97 of 97. The direction of the error is the one my own audit predicted in advance: a large, perfectly reliable operator inflates the healthy denominator, so I was overstating reliability, by 4.6 points on the headline figure and 2.4 on the daily average.

The bimodal shape survives all of this. The level does not.

The part I did not predict: the aggregate now has weather

My internal audit closed the concentration question with this sentence: "It never fails, so it does not inflate a failure count — it inflates the healthy denominator." That was the load-bearing premise: it made the direction of the bias knowable in advance, which is the only reason a correction could be issued without re-running everything.

It was already wrong three days later — four of the gateway's paths went down on 08-27 — and it broke properly on 09-05.

Daily uptime of the cohort, split:

date	whole cohort	the gateway (97)	everyone else (303)
2026-09-02	89.5%	95.9%	87.5%
2026-09-03	89.5%	95.9%	87.5%
2026-09-05	75.8%	60.8%	80.5%
2026-09-06	89.8%	95.9%	87.8%
2026-09-07	77.8%	48.5%	87.1%

Look at 2026-09-07. The population number falls 12.0 points overnight. The other 303 servers move by 0.7 points — 37 down the day before, 39 down that day. Every bit of the drop is one operator: 30 timeouts and 20 HTTP 503s on the gateway.

Give every operator one vote instead of every endpoint one vote — the mean of the per-operator uptime rates, 242 operators — and the same two days read completely differently:

date	per-endpoint	per-operator
2026-09-03	89.5%	86.8%
2026-09-05	75.8%	80.3%
2026-09-06	89.8%	87.5%
2026-09-07	77.8%	86.9%

A 12.0-point per-endpoint fall is a 0.6-point per-operator fall. If you are tracking "MCP health" as a time series built from endpoint counts, a chunk of your variance is one company's afternoon.

Note that 09-05 and 09-07 are not the same event. On 09-05 the tail moved too (80.5% against a baseline of ~87.5%), so per-operator uptime genuinely dipped, by 7.2 points. On 09-07 only the gateway moved. Two superficially identical dips in the headline, two different underlying facts — which is the whole argument for not reading the headline.

Was it my network? No, and the data can rule it out rather than my assurances. Median latency of successful responses on 09-07: the gateway 13,272 ms, everyone else 965 ms. On a normal day the gateway is the fast one — 216 ms on 09-03 against 688 ms for the rest. It was struggling even where it answered. The contrast case is 2026-08-25, when the gateway ran 3,943 ms and everyone else ran 5,203 ms — both elevated together. That day was my end. 09-07 was not.

The out-of-sample test, which is why the correction matters

Fixing the concentration made the original finding stronger, not weaker, and I only found that because I had to redo the analysis.

The 8/27 article sorted all 400 into three groups using 8/04–8/27. The eleven days since are a holdout the classification never saw. 8 of those 11 days are usable; 08-29, 08-30 and 09-04 are excluded because the probe self-reported complete: false and returned no scores. They are not zeros, they are absent.

Percentage of each group that had zero down-days in the holdout:

group (assigned 8/04–8/27)	n	clean in holdout	n excl. gateway	clean, excl. gateway
never missed a day	313	72.8%	223	90.6%
the partial tail	65	55.4%	58	58.6%
never answered	22	0.0%	22	0.0%

Mean down-days out of 8, all three on the de-concentrated populations so they are comparable: 0.15 for the reliable block (223), 1.88 for the tail (58), 7.95 for the dead block (22). Pooled over all 400 the first two are 0.36 and 2.18; the dead block is 7.95 either way, because none of its members is on the gateway.

Two things fall out.

The classification predicts. A server that was perfect for 23 days stayed perfect through the next 8 about nine times in ten. Not one of the 22 that never answered in the training window answered in the holdout either — 0 of 22, averaging 7.95 down-days out of 8. Dead is not a phase.

The concentration was hiding that. Pooled over all 400, the reliable block looks 72.8% predictive. Remove the gateway and it is 90.6%. The reliable block took 113 down-observations across the holdout, and 79 of them — 69.9% — came from the 90 gateway endpoints that are 28.8% of its membership. They are not 79 independent failures. They are one gateway shedding a rotating subset of its own paths on two afternoons: of its 90 members, 26 stayed clean, 49 went down on one day and 15 on two — 33 failed on 09-05, 46 on 09-07, and only 15 on both. Concentration did not just bias the level; it made a genuinely sharp classifier look mushy.

What I would do differently, stated as a rule

Report per-endpoint and per-operator side by side, always. Not per-operator instead — per-endpoint is the right number if you are asking "will a URL I picked answer." Per-operator is the right number if you are asking "is the ecosystem healthy," and the gap between them is itself the interesting figure.

Concentration has broken results here before, and the list is specific. 2026-08-04: an article corrected after 173 of the servers it flagged — 56% — turned out to be one operator counted many times. 2026-08-06: a recommendation retracted outright, because one publishing account was 100 of 342 republishers. 2026-08-24: four more articles corrected, including a coverage figure wrong by about 1.5×. 2026-08-27: the piece this post is about — written three days after that batch shipped, from the same cohort, with the same defect.

The pattern in that list is not that I failed to learn the lesson. It is that I kept learning it afterwards, one article at a time, because the check lived in my judgement instead of in the pipeline. So it is now a step in the script that produces the numbers: every rate comes out of the analysis with its per-operator twin attached, and if the two disagree by more than a point the script says so before I get to write a sentence about either.

Method and limits

• 400 endpoints, frozen 2026-07-30 from the official MCP registry, anonymous initialize + tools/list once daily. answered is a boolean on a completed handshake.
• The cohort is the servers that answered on 07-30. It is not a random sample of the registry and it is not the registry today — 16,627 entries as of this run.
• Excluded runs: 08-02 and 08-03 (no answered field yet), 08-09 (0/400 — the probe failed, not 400 servers), 08-29, 08-30, 09-04 (complete: false). Nothing else was dropped.
• "Operator" is eTLD+1 by a short hand-kept suffix list, with shared platforms (*.workers.dev, *.railway.app, *.vercel.app and similar) collapsed to the platform. That is right for availability correlation — tenants of one platform fail together — and wrong if you consider two unrelated Workers apps independent. It moves the gateway figure not at all: that is one host, one domain, 97 paths. It does move the concentration table's other two rows, and I would rather show that than reassure you about the one number that happens to be invariant — treat each platform as a public suffix instead, so every tenant is its own operator, and the cohort becomes 266 operators with top-5 124 (31.0%) and top-10 140 (35.0%) against the 133 (33.2%) and 157 (39.2%) above. The argument of this post does not turn on that choice; the smaller rows of that table do. The grouping is in tools/dual_rate.py in the linked repo, with its own self-test, and every rate in this post came out of it rather than out of a one-off script. Two counts I got wrong on the first pass and it caught: a naive last-two-labels rule merged two unrelated Australian companies into a single com.au "operator", giving 241 operators instead of 242 and shifting the 09-07 per-operator rate by 0.2 points.
• 8 holdout days is not many. The 0-of-22 result is the robust one; the 90.6% has real error bars around it.

Raw snapshots and the scripts are in github.com/operatorsheets/mcp-observatory; the running series is at operatorsheets.github.io/state-of-mcp.

Written with AI assistance; every figure in this post was computed from the raw snapshots on disk and is reproducible from the linked repository.