How an MCP registry changes in a week: 5,161 new servers, 12,973 new versions, 75 removed

If you build on the official MCP registry, the listing you read today is not the listing you will read next week. I run ProtocolProbe, a directory with a page for every server in that registry. Every day a job pulls the whole registry, compares it with the last snapshot it loaded, and records what changed. This post is the first eight days of that record, 2026-10-23 to 2026-10-31.

Nothing here required calling a single server's tools. It is the registry's own list API, compared with itself.

How the numbers were made

• One snapshot of the registry's latest entries per day, pulled at a different time of day (between 01:38 and 16:43 UTC). A "day" is the gap between two pulls, not midnight to midnight.
• Each snapshot is compared with the previous one the job loaded. That gives seven comparisons covering eight days: the run of 2026-10-25 did not load, so the comparison dated 10-26 covers two days.
• A server counts as new if its name was not in the previous snapshot, removed if it was and is gone, and as having a new version if its latest version differs from the previous snapshot. If a server published three releases between two pulls, that is one row, not three. All version counts below are therefore "at least".
• A status change is a change of status on an entry whose version did not change.

The week in one table

The arithmetic closes, and it closes on the first day too (48,551 + 928 - 34 = 49,445, the 10-24 pull). The 2026-10-23 snapshot held 48,551 latest entries. Add 5,161 new, take away 75 removed, and you get 53,637, which is exactly what the 2026-10-31 pull counted. That is +10.5% in eight days. The registry's table of every version of every server, including old ones, went from 170,076 rows to 198,499, which is +28,423 or +16.7%.

No entry returned after being removed in any comparison.

New servers: 5,161 of them, from 3,677 publishers

I use the part of the name before the slash as the publisher, for example io.github.<account> or a reversed domain.

• 2,249 of the 5,161 new servers (43.6%) are under io.github.*.
• The six publishers with the most new servers account for 753, which is 14.6%. The rest is a long tail: 3,677 distinct publishers for 5,161 servers.
• 839 of the new servers (16.3%) also published a newer latest version before the window ended.
• 14 appeared already marked deprecated.

Updates: 6,630 servers, and two publishers make up 46% of the rows

12,973 rows is not 12,973 servers. 6,630 distinct servers from 3,205 publishers had a new latest version at least once, and they did so on a different number of days:

Direction: 12,958 rows went to a newer version, 2 went to an older one, and 13 could not be ordered.

The long right end of the table is one publisher. 341 of the 408 servers that changed on six or seven of the seven comparisons belong to a single publisher, and two publishers together account for 6,006 of the 12,973 rows, 46.3%. Without them there are 6,967 rows across 4,320 servers. If you count owners rather than entries, the picture is a few automated release streams on top of a wide base of occasional updates.

A new version number tells you a publisher published. It does not tell you what changed, and this comparison cannot see inside a release.

Removals: 75, from 66 publishers

Six of the 75 had been first listed inside the same window. The registry's list stops returning a removed name, so what we record is "listed on one date, not listed on the next".

Status: 207 servers moved to deprecated, 137 of them in one day

All 207 status changes in the week were active to deprecated. None went the other way. They came from 59 publishers.

The shape is uneven: 4 to 19 a day, then 144 on 10-31. 137 of those 144 belong to one publisher, so that day is one publisher's decision, not a trend.

We also know these status changes only because of a gap we closed during this week. Until 2026-10-29, a change of status at the same version was counted in the daily summary and never written back to our stored record, so the entry kept showing as active. A full comparison on 2026-10-28 found 53 such records. Since then, every status change is reconciled into the stored record the same day.

What this means if you depend on the registry

• Poll more often than the changes arrive. Averaged over the eight days, roughly 1,600 entries a day got a new latest version and roughly 650 servers a day were added. The registry's list API supports an updated_since filter, so you can ask for only what changed.
• Watch status as well as version. A deprecation at the same version produces no new version. If you only watch versions, you will not see it.
• Treat a listing as a dated fact. An entry that was current on Monday can be deprecated on Tuesday, and no one re-checks it unless someone does.
• Pin by exact version if you can. The latest version of a large share of the registry moved in eight days.

What I did not check

• What changed inside the updates. A new version could be a one-line fix or a rewrite; this comparison sees only the registry's own fields.
• Whether the 5,161 new servers work. Nothing was started and no tool was called.
• Why the 137 deprecations on 10-31 happened. I read the status, not the publisher's reason.
• Anything outside these eight days. A week with different release habits would show different shares.

See it yourself

The daily record is public: protocolprobe.com/mcp/changes lists each day's new, removed and changed servers, there is an Atom feed, and the same data is available through the site's API. If your own count of a day disagrees with mine, tell me which day and what you got, and I will re-run that comparison.