DEV Community: md sultan mahamud

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

md sultan mahamud — Sat, 31 Oct 2026 20:23:34 +0000

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

Day	Compared with	New	New version	Removed	Status changed
10-24	10-23	928	1,906	34	13
10-26	10-24 (two days)	1,014	2,010	6	19
10-27	10-26	724	1,601	9	10
10-28	10-27	671	1,159	5	11
10-29	10-28	307	1,258	3	6
10-30	10-29	962	3,448	10	4
10-31	10-30	555	1,591	8	144
Total		5,161	12,973	75	207

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:

Comparisons with a new version (of 7)	Servers
1	3,521
2	1,649
3	685
4	209
5	158
6	383
7	25

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.

Run security checks against your own MCP server in CI, and see the findings in GitHub

md sultan mahamud — Fri, 30 Oct 2026 15:04:27 +0000

Most MCP security tooling reads a server's tool descriptions. That finds text that looks suspicious. It does not tell you what your server does when a client calls it.

This post is about a small command-line tool that does the second thing, for a server you run: it starts your server, connects as an MCP client, calls it, and reports what it observed. It is called protocolprobe-selftest, it is ISC-licensed, and the source is public: protocolprobe/protocolprobe-tools.

I build ProtocolProbe, a directory of dated facts about the servers in the official MCP registry. This tool is the part that runs on your machine, not ours. We use it on nobody else's server: you point it at your own, and the results stay on your computer.

Run it once

npx protocolprobe-selftest --i-own-this-server --stdio node ./dist/server.js

Everything after --stdio is your server's own command line, so a Python server works the same way (needs uv):

npx protocolprobe-selftest --i-own-this-server --stdio uv run --directory . server.py

The server is started in a temporary folder, so keep --directory . with uv run; a plain uv run server.py will not find your project.

--i-own-this-server is required on every run. It is a statement, not a technicality: the tool is for servers you own or are authorised to test.

What the output looks like

The result is a count over the checks that actually ran, with the rest listed, for example "N of M checks passed". Two rules are deliberate:

No letter grade, no weighting. A single grade hides which check failed and why.
Checks that could not run are listed, never counted as passed. If a check does not apply to your setup, or could not be tested, the output says so. A result where some checks did not run is marked partial.

Two of the checks are off unless you turn them on, because they are the kind that change data or send malformed input to your server:

npx protocolprobe-selftest --i-own-this-server --allow-mutating --allow-fuzzing --out report.json --stdio node ./dist/server.js

Use those against a development copy, not against a server holding data you care about.

Put it in CI

npx protocolprobe-selftest --i-own-this-server --fail-on-finding --sarif selftest.sarif --stdio node ./dist/server.js

--fail-on-finding makes the job exit with code 5 when a check needs attention (VULNERABLE or FOUND). Without it the exit code is 0 whatever the result.
--sarif <file> also writes the result as SARIF 2.1.0, which GitHub code scanning reads.

Only checks that need attention become SARIF results: VULNERABLE is an error, FOUND is a warning (a heuristic match for you to review). The score and the list of what did not run are kept in runs[0].properties.

A finding here is about the running server, not a line of code, so every result points at line 1 of one file. --sarif-anchor <file> picks that file; by default it is the first file in your --stdio command that is inside the current folder. With neither, the SARIF is valid but GitHub does not display the results, so run the command from your repository root.

One thing that is easy to get wrong in GitHub Actions: a step that exits 5 stops the steps after it. Give the upload step if: always(), or the SARIF is not uploaded in exactly the case where there are findings.

A workflow of that shape looks like this (adapt the build and server command to your project):

name: mcp-selftest
on: [push, pull_request]

jobs:
  selftest:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci && npm run build
      - run: npx protocolprobe-selftest --i-own-this-server --fail-on-finding --sarif selftest.sarif --stdio node ./dist/server.js
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: selftest.sarif

I have not run this exact workflow end to end for this post; the command line and the exit-code behaviour are from the tool's tests and documentation. If your first run behaves differently, open an issue with the tool version, your Node version and what you ran.

A server that is already deployed

From version 0.2.0 the tool can test your own Streamable HTTP server at a URL, but only after the server proves you control that exact URL:

Run the command with --url. It connects to nothing, prints a line such as protocolprobe-proof=pp1-..., and exits with code 3.
Put that line, on a line of its own, into your MCP server's instructions text and deploy.
Run the same command again within 30 minutes. It reads the instructions, and if the line is there it runs the checks on that same connection. The value is then used up.

The rules are enforced and tested: the value works once, only for the exact URL it was made for, expires after 30 minutes, and no redirect is followed. If your server needs a credential, you pass it through an environment variable (--bearer-env), never on the command line, and it is only sent to the proven URL and replaced with [redacted] in everything the tool prints or writes.

Be clear about what this proof is. It stops accidents and casual misuse: nobody can make someone else's server return a fresh random value. It is not enforcement. The tool is open source and could be changed to skip it, and other tools connect to any URL with no proof at all. Use --url only for a server you operate or are authorised to test.

What it cannot tell you

These limits are in the README too, and they matter more than the feature list:

Over HTTP, fewer checks apply. Two checks (a secret leaking into output, and a leak into logs) look for a fake secret planted in the process the tool starts, so they are marked not applicable when your server is at a URL. They are listed, not counted.
Through a proxy, the same two are lost. If you start your server via a stdio-to-HTTP proxy (mcp-remote for example), the process under test is the proxy. The tool recognises a short list of common proxies; a proxy not on the list, or a wrapper script around one, is not detected, and those two checks can then come out clean without meaning anything. A server inside a container or virtual machine is the same case, and that case was not tested.
A clean result is not a certificate. It means these checks did not find a problem in this run, against this server, in this configuration.

Why a runtime check at all

When I ran the same battery against five widely used reference MCP servers, the one result that repeated everywhere was this: on every server that had a tool that changes data, the tool ran in a millisecond or two, with no error and no confirmation step. That is how the protocol is designed, and many clients ask the human for confirmation. But if your server is reached by a client that does not, nothing in the server stops it. That is a fact about behaviour, and it only shows up if you call the tool.

Try it, and tell me what is wrong

npx protocolprobe-selftest --i-own-this-server --stdio <your server command>

Source, issues and discussions: github.com/protocolprobe/protocolprobe-tools. If a check gives a wrong result on your server, that is the most useful bug report I can get.

"Our MCP directory said \"active\". The publisher had deprecated it five days earlier."

md sultan mahamud — Thu, 29 Oct 2026 13:41:18 +0000

I run ProtocolProbe, a directory of facts about every server in the official MCP Registry: each server gets a page, read from public records (the registry, npm, PyPI, GitHub), with a date on every fact.

A publisher emailed us. They had renamed their server, marked the old registry entry as deprecated, and added a message pointing to the new name. Our page for the old entry still said active.

I told them it would update on our next daily run. That was wrong. This post is about why, and what we changed.

The bug

Our daily job pulls the full registry list, compares it with yesterday's, and loads what changed: new servers, new versions, removed servers. For those, it re-reads the package and repository facts the same day.

The publisher's change was none of those. The registry lets a publisher change an entry's status (active → deprecated) and its status message without publishing a new version. Same version, different status.

Our job noticed it: it counted it as a "metadata-only" change. It just never loaded it. The page kept the old status, and the run still finished with ok.

How big was it?

One report can be a coincidence, so we compared every stored record with the registry list of that day, field by field (read-only, 51,834 servers):

	mismatches
servers missing / extra	0 / 0
version	0
status (stored `active`, registry `deprecated`)	53
status message	60

So the parts the job was built for were exact, and the gap was precisely the case it skipped: entries deprecated by their publishers that we still showed as active. Our own record check "deprecated in the registry" gave the wrong answer for all of them.

Fix 1: reconcile what the registry owns, every day

The registry is the source of truth for a few fields: status, status message, published and updated dates. Now, after every daily load, the job compares those fields for all servers with the registry list and patches the ones that differ at the same version:

a backup of every value before the first write, and a journal, so a crash mid-way resumes instead of half-patching;
every patched document read back; a mismatch rolls the whole step back;
a cap of 2,000 patches a day (a registry-wide change needs a person to look);
each change recorded publicly with its date, so anyone can see what changed and when.

First run: 59 servers patched (some had changed since the count above). A second comparison right after: 0 mismatches across 52,138 servers.

Fix 2: a job that says "ok" must check the page

The deeper problem was not the missing field. It was that the job reported success without looking at what visitors see.

So the job now ends with a live check: after the pages are refreshed, it takes a small fixed sample of the day's changed servers (new, new version, status patched) and opens their public pages.

We first tried reading our own public API instead. It was the wrong thing to check, for two reasons we found by reading our code:

The API is not what was stale. The page was.
The API answer is cached at the CDN and inside each function instance, and the instance copy comes back without a cache header. A check right after a load can read an old copy and raise a false alarm.

Each server page now carries a small machine-readable marker in its head: version, status, a short hash of the status message (never the message itself), and the snapshot date. The job compares that with what it loaded.

A mismatch is a warning, never a rollback.
Our own failures (rate limits, timeouts) are "not checked", never a mismatch.
If half the sample can't be checked, that is a warning too.

Fix 3: a date range, not a date

While checking this, we found a quieter version of the same problem on our leaderboards. They said "facts checked 2026-10-29". That was the newest date among the records, which meant the servers that changed that day.

Most stars and download counts behind the ranking had been read days earlier. The page now shows the range: "facts checked 2026-10-24 to 2026-10-29".

How stale does a directory get?

We measured it. We re-read the free facts (npm/PyPI, OSV, GitHub) of 1,729 servers that had not changed in the registry, a 1/30 slice of the catalogue. It took about 14 minutes and about 1,200 GitHub API requests.

614 of them (35%) had at least one fact that had changed since our last read:

396 download counts
301 last-push dates
99 star counts
23 version-pin states
7 repository states (not found, found again, archived)
1 newly withdrawn package

None of these show up as a registry change. We built a daily rotation that re-reads such a slice every day, so every server is re-read at least monthly. It is switched off until we have watched a few normal runs of the new checks.

What I'd tell anyone building on a registry

A listing is a snapshot. The official MCP Registry checks an entry when it is published (each new version), and nothing re-checks it on a schedule. We asked for that upstream: registry issue #1715. If you mirror it, you inherit the same gap.
Same version doesn't mean same record. Compare the fields the source owns, not just the version.
Check the output, not the exit code. Our job said ok for days while pages were wrong.
Show the age of your data honestly. A single date can quietly overstate how fresh it is.
Say when you were wrong. I told the publisher the wrong thing first. Admitting it took one email. Our corrections are logged at protocolprobe.com/corrections.

Every change the job records is public, by day, at protocolprobe.com/mcp/changes, and in a free API with no key (/docs/api). If you run an MCP server and something on its page looks wrong, /operators says how to tell us.

"Your MCP server's tool list can be refused before the model sees it: the rules three AI APIs applied to 21,812 lists"

md sultan mahamud — Wed, 28 Oct 2026 19:32:30 +0000

We read the tool lists of MCP servers in the official MCP registry. Then we sent each list, once, to three small AI models through their vendors' Batch APIs: Claude Haiku 5.5, GPT-5-nano and Gemini 2.5 Flash. Each model was set to its lowest reasoning level and got one fixed request. That was 21,812 tool lists, one per server, with answers dated 2026-10-25 to 2026-10-26 (UTC).

No MCP server was contacted and no tool was run. We sent only the tool names, descriptions and input schemas, exactly as each server publishes them.

The finding most useful to server authors: each API checks the tool list before its model sees it, and each API has its own rules. The same list can be accepted by one API and refused by another. A refusal is the API's answer about the list as written. It is not a fault in the server's code, but it does mean that client never offers your tools to the model.

What each API refused, in its own words

Counts are tool lists, one per server, from our run. An API can have other rules, and can change them.

Anthropic's API (456 lists refused)

Rule	API message	Lists
`oneOf` / `allOf` / `anyOf` at the top level of `input_schema`	`input_schema does not support oneOf, allOf, or anyOf at the top level`	267
Tool name outside `^[a-zA-Z0-9_-]{1,128}$`	`String should match pattern '^[a-zA-Z0-9_-]{1,128}$'`	173
Two tools with the same name	`Tool names must be unique.`	29
Schema not valid JSON Schema draft 2020-12	`JSON schema is invalid. It must match JSON Schema draft 2020-12 …`	6
Top-level property key outside `^[a-zA-Z0-9_.-]{1,64}$`	`Property keys should match pattern …`	4

OpenAI's API (591 lists refused)

Rule	API message	Lists
Top level not `type: object`, or has `oneOf`/`anyOf`/`allOf`/`enum`/`const`/`not`	`schema must have type 'object' and not have 'oneOf'/'anyOf'/'allOf'/'enum'/'const'/'not' at the top level.`	262
More than 128 tools	`Invalid 'tools': array too long. Expected an array with maximum length 128 …`	171
Tool name outside `^[a-zA-Z0-9_-]+$`	`string does not match pattern …`	167
A `pattern` it does not read as a regex (every case used `\p{…}` Unicode classes)	`'^[\\p{L}\\p{N}_-]+$' is not a 'regex'`	19
A number in the schema too large	`a numeric value in the function parameters is too large`	4
List longer than the input limit	`Input tokens exceed the configured limit of 272000 tokens.`	3

The 128-tool limit is not stated on the chat completions API reference page we read on 2026-10-25. The refused lists ranged from 129 to 1,711 tools.

Google's API (7 lists refused, plus 135 unexplained)

Rule	API message	Lists
Tool name starts with a digit, or has a space, braces or square brackets	`Invalid function name. Must start with a letter or an underscore. …`	7

For 4 of those 7 lists, the names started with a digit. That meets the docs text we read, which gives no rule for the first character, but the API still refused them. Google's API also answered Request contains an invalid argument. for 135 more lists without naming a rule. Of those 135, 34 had tuple-style items (an array of schemas) and 30 had two tools with the same name. No list that Google's API answered had either. That is an association we measured, not a reason Google gave.

A checklist for MCP server authors

From the rules above, a tool list is accepted by all three APIs in our run more often when:

Tool names use only a-z A-Z 0-9 _ -, start with a letter, and stay at 64 characters or fewer.
Every tool name in the list is unique.
Each inputSchema is type: "object" at the top level, with no oneOf/anyOf/allOf/enum/const/not there.
pattern values avoid \p{…} Unicode classes.
Arrays use a single schema in items, not a tuple.
The server exposes 128 tools or fewer.

What these figures do not mean

They describe three small models on the dates shown, each at its lowest reasoning setting. They do not describe the vendors' other models or a real client with its own system prompt. They are not a judgment of any server or publisher. We do not rank the models. Each model's own figures are on the full page, and each server's own API message is on its server page.

850 MCP servers describe a tool that moves money. Here is what the tool lists say.

md sultan mahamud — Wed, 28 Oct 2026 18:02:29 +0000

Most people ask whether an MCP server is popular. Fewer ask what its tools are allowed to do once an agent connects.

I read the tool list of every MCP server I could open in the official registry, and counted what the tool descriptions say each tool does. No tool was called, anywhere.

The numbers

Registry list of 2026-10-27: 51,168 servers. I opened a live, read-only session with 25,335 of them and read the tool lists of 23,655 servers (385,096 tools).

A server is counted under every kind it has a tool of, so the rows overlap and do not add up to 23,655.

What a tool's description says it does	Servers
reads or searches	20,019
creates or changes data	6,437
sends messages	2,696
runs code or commands	1,540
moves money (payment or financial)	850
controls a browser or desktop	481
manages infrastructure	125

Looking at what each server mainly works on instead: 8,710 only answer questions and touch nothing outside themselves, 4,072 work on accounts and data in outside web services, 1,978 on files and code on the machine they run on, and 756 on money, payments or trading.

How to read these numbers

These are an AI model's reading of each tool description, not a test. Two differently worded runs had to agree on a label, otherwise it was left out. Nobody checked the labels by hand. On my own spot checks the tool kind agreed 93.8% of the time between the two runs.
A description is a claim by the publisher. "Moves money" means the description says so. It does not mean the tool works, or that it is safe or unsafe.
I called no tool. Not one. Connecting only lists what the server offers.
Not every server could be read. 25,833 of the 51,168 were not opened: 15,434 by the server's own choice (it needs a key or sign-in), 1,799 because of a defect in the package, 2,117 because of my own limits, 6,483 for a cause I could not determine. These counts say nothing about them.

Why this matters if you build agents

An agent with a payments tool and a "send message" tool in one session is a different risk from one that only searches. The registry's required fields are a name, a description and a version, so a listing alone does not tell you which of these a server has. Reading the tool list does.

A practical use: before you add a server to an agent, look up which kinds of tool it has, and give the agent only what the task needs.

Browse it yourself

Each list opens the servers with that kind of tool, each with its source and the date it was read:

Method and corrections: protocolprobe.com/methodology and protocolprobe.com/corrections. The same data is in a free API (no key) and a citable dataset: protocolprobe.com/docs/cite.

I built ProtocolProbe. If a label looks wrong to you, tell me in the comments and I will check it.

What the official MCP registry looks like when you check it twice

md sultan mahamud — Sun, 25 Oct 2026 21:14:30 +0000

I run ProtocolProbe, a free site that records dated facts about every server in the official MCP registry. We pulled the whole registry on 2026-10-04 and again on 2026-10-23, and we have pulled it daily since. This post is about what changed, what the registry itself checks and when, and how to reproduce the counts yourself. No server's tools were called to get any of it: everything below comes from the registry API, npm, PyPI, GitHub and OSV.

What changed in 19 days

2026-10-04: 38,977 latest entries. 2026-10-23: 48,551. (2026-10-24: 49,445.)
Between the two pulls: 9,803 new servers, 5,646 existing servers listing a newer version, and 229 servers no longer listed. The arithmetic closes: 38,977 + 9,803 − 229 = 48,551.
The registry gives no reason for a removal, so we do not guess one. Each removed server's page stays up, marked as removed.

The day-by-day record is at protocolprobe.com/mcp/changes.

What the registry checks, and when

This is from reading the registry's source (commit c384c4b, read on 2026-10-06), so treat it as a statement about that code, not about anyone's intent:

At publish time the validators fetch the exact listed npm or PyPI version and check the ownership token.
I found nothing that re-validates an entry after it is published. repository.url is checked with a regular expression only, and the schema requires only name, description and version, so an entry with no package and no remote is allowed.
On 2026-10-26 the registry's roadmap (docs/design/roadmap.md) has no re-validation item. It also says its own phase labels are out of date as of 2026-08-10.

I opened issue #1715 asking for periodic re-checks of published entries.

What a second look finds (dataset snapshot 2026-10-24)

What we counted	Number
Entries in the snapshot	49,445
Remote only / local package only / both / neither	30,185 / 16,395 / 2,348 / 517
Entries whose linked GitHub repository exists	29,039
Entries whose linked GitHub repository returns 404	4,622 (13.7% of the 33,661 that link one)
Entries with no GitHub link we could check	15,784
Entries marked deprecated in the registry	620

One earlier number from the 2026-10-04 snapshot, which we have not re-run on the newer one: of 14,431 npm and PyPI entries, 157 (1.09%) listed a package or version that cannot be installed because it does not exist on npm or PyPI.

What these numbers are not: a 404 can mean a deleted, private or moved repository, and we cannot tell which. A count of public records on a date is not a verdict on any server, and we do not rank or grade servers.

Reproduce the repository count

The dataset is CC BY 4.0, on Zenodo (the DOI of all versions leads to the newest), Hugging Face and Kaggle. Standard library only:

import csv, io, urllib.request, collections

url = "https://huggingface.co/datasets/sultan57/mcp-registry-facts/resolve/main/servers.csv"
rows = list(csv.DictReader(io.StringIO(urllib.request.urlopen(url).read().decode("utf-8"), newline="")))

c = collections.Counter(r["repository"] or "none" for r in rows)
linked = c["present"] + c["repo-not-found"]
print(len(rows), dict(c), f"{c['repo-not-found'] / linked:.1%} of {linked}")
# 49445 {'none': 15784, 'present': 29039, 'repo-not-found': 4622} 13.7% of 33661

I ran this on 2026-10-26 and got the output in the last comment. The CSV has 22 columns (hosting_type, lifecycle_status, license_class, maintenance and more); the full records are one JSON file per part, exactly as the public API serves them.

If you run an MCP server

There is a small command that runs ProtocolProbe's runtime checks against a server you run yourself, on your own machine: npx protocolprobe-selftest. It can fail a CI job (--fail-on-finding) and write SARIF (--sarif). It is separate from the data above, which never calls anyone's tools.

Corrections are welcome: protocolprobe.com/corrections lists the ones we have made.

The MCP registry checks a package at publish. Here's what drifts after that.

md sultan mahamud — Sat, 24 Oct 2026 00:32:10 +0000

When you install an MCP server from the official registry, you get exactly the package version the entry lists. The registry checks that version when the entry is published: it fetches it from npm or PyPI and confirms the package names the server.

I read the registry's source to see what happens after that. The package check runs again only when the publisher edits the entry. Nothing re-checks entries on a schedule. Repository links are checked against a URL pattern and never fetched.

That's a reasonable design for a young registry, and it isn't anyone's mistake. But it means entries can drift. So I checked the whole registry against npm, PyPI and GitHub and counted what no longer matches.

What I counted

Registry snapshot 2026-10-04: 38,977 servers (the latest version of each name). Lookups ran on 2026-10-06.

What	Count	Out of	Share
Repository link returns 404 (missing or private)	4,298	28,743 entries with a GitHub link	15.0%
Listed version is withdrawn upstream (npm deprecated / PyPI yanked)	663	14,431 npm/PyPI entries	4.6%
Linked repository is archived	309	24,256 reachable repos	1.3%
Listed package or version can't be installed at all	157	14,431 npm/PyPI entries	1.1%
Active, but no package, no remote and no website	216	38,977	0.6%

Together, at least 5,192 of 38,977 entries (13.3%), more than 1 in 8, had at least one of these.

A few notes on reading this:

The 157 are the clearest case of drift. All of them were published after the registry's version check existed. If validation was on (it is by default), each one passed an exact-version check and the package or version disappeared later.
Withdrawn doesn't mean malicious. I classified the publishers' own deprecation messages. Most are renames, moved distributions and discontinued packages. A few say the backing service shut down, and 12 publishers cite a security issue. A registry-driven install still gets the withdrawn version, with no warning.
A 404 can be a renamed or private repo. I don't tell those apart.

The fix is now being tracked

I opened a feature request on the registry, modelcontextprotocol/registry#1715. It asks to re-run the existing checks on a schedule and record the result (for example lastVerifiedAt plus a status) instead of deleting anything.

On 2026-10-23, a member of the MCP organization consolidated the older re-validation request (#93) and five endpoint-health reports into that issue, so periodic re-validation now has one implementation tracker. The direction in the thread: dated results, explicit "auth-required / transient / unknown" states, and no removal on a single failed check.

That last point matters. A missing repo or a yanked version is a fact a client should see. It shouldn't silently turn into a takedown.

What this doesn't say

Nothing here says whether any server is safe or unsafe. I didn't run or call any server's tools. Everything comes from the registry and public package records.
The numbers are a dated snapshot. The registry has grown since then, and I haven't recounted these figures.

If you publish an MCP server

Five minutes of housekeeping:

Open your registry entry's repository.url. Does it still load?
Is the version you list still published, and not deprecated or yanked?
If you renamed or moved the package, publish an update that points to the new one.

Full tables, with each figure's source and date: https://protocolprobe.com/mcp/reports/registry-vs-reality
Dataset (CC BY 4.0, citable): https://doi.org/10.5281/zenodo.23386799

Disclosure: I built ProtocolProbe, a free directory that reads the registry's public data. Corrections welcome: hello@protocolprobe.com.

We re-checked 38,977 MCP registry entries against npm, PyPI and GitHub: 4,298 repository links no longer open.

md sultan mahamud — Sat, 17 Oct 2026 19:28:23 +0000

4,298 MCP registry entries link to a GitHub repo that returns 404

md sultan mahamud — Fri, 16 Oct 2026 10:37:36 +0000

I built ProtocolProbe on my own to read the official MCP registry and public package records. This post is one question: when a registry entry links to a repository, does the link open?

Why ask

The registry checks that a repository URL is well-formed. As far as I read its source (2026-10-06), it does not fetch the URL, and it checks a package once, at publish time. So a link that worked at publish can stop working later, and a link that never worked is still accepted. I have not re-run that source read since.

Method

For every registry entry that links to a GitHub repository, I called GitHub's public repository API and recorded the HTTP status. Public records only. I did not run or call any MCP server.

Registry snapshot: 2026-10-04. Lookups: 2026-10-06.

Numbers

What	Count	Of	Share
Entries whose linked repo returns HTTP 404	4,298	38,977 registry entries	11.0%
Same, counted by publisher	2,594	23,016 publishers	11.3%
Same, among entries that link to GitHub	4,298	28,743	15%
Linked repo is archived (read-only)	309	24,256 entries with a reachable repo	1.3%

What a 404 means

GitHub returns 404 for a repository that is missing or private. From outside I can't tell which. It could be a rename, a deletion, a private repo or a typo. It is not a judgement on the publisher, and the registry never promised to re-check.

Limits

Figures are from 2026-10-06, not live.
GitHub links only; other hosts are not counted.
Counting by publisher is shown next to entries because a few publishers own many entries.
No monthly re-check has run yet, so I can't say how these numbers move over time.

Data and method

Page with the figures and sources: https://protocolprobe.com/mcp/reports
Dataset (Zenodo): https://doi.org/10.5281/zenodo.23386799

If you see a flaw in the method, tell me in the comments.