387 active servers declare neither remotes nor packages and cannot be reached

[Xdott]

Describe the bug

387 servers with status: active declare neither remotes nor packages. They are published and discoverable, but their record contains no way for any client to reach or install them.

I found this while taking a census of the registry, not while trying to publish, so this is a data-quality observation rather than a publish-flow bug.

Numbers

Retrieved every record from GET /v0/servers by cursor pagination (August 2026): 82,994 version records, resolving to 25,125 distinct servers after filtering on _meta[...].isLatest.

Finding	Count	Share of distinct servers
No remotes and no packages	393	1.56%
...of which status: active	387	1.54%
Still carrying the unedited description template	8	—
status: deprecated but still listed	262	1.04%

Examples (all status: active, no transport declared)

• ai.complyme.mcp/mcp v1.0.0
• ai.megastructure/arc v1.9.1
• app.qwady.thorns/thornguard v0.1.0
• bid.scope/healthcare v0.0.0
• capital.hove/read-only-mysql-mcp-server v0.1.0

The 8 servers whose description is still the template string [describe what your server does]:

co.contraption/mcp, io.github.TranThienTrong/asset-auto-picker, io.github.arun250492/Personal-MCP, io.github.atarkowska/fastmcp-pdftools, io.github.augee99/mcp-weather, io.github.manoharanRajesh/python-version, io.github.preedew17/mcp-bookmark, io.github.shafarenkacfi/mcp-server-registration

Expected behavior

Publication could reject a server that declares neither remotes nor packages, since such a record cannot be acted on by any client. The template-description case is a one-line string check.

This is adjacent to #1193 and #1004 but distinct: #1193 concerns skipping deprecated servers during remote-URL validation at publish time, and this is about records that declare no transport to validate in the first place.

To Reproduce

python fetch_mcp_registry.py --out mcp-registry.jsonl
python -c "
import json
rows=[json.loads(l) for l in open('mcp-latest.jsonl',encoding='utf-8')]
none=[r for r in rows if not r.get('remotes') and not r.get('packages')]
print(len(none), 'of', len(rows), 'have no transport')
print(sum(1 for r in none if r.get('_status')=='active'), 'of those are active')
"

Retrieval script: https://github.com/ashishsinha1602/dataset-integrity-audit/blob/main/fetch_mcp_registry.py

Additional context

Counts are a snapshot from August 2026 and will drift. One caveat on methodology, in case it is useful to anyone repeating this: the endpoint returns one record per version, so measuring without filtering to isLatest inflates duplicate-description rates roughly 20x (74.5% vs 3.6%). The mean is 3.30 versions per server, with a maximum of 1,175.

Happy to open a PR adding the transport check if that would be welcome.

[ashishsinha1602]

A second, distinct failure mode with the same consequence, found while extending the census: 58 servers declare an installable package that does not exist.

The original report covered servers declaring no transport. These declare one, but the package 404s.

Package registry	Identifiers checked	Missing	Rate
npm	7,498	34	0.45%
PyPI	3,279	24	0.73%
Total	10,777	58

Method. Every declared identifier was resolved against the live registry (registry.npmjs.org, pypi.org/pypi/<name>/json). Only an explicit 404 counts as missing; rate limits and 5xx are recorded separately as unresolved, and there were zero unresolved � every one of the 10,777 identifiers resolved cleanly.

I mention the method because I first estimated this from a package-index dump and got a materially different number. Index scans produce false positives on scoped npm packages, and a small random sample overestimated the rate by ~7x. Only the exhaustive live check is reliable here.

npm (34):

@alexendros/proton-mail-mcp
@anara123/mcp-weather-server
@authzx/mcp-gateway
@bgorzelic/ghostlink
@briangaoo/totem
@cognitivemyriad/vrm-local
@cyanheads/bls-mcp-server
@cyanheads/eia-mcp-server
@cyanheads/fred-mcp-server
@cyanheads/gbif-mcp-server
@cyanheads/nominatim-mcp-server
@cyanheads/uspto-mcp-server
@datasynx/agentic-ai-cartography
@datasynx/agentic-ai-shadowing
@gener8v/mcp-geographic-data
@ingeniux/ctnp-mcp
@intencion/mcp
@j0hanz/code-review-analyst-mcp
@j0hanz/filesystem-context-mcp
@jamesrez/valoria-intelligence
@latam-mcp/mcp
@littlebearapps/outlook-mcp
@merk.a2a/mcp-server
@oaslananka/composer
@oaslananka/sentinel
@pavelpiha/specrun
@ramaris/mcp-server
@seojeom/mcp-server
@shirbarzur/planform-mcp-server
@shmindmaster/repocontext
@strajkpolski/mcp
@vidnotes/mcp-server
@walensis/mcp-for-ynab
@yawlabs/nol-mcp

PyPI (24):

aifp
aion-news-to-signal
atlaso
baton-orchestrator
codeintel-navigation-mcp
codelogic-mcp-server
crosstabs-mcp
dataraum
eval-integrity
ghostqa
glitch-grow-linkedin-ad-mcp
grandline-mcp
instinct-mcp
labs-mcp-server
mcp-search-server
mcp-server-evolutiondb
olane-cosync-local
regula-ai
selvo
spineframe
sqlite-mcp-server-enhanced
twilize
vivory-mcp-korea
wrg-mcp-server

Suggested check. Unlike the no-transport case, this one cannot be fully settled at publish time � a package can be unpublished afterwards. A periodic resolve of declared identifiers, marking servers whose package has disappeared, would catch it. Happy to contribute that if it would be useful.

Verification data: dead-packages.json � full list plus counts. Checker: check_dead_packages.py.

[Xdott]

Correction to my own report: the number should be 189, not 387.

While preparing a PR for this I read docs/reference/server-json/generic-server-json.md more carefully and found the section "Server with Custom Installation Path":

For MCP servers that follow a custom installation path or are embedded in applications without standalone packages, use the websiteUrl field to direct users to setup documentation

The example beneath it declares neither packages nor remotes — deliberately. So a server with no transport but a websiteUrl is following documented guidance, not misconfigured. I missed this when I filed.

Re-measuring with that distinction:

	Servers
status: active, no remotes and no packages	387
— with a websiteUrl (documented pattern)	198
— with no websiteUrl at all	189

So roughly half the original figure is legitimate. The genuinely unreachable set is 189 — no endpoint, no package, and no page telling a user what to do instead.

Examples of the real cases: ai.complyme.mcp/mcp, capital.hove/read-only-mysql-mcp-server, cash.flat/flatcash-mcp, ai.gatetest.www/gatetest.

What this changes about the suggested fix. A flat "must declare a transport" rule would reject your own documented example and break make validate, since tools/validate-examples/main.go runs the semantic validator over the docs examples. The rule that matches your documentation is at least one of packages, remotes, or websiteUrl — that keeps the custom-installation pattern valid and still rejects all 189.

I also noticed docs/design/proposed-enhanced-validation.md puts concerns like this in the non-blocking Linter tier, and cites prefer-transport-configuration as an example rule name — which suggests you may already intend this as a warning rather than a publish-blocking error. And #642 (on-device packages) looks like it would legitimately cover some of these cases too.

Rather than send a PR that guesses, I'd rather ask: do you want this as a blocking semantic error on the three-field rule, or as a linter-tier warning? Happy to implement either — the investigation is done and I know where it goes (internal/validators/validators.go, semantic block around lines 100–113).

Apologies for the inflated first number. The 58 dead package references in my earlier comment are unaffected — those were resolved individually against the live npm and PyPI APIs.

[erdemt]

Independent reproduction from a separate pipeline, plus two extensions that may be useful for deciding where the check belongs.

I maintain an ingest pipeline that snapshots the registry (full GET /v0/servers enumeration, one row per server name, isLatest only). Snapshot of 2026-08-28: 25,297 distinct servers, 25,033 active.

Your split holds almost exactly. Active servers declaring neither remotes nor packages: 385 (yours: 387) — of which 197 carry a websiteUrl (yours: 198) and 188 have none (yours: 189). The small drift is consistent with different pull dates on a moving registry.

Extension 1 — the complementary failure class: declared-but-dead remotes. We probe every declared remote with a real MCP initialize + tools/list (10s timeout; single pass, 2026-08-23→27). Of 13,925 active servers declaring ≥1 remote, 7,586 answered with a non-empty tool list. Among the failures, 1,314 are hard-unreachable — DNS-dead host (620), HTTP 404 on the declared endpoint (609), TLS failure (85). So beyond the 188 records with no way to reach them, there's a larger set that declares a transport that doesn't exist anymore. Caveat: 2,556 further failures are 401/403 auth walls — alive but credentialed, so "didn't answer" must not be read as "dead".

Extension 2 — the template-description problem is bigger than the 8 you found. Exact duplicate descriptions (case/trim-normalized) across distinct active servers: 375 groups covering 816 servers — led by "Description of my MCP server" ×22 and "An MCP server for weather information." ×14; the literal [describe what your server does] placeholder appears ×7 in our snapshot. 110 active servers have descriptions under 20 characters. And 1,163 short names exist under more than one namespace (mcp alone under 1,171 namespaces).

On the fix: the three-field rule (packages | remotes | websiteUrl) matches what our data shows as genuinely unreachable, and the dead-remote/dead-package cases support your point that a publish-time check can't be the whole answer — those need a periodic re-validation pass, which fits the linter tier the maintainers' proposed-enhanced-validation.md describes.

Happy to share query definitions or re-run any of these against a fresh snapshot if useful.

[Xdott]

This is the most useful thing that could have happened to that report — thank you for reproducing it from an independent pipeline.

Your numbers against mine, different pull dates:

	yours (08-28)	mine (08-28)
active, no remotes and no packages	385	387
— with websiteUrl	197	198
— without	188	189

A one-server drift on a registry gaining ~300/day is about as close as two independent enumerations get. That settles the 189 figure a lot more firmly than my single measurement did.

On your Extension 1 — this is the finding, and it's bigger than mine. 1,314 hard-unreachable declared remotes (620 DNS-dead, 609 HTTP 404, 85 TLS) against my 189 no-transport records means the declared-but-dead class is roughly 7x the declares-nothing class. I only checked declared packages (58 of 10,777 identifiers 404 on npm/PyPI) and never probed remotes, so I missed the larger half entirely.

Your 401/403 caveat is the right call and worth stating loudly: 2,556 auth-walled endpoints are alive-but-credentialed, and folding those into a dead count would inflate it by roughly 3x. That's the same trap as the websiteUrl one I fell into — a shape that looks like a defect and isn't.

On Extension 2 — your 375 duplicate-description groups covering 816 servers is a much better measurement than my 8 template strings, because you're counting the general case rather than one literal. I'd only add that when I ran near-duplicate clustering over descriptions I got 487 clusters at Jaccard ≥ 0.70, none identical across every evaluated field — so description collision looks widespread but rarely indicates a genuinely duplicated server.

On where the check belongs — I agree with your read. Publish-time validation can only catch the packages | remotes | websiteUrl case; everything you found is a liveness property that decays after publication and needs periodic re-validation. That maps cleanly onto the linter tier in proposed-enhanced-validation.md, and it argues for prefer-transport-configuration as a warning plus a separate reachability sweep, rather than one blocking rule.

I'd genuinely like the query definitions if you're willing. And if the maintainers want it, I'm happy to combine both snapshots into a single writeup with the methodology from each — your remote probing plus my package resolution covers the whole surface, which neither of us does alone.

My data and code: https://github.com/ashishsinha1602/dataset-integrity-audit

[Xdott]

I probed the declared remotes independently to check your Extension 1, and the short version is that your numbers hold and mine had a methodological flaw worth flagging for anyone else measuring this.

My run: 14,272 remotes across 13,805 active servers, single pass, 10s timeout.

Class	Mine	Yours
DNS-dead	647	620
TLS failure	115	85
HTTP 404	1,090	609
auth-walled (401/403)	2,487	2,556
hard-unreachable total	1,852	1,314

DNS and TLS line up closely — those are transport-level and method-independent, so the drift is just different pull dates. Auth-walled agrees too.

The 404 class disagrees by nearly 2x, and the difference is my fault. I probed with a plain GET. You did a real initialize + tools/list. MCP streamable-HTTP endpoints frequently reject GET — the transport expects POST with a JSON-RPC body — so a GET-404 does not mean the endpoint is gone.

I tested that directly: of a random sample of 400 declared remotes, 28 returned 404 to a GET. Re-testing those with a proper initialize POST, 16 of 28 (57%) responded with something other than 404. Small sample, so treat the ratio as approximate, but the direction is unambiguous.

Applying it to my totals: roughly 469 of my 1,090 404s are likely genuine, which puts my hard-unreachable count near 1,231 against your 1,314 — a difference well inside what different pull dates and timeout thresholds explain.

So: independently reproduced. The declared-but-dead class is real and is several times larger than the 189 declares-nothing class.

The practical takeaway for anyone repeating this: do not probe MCP remotes with GET. It will overstate dead endpoints by roughly a factor of two, in the same way that counting auth-walled endpoints as dead overstates by roughly three. Both are shapes that look like failure and are not — which is the same trap as the websiteUrl case at the top of this thread.

Probe code, with failure classes kept separate rather than pooled: https://github.com/ashishsinha1602/dataset-integrity-audit/blob/main/probe_remotes.py

I'll fix mine to do a real handshake before I use these numbers anywhere.