When we published the crawler census — 60 named bots hitting one directory-listed MCP + x402 endpoint, none of them buying anything — two readers on r/mcp asked the obvious follow-up questions. Is all of that traffic really coming from the directory listings? And do the monitors learn from each other — does a tool name published in one crawler's output end up being probed by another?
Both are answerable with a control. So on 2026-08-29 we deployed one.
The setup
- The listed server:
fetchgate.dev/mcp, the real thing. Published to the official MCP registry and around thirty x402 and MCP directories, linked from the site, the sitemap,llms.txt, and several articles and posts. - The unlisted twin: a second Cloudflare Worker with the same MCP wire shape (
initialize,tools/list,tools/call, the same headers, the same JSON-RPC error handling), deployed to an unguessableworkers.devhostname. It advertises two tool names that exist nowhere else on the internet — invented words, chosen so that any call to them by name would have to have been learned from this server's owntools/listoutput. It has never been listed, linked, submitted, posted, or mentioned anywhere, including in this article. Every request to it is logged: path, method, user agent, JSON-RPC method, tool name, country.
Same protocol, same account, same edge network, same eight days. One variable: listed or not.
The result
| Listed server | Unlisted twin | |
|---|---|---|
| Requests, 2026-08-29 → 09-05 (8 days) | 36,240 | 0 |
| Requests per day (range) | 3,248 – 7,218 | 0 |
/mcp requests in the last 24h | 1,664 | 0 |
Distinct user agents on /mcp, last 24h | 60 | 0 |
| Calls to the twin's unique tool names | — | 0 |
The twin's log contains exactly five rows: our own curl smoke test at deploy time, 2026-08-29 20:37Z, from South Africa. Nothing since. Not a liveness monitor, not a registry crawler, not a security scanner, not a subdomain enumerator, not a random GET /.
Zero is a small number, and it makes a clean statement. Per-day, for the record:
| Day | Listed | Unlisted |
|---|---|---|
| Aug 29 | 7,218 | 4 (us) |
| Aug 30 | 4,009 | 0 |
| Aug 31 | 3,701 | 0 |
| Sep 1 | 3,700 | 0 |
| Sep 2 | 3,293 | 0 |
| Sep 3 | 3,248 | 0 |
| Sep 4 | 4,931 | 0 |
| Sep 5 | 6,140 | 0 |
What this answers
1. Yes, the traffic is the listings. All of it. Not "mostly". Every one of the ~36,000 requests the listed server took in the window is downstream of a directory entry, a registry record, or a link. Remove those and the crawlers, monitors, graders and price-scrapers do not find you — because none of them is searching. They are reading lists.
2. No, the monitors do not learn from each other — at least not within eight days. Nobody called tools/list on the twin, so nobody could have republished its tool names, so nobody could have probed them. The "monitor-on-monitor" channel that a reader hypothesised is not carrying traffic at a rate this experiment can detect. (It cannot rule out the channel existing; it rules out the channel finding an unlisted server.)
3. Nobody is enumerating workers.dev. The twin sits on a subdomain of the same workers.dev account as the listed server. Wordlist scanning of that namespace, if anyone does it, did not reach a name like this one in eight days. That is expected — the hostname is not guessable — but it is worth having measured rather than assumed.
What it means if you run an MCP server
Listing is the whole discovery layer. This is the same conclusion as the census, from the other direction. The census showed that being listed produces crawlers and nothing else; this shows that not being listed produces nothing at all. There is no ambient discovery on the agent web today — no equivalent of a search engine following links, no agent stumbling onto your endpoint because it was useful. If your server is not in a registry, then to every crawler, monitor and researcher measured here, it does not exist.
Every "state of MCP" number is a number about the registries. When we probed 15,329 remote servers in the official registry and found 47 hosts with concealment directives in their tool descriptions, that was a measurement of the listed population. So is every security scanner's finding, every uptime dashboard, every trust score. The unlisted population is unmeasured — by us, and, on this evidence, by everyone else too. That cuts both ways: an unlisted server is invisible to the security-research crawlers, and an unlisted malicious server is invisible to them as well.
The monitors are not a signal of interest. We had already concluded this from the census's payment log (zero payments from 6,309 requests), but the twin sharpens it. Sixty user agents hit the listed /mcp in the last 24 hours. If any of them represented a user choosing a server, you would expect at least some of that choosing to happen off-list — a link shared in a chat, a URL pasted into a client. The twin got none, because nothing on the agent web is currently choosing; it is enumerating.
Honest limits
- One twin, eight days. A longer window could see a first request; we will update this page at 30 days (2026-09-28) and keep the twin running.
- "Unlisted" bundles several things. A
workers.devhostname has no certificate-transparency entry of its own (it sits under a wildcard certificate), no DNS zone to walk, and no root page. A never-listed server on a custom domain would separate "not in a registry" from "not in CT logs". That variant is the natural next experiment. - The listed server's request count is the whole Worker, not just
/mcp: it includes the site, the API, and the 402 challenges. The last-24h row (/mcponly, 1,664 requests, 60 user agents) is the like-for-like comparison, and the twin's zero holds against either. - This measures crawlers, not humans. A person who was sent the twin's URL would obviously reach it. Nobody was.
Method
Request counts for both Workers come from Cloudflare's account-level workersInvocationsAdaptive dataset, per script per day. The /mcp user-agent breakdown comes from zone analytics for fetchgate.dev over the 24 hours ending 2026-09-06T19:00Z. The twin logs every request to its own Analytics Engine dataset (path, method, user agent, JSON-RPC method, tool name, country, protocol version, Accept), which is where the "five rows, all ours" figure is read from.
The twin's hostname is deliberately absent from this article, from the site, from our sitemap and llms.txt, and from the GitHub mirror. The experiment is only valid while that stays true. If you run a crawler and would like to demonstrate that it can find unlisted servers: please don't — that is the measurement.
This experiment is a by-product of running Fetchgate, a live x402 + MCP storefront. The measurements it draws on — the registry audit, the Bazaar audit and the crawler census — are written up with every number in The Agent Web, Measured (2026 Q3), a 25-page analyst report ($149; free 5-page sample). The raw per-server rows behind the registry numbers are the MCP Tool Inventory dataset.