80 remote hosts no longer resolve (~1.1%), and 136 entries come from a single namespace

I scanned the public registry API and checked whether the hosts behind remotes[] still resolve in
DNS. Reproduction, no clone and no account:

npx -y -p github:siliroid/unreached unreached-registry --api https://registry.modelcontextprotocol.io

Scope: 60,566 servers, 7,516 distinct remote hosts.

The number, after I filtered it three times against myself

The claim I'd stand behind is the last row: 80 company-owned endpoints across 174 entries, ~1.1%
of hosts. The raw 250 / 3.3% is what I'd have reported an hour earlier, and both excluded classes
are separate stories rather than noise — a lapsed free deploy isn't a business going dark.

Method, including what it deliberately does not count

DEAD = the hostname does not resolve, resolve4 and resolve6 both ENOTFOUND. Not counted:
4xx/5xx (could be auth or a bot wall), timeouts, Cloudflare refusing a non-browser agent. I
published a 56% false-positive rate on my own link crawler this week for exactly that class, so the
DNS signal is the only one here without an error bar — and it makes this a floor, not a ceiling.

Hand-verified 10 hosts individually, A and AAAA separately: 10/10 ENOTFOUND. Among them
mcp.perplexity.ai (7 entries), checked twice because a wrong claim about a company that size is
exactly the mistake worth avoiding.

The concentration, which is the part I think you'll care about

app.wishpool/* accounts for 136 entries / 125 distinct dead hosts — roughly 28% of all
affected entries, from one namespace. Measured:

• 91 distinct GitHub repo URLs across those entries, all under one owner (junter1989k-ai)
• that account currently reports 0 public repositories
• 15 of 15 sampled repo URLs return 404
• every remote endpoint: ENOTFOUND
• versions 0.1.0–0.3.0, published across a few days, status active

Every artifact those entries point to is unreachable — source and endpoint both. That is the
entire claim, and I'm not making a second one. Abandonment, a migration, a deleted account and a
lapsed domain all produce this identical evidence and I can't tell them apart from outside. 15/15 is
a sample, not a census, and 0 public repos corroborates without proving anything.

If it's useful I'll open a separate issue with the full 80-host list, or a PR against whatever
delisting process you'd prefer. Happy to re-run on a schedule if a periodic check is wanted.

Run the supplied unreached-registry command against the registry API and inspect the reported remotes[] hosts. Then review the registry's existing process for handling unreachable entries. The report mentions a possible host-list issue or periodic check, but does not define which outcome or acceptance criteria is wanted.