One domain holds 75 registry entries under 75 separately-registered namespaces, and 62 of them serve `text/html`

[siliroid]

I probed every remote endpoint in the registry (10,540 of 10,542 reached; data and method: https://github.com/siliroid/mcp-endpoint-census). One domain stood out far enough to be worth reporting on its own.

What is measurable

clauxel.com has 75 endpoints in the registry, published under 75 distinct publisher namespaces — com.clauxel.a2adependencyinspector, com.clauxel.a2aidentitytoll, com.clauxel.a2areplayreceipt, and so on, one namespace per subdomain.

result	count
405 to a POST, serves text/html on GET	62
404	6
401 (gated — live, and correct behaviour)	4
completes an MCP initialize handshake	3

I checked the content type on 10 of the 62 individually. All 10 return text/html with CF-Cache-Status: HIT. The page at one of them is titled "Connect agents to a paid remote MCP endpoint — A2A Identity Toll".

So: a GET returns a cached marketing page describing a paid MCP endpoint, and a POST — which is what streamable HTTP actually uses — returns 405, because static hosting does not accept POST.

Reproduce

# advertised endpoint, POST as a client would
curl -sS -o /dev/null -w '%{http_code}\n' -X POST https://a2aidentitytoll.clauxel.com/mcp \
  -H 'content-type: application/json' -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"p","version":"1"}}}'
# => 405

# same URL, GET
curl -sSL -o /dev/null -w '%{content_type}\n' https://a2aidentitytoll.clauxel.com/mcp/
# => text/html

The 62 are listed in broken-rows.csv in the repo above, each with a repro command.

What I am not claiming

I have measured bytes, not intent, and the distinction matters here:

• I do not know that these are not real products. They may be pre-launch, with the listing published ahead of the server. That is a perfectly ordinary thing to do.
• The servers may exist elsewhere. not-mcp here means the URL in the registry does not serve MCP. It says nothing about whether the software is good or running somewhere else.
• 3 of the 75 do complete a handshake, and 4 more return 401, which is correct behaviour for a gated commercial service. Those 7 cut against the simplest reading and I would rather flag them than leave them out.
• I am not asking for anyone to be removed. That is a policy call and it is yours, not mine.

Why raise it as its own issue

Ecosystem-wide, non-responding endpoints are diffuse — 523 distinct hosts carry the 1,154 broken rows. This is the opposite shape: one operator, one domain, 75 namespace registrations, ~83% of them serving a cached HTML page at the advertised MCP URL. Whatever the intent, a client resolving these gets a marketing page instead of a server, 62 times.

If registry policy has a view on one publisher taking 75 namespaces, this is the case that surfaces it. If it does not, that is also a useful thing to have decided deliberately rather than by default.

Related: #1487 (protocol conformance across the whole registry), #1445 (proposal for health metadata on entries).

Correction note, since it bears on trusting the numbers above: I published the ecosystem figure as 14.4% earlier today and corrected it to 12.2% within two hours — two bugs in my own prober, both inflating it, found by running a stratified control arm (40 suspects and 40 controls, independent HTTP stack). The correction and the mechanism are at the top of that repo. The clauxel figures here are from the corrected run and the content types were checked by hand.

[ppcvote]

The measurement holds up — I re-ran the registry side independently before writing any of this: /v0/servers?search=clauxel returns exactly 75, all status: active, all under com.clauxel.*, 75 distinct namespaces, published across 2026-05-17 → 05-27. Two things I can add that bear on the policy question you deliberately left open, one mechanical and one on the time axis.

The 75 namespaces are one verification, not 75

This matters because it changes where a policy lever would go. From internal/api/handlers/v0/auth/dns.go, in ExchangeToken:

// DNS implies a hierarchy where subdomains are treated as part of the parent domain,
// therefore we grant permissions for all subdomains (e.g., com.example.*)
// This is in line with other DNS-based authentication methods e.g. ACME DNS-01 challenges

A single TXT record at the clauxel.com apex grants com.clauxel.*/*. So com.clauxel.a2adependencyinspector, com.clauxel.a2aidentitytoll and the other 73 are not 75 separately-registered namespaces — they are 75 names under one grant, and publishing all of them costs exactly one DNS record. The ACME comparison is apt and the design is deliberate.

That reframes the finding rather than diminishing it. "One publisher took 75 namespaces" implies a quota lever. What's actually happening is that the registry's unit of trust is the registrable domain, while its unit of presentation is the namespace — and nothing in the API surface expresses that these 75 share one root. A client listing servers sees 75 independent-looking publisher identities; a client that knew they collapse to one apex would rank, dedupe, or display them very differently. No quota can fix that, because the wildcard grant is the intended behaviour.

The verification is a one-time snapshot, and this one has already lapsed

Verification happens once, at token exchange (ExchangeToken → LookupTXT → hasMCPRecord). LookupTXT is called from nowhere else in the repo except that handler and its tests, and a code search for revalidate / reverify / recheck / periodic returns nothing (the only cron hits are the schema and DB sync workflows). Nothing revisits domain control after the JWT is issued, and published entries carry no expiry tied to it.

That is observable here today:

domain	MCPv1 TXT present now?
clauxel.com (apex)	no — only SPF and a Google site-verification record
a2adependencyinspector.clauxel.com	no TXT at all
a2aidentitytoll.clauxel.com	no TXT at all

Queried through both Cloudflare and Google DoH resolvers, agreeing. Since a lapsed record is only meaningful against a base rate, I checked a control arm of eight other domain-namespaced entries drawn from /v0/servers (inference.ac, tandem.ac, hood.ag, kesey.agency, lona.agency, 1325.ai, aarna.ai, abmeter.ai): seven of the eight still publish a live MCPv1 record. Keeping the record is the norm, so the absence here is a real difference and not just how everybody operates. Eight is a small sample and I'd treat it as a direction, not a rate — your census could settle it registry-wide in one pass.

What I am not claiming: that anything was removed maliciously, or that these entries are illegitimate. A publisher rotating keys is told to delete the old record, and stopping there is an easy and honest mistake. The point is structural, not about this operator: a domain-namespaced entry can outlive the proof that produced it, and today nothing measures or displays that. Domains also expire and change hands, and when one does, every com.<olddomain>.* entry keeps its verified-looking prefix under an owner who never held the key. That is the same trust-boundary-over-time problem we hit auditing agent skills in anthropics/skills#492: a one-time check plus a durable trust marker reads to users as a continuously-held property.

Policy options, cheapest first

1. Expose the trust root. Derive the verifying apex from the namespace and surface it in the API (_meta on the entry, or a query parameter). Purely additive, no policy judgement required, and it lets clients collapse or rank by root without the registry deciding anything. This is the one I'd argue for regardless of what else happens.
2. Re-verify periodically. A scheduled TXT re-check per verified apex, with the result exposed as metadata rather than as an enforcement action. Cheap: one DNS query per apex, not per entry. It reduces the aggregate to a number instead of an anecdote, which is what a maintainer needs to decide whether the aggregate matters at all.
3. Liveness on remotes[] — already the subject of ~11% of advertised remote endpoints do not speak MCP at the URL given (sampled 1,200 of 10,542) #1487, so I won't restate it here beyond noting that lapsed-proof and not-serving-MCP are independent signals, and an entry showing both is a much stronger candidate for review than either alone.
4. Rate or review thresholds per apex — I'd rank this last. It's the intuitive response to "75 entries", but it targets a symptom of the wildcard grant rather than the grant, and it collides with docs/design/design-principles.md ("avoid features that require constant human intervention or moderation"). Options 1 and 2 keep that principle intact; this one spends it.

Happy to open a PR for option 1 if that's a direction you'd take — it looks like a small change on the read path, and it doesn't require the project to have decided the harder question first. Not planning to touch anything until a maintainer says which way this is going.

(Method note, since your correction upthread set the standard: the registry counts and DNS results above are from live queries today, the code quotes are from main, and I checked the control arm precisely because I didn't want to report a lapsed record without knowing the base rate.)