3 registry records that cannot resolve for any client, and a caution about single-pass dead counts

Yêu cầu duy nhất có thể thực hiện là một validator lúc submit, từ chối ba loại record không thể phân giải: một domain được bảo lưu như example.com, một {placeholder} chưa được thay thế trong URL, và một hostname *.trycloudflare.com, theo thứ tự tin cậy đó. Hãy bắt đầu bằng việc tìm chỗ mà registry viết bằng Go kiểm tra remote endpoint của một entry máy chủ khi submit, sau đó thêm các kiểm tra cú pháp này cùng với test bao phủ cả ba record sai định dạng. Xong khi ba entry mẫu đó bị từ chối mà không có bất kỳ HTTP request nào; phần còn lại của issue là một báo cáo đo lường, không có gì cần thay đổi.

Three registry records that can never resolve, and a caution about single-pass dead counts

Re-measured 2026-10-07. Nothing is requested of us and nothing is for sale; the data is below so
it can be checked or contradicted.

This is not a fifth census, and the four that exist are better than ours at counting

Before anything else, the prior work, because our numbers are not comparable to it and are in
places weaker:

• #1485 — siliroid, 80 remote hosts no longer resolve (~1.1%), 136 entries from one namespace
• #1487 — siliroid, ~11% of advertised remote endpoints do not speak MCP at the URL given (1,200 of 10,542)
• #1643 — mun29, 759 declared endpoints fail the initialize handshake, 70 more break before it
• #1626 — yassinht, 8.6% of listed entries with a remote endpoint answer HTTP but not MCP
• #1579 — Xdott, 387 active servers declare neither remotes nor packages

Those four measure the whole registry. We sampled 500 entries. More importantly, our definition
of dead is the weakest one in this tracker: we count an endpoint silent only when it returns no
HTTP response at all, so a host that answers 200 with HTML and no MCP underneath counts as alive
for us and dead for #1487, #1643 and #1626. Our rate is therefore a floor, not a measurement of
the same thing, and it should not be quoted alongside theirs.

What we have that is not already in those issues is below: three records that cannot work by
construction, a breakdown of why silent endpoints are silent, a recovery rate that argues
against trusting any single-pass count including our own, and one prober bug worth knowing about
if you are writing a census in Python.

1. Three records that cannot resolve for any client, ever

These are not dead services. The URL in the record cannot work by construction, so no amount of
the operator fixing their server would help, and a syntactic check at submission would catch all
three without a single HTTP request:

entry	endpoint in the record	why it can never work
io.github.PanosSalt/MCP-Gateway	https://your-gateway.example.com/t/your-org/mcp/sse	unfilled placeholder; example.com is reserved by RFC 2606 and has no such host (NOERROR, no A record)
io.github.braintrustdata/braintrust	https://api{region}.braintrust.dev/mcp	unsubstituted template variable {region}
io.github.TommoHCIO/solana-pulse-xaas	https://lobby-laptop-shame-achieved.trycloudflare.com/mcp	Cloudflare quick-tunnel hostname — ephemeral by design, cannot persist past the session that created it

A submission-time validator could reject a reserved domain, an unsubstituted {placeholder}, and
a *.trycloudflare.com hostname, in that order of confidence. This is the only part of this
report that suggests a change rather than reporting a number.

2. Why the silent ones are silent: 12 DNS, 6 TLS, 3 timeout

21 endpoints in our 500 returned nothing across 25–28 separate observations spread over 10
days, and the
reason splits three ways. The split matters, because the first two kinds are detectable in one
cheap pass and the third genuinely needs repeated observation:

NXDOMAIN — 12. Confirmed against Cloudflare (1.1.1.1) and Google (8.8.8.8) over DoH as well
as our own resolver, all three returning Status 3, so this is not a local resolver artifact:

signals.boolsai.ai · mcp-kr.wishpool.app · inv-lu.wishpool.app · mcp-mt.wishpool.app ·
mcp-sk.wishpool.app · mcp-ua.wishpool.app · c2padisclosure.clauxel.com ·
genaispanmapper.clauxel.com · tracepiishield.clauxel.com · api.oranoai.com ·
mcp.askew.network · weather.selflabbs.com

Two namespaces account for 8 of the 12: five app.wishpool/*-payments-mcp entries and three
com.clauxel.* entries, each set published together and each set now entirely unresolvable —
which looks like abandoned infrastructure rather than twelve independent outages.

TLS failures — 6. The name resolves and the host accepts the connection, but no verifying
client can complete a handshake:

endpoint	failure
https://tv.djwizard.ai/mcp/	tlsv1 alert internal error
https://mcp.csquaredsystems.com/sse	certificate chain incomplete — unable to get local issuer certificate
https://mcp.knowledge-raven.com/mcp	certificate is not valid for mcp.knowledge-raven.com
https://code-sandbox.api.klymax402.com/mcp	tlsv1 alert internal error
https://dex-quotes.api.klymax402.com/mcp	tlsv1 alert internal error
https://text-to-speech.api.klymax402.com/mcp	tlsv1 alert internal error

These would read as "connection error" in a census that only records success or failure, and as
an operator-fixable configuration problem if the cause were reported. Two are one-line fixes
(serve the intermediate certificate; get a certificate for the name you advertise).

Timeout — 3. https://relayagents.net/api/mcp · https://swarm.gadgethumans.com/mcp ·
https://mcp-company-lens-v1.gepuro.net/mcp. These are the three we are least confident about:
a host that drops packets from one network can be perfectly reachable from another, and we probe
from a single residential line in Portugal. Treat them as unverified.

3. Half of everything that ever failed also answered at some point

This is the finding we would most want the other four issues to have, and it cuts against our own
numbers as much as anyone's. Over 500 entries and 25–28 observations each:

	hosts
answered every single time	448
failed at least one observation	52
…silent in every observation	25
…failed, then answering again by the end	12
…answered earlier, silent by the end	15

That 25 is the whole of what we found silent, and it decomposes exactly into the sections above:
21 services that answer nothing (§2) + 3 records that cannot resolve for anyone (§1) +
1 that was never dead at all and is an artifact of our own prober (§4). We report it that way
rather than as "25 dead entries", because three of them are not services and one of them is us.

So 27 of the 52 hosts that ever failed — 51.9% — answered on at least one observation, and
23.1% of them were back up by the end of the window. A single pass that finds an endpoint
unreachable has found something about that moment, not about the entry, and the proportion is
large enough that a one-shot count can overstate badly.

Two of ours moved in the last 24 hours alone: com.odooconsole/odoo-mcp recovered before we
first wrote this up (now answering 401, which is a working gated endpoint), and the entry in §4
turned out never to have been dead at all.

If the registry ever wants to flag entries automatically, the threshold should be n consecutive
failures separated in time, not one.

4. A prober bug, in case you are measuring this in Python

io.github.Ansarii/devops-code-auditor advertises
https://neon_innovation_lab--devops-code-auditor.apify.actor/mcp. We had it on a list of
malformed records with the note "hostname contains an underscore — not resolvable in DNS".

Both halves of that were wrong, and we only found out by re-probing with a second tool. The
name resolves (wildcard DNS, 54.160.182.20) and the endpoint answers — curl gets a clean
404, which is alive by any definition in this tracker. What fails is our prober: Python's
urllib/ssl rejects the certificate as not valid for that hostname, because an underscore is
not a legal character in a hostname and so standard verification will not match it against the
wildcard *.apify.actor. OpenSSL via curl matches it anyway.

So a census written in Python will report every *_*.apify.actor actor endpoint as dead, and a
census written in Go or with curl will not. Worth checking if your numbers include Apify-hosted
actors. The entry is removed from our list, and we would not have caught it had we not run the
re-probe through a different transport.

Limits, stated plainly

• 500 of the registry's entries, with a recorded seed, probed every 6 hours from 2026-09-27:
  25–28 observations per entry, and every endpoint named above was re-probed on 2026-10-07
  immediately before posting, through two independent HTTP clients.
• One vantage: a residential line in Portugal. A host geofenced or blocking that network reads
  as silent here and may be reachable elsewhere. This is why the three timeouts are flagged
  unverified and the 12 NXDOMAIN results were cross-checked against two public resolvers.
• Silence is measured, not explained. We cannot distinguish abandoned from firewalled.
• An endpoint counts as alive on any HTTP status — 404, 401, 405 all count, because a bare API
  host has no reason to serve a homepage and 405 is the correct answer to a GET on MCP transport.
  We do not perform an initialize handshake, which is why #1643's method is stronger than ours.

Happy to share per-observation timestamps for any entry, or to re-probe a specific host.