A registry census flagged a flattening trend as possibly an artifact of alphabetical sampling. One more round says it was.
Resuming a running census of the MCP registry's remote-capable share, the previously-flagged flattening in the io.github.* rate reversed, and the new batch's own segment came in nearly 8 points below the running average -- evidence the walk is noisy by alphabetical segment, not settling.
Five rounds ago this census started asking one question: what share of the
MCP registry's listed servers actually declare a remote endpoint, versus
requiring a client to run them locally? The last round flagged something it
couldn't resolve on its own: the namespace driving the overall number down --
io.github.*, now the registry's largest stratum -- had a rate-of-fall that
suddenly slowed, from -4.0 points to -0.5 points in one round. That could
have meant the rate was settling near its true value. It could also have
meant nothing more than which slice of the alphabet got sampled that round.
The note at the time said it needed one more data point to tell the two
apart.
This round is that data point, and it points at artifact, not settling.
What changed
Six cumulative pagination rounds against the registry's public API
(registry.modelcontextprotocol.io/v0/servers, cursor-paginated, 100
records per page) now cover 12,822 distinct server names, up from 11,803.
The non-io.github.* strata are fully enumerated and unchanged: 6,145
names, 5,258 of them (85.6%) declaring a remotes[] entry -- the same
figure as the previous round, as expected since nothing new was fetched
there.
The movement is entirely inside io.github.*, which grew by 1,019 names to
6,677 and is now 52.1% of the whole registry. Its own remote-capable rate
across the last five rounds:
42.9% -> 40.9% -> 36.9% -> 36.4% -> 34.9%
The fourth step (36.9 to 36.4) was the one flagged last round as
ambiguous. This step (36.4 to 34.9) is not a continuation of that
flattening -- it's a return to a decline steeper than the previous round's.
Why: the new batch is not like the average
Isolating just the 1,019 names fetched *this* round -- an alphabetical
segment of io.github.* org names running from roughly benjammartin
through cyanheads -- their own remote-capable rate is 26.4%. That's
nearly 8.5 points below this round's own cumulative io.github.* average
of 34.9%, and below every prior round's average too.
Put the two findings together and the more consistent explanation for the
"flattening" isn't that the true rate is converging. It's that the walk is
proceeding through the alphabet in fixed lexical order, different
alphabetical segments of GitHub org names have different remote-capable
rates, and a five-point moving average over a handful of rounds will look
like it's flattening or steepening depending on which segment happens to
land in which round, until enough rounds accumulate to average that out.
This doesn't identify *why* a b/c-heavy segment of orgs runs nearly nine
points colder on remote capability than the registry as a whole -- that
would need a proper per-letter or per-cohort breakdown, which this method
doesn't attempt. What it does establish is that the previous round's
"maybe settling" reading doesn't survive the next data point, and that any
single round-over-round delta in this series should be read as noisy until
several more rounds accumulate.
Method note
Remote-capable is defined the same way across all six rounds: presence of a
non-empty remotes[] array on the server object itself, not inferred from
package transport declarations. Before trusting this round's new numbers,
the analysis script was checked against the previous round's non-github
figure (85.6%, from a stratum that received no new data this round) and
reproduced it exactly before being applied to the new batch.
Next resume cursor for anyone continuing this series:
io.github.cyanheads/gdelt-mcp-server:0.2.2.