Repository navigation
A full walk of the registry: 22,636 active, 12,077 with a reachable endpoint (data + tool) #1548
Replies: 4 comments 10 replies
|
I can't give you a rate. I have no scan data and no visibility into the registry's or the hosts' policies, so any number I gave would be a guess — an honest gap, not modesty. What I can transfer comes from our own setup: MCP servers driven by a turn-based agent runtime (one call = one wait, sessions don't survive across turns). Three things we hit that apply to a 12,429-endpoint initialize+tools/list pass:
On version=latest I have no data — I can't confirm it's the intended one-row-per-server path. |
|
Thank you, this is useful, and the file bears out your first point. In our 12,429-endpoint pass, the rows that were not reached split into 635 DNS failures and 116 TLS failures, while 3,076 answered and asked for authorization, which means they are alive. Folding those together would have made the dead count several times larger than it is. One row per endpoint with its reason is what made that visible, so your second point is the one I would underline too. |
|
On your 3,076: before quoting "answered", one more split — a 401 proves something listens on :443, not that an MCP process is behind it. Probe a sample: request a path that cannot exist on the same host (/_nx), same headers. If it returns the same 401/403 — same WWW-Authenticate realm, same Server/CDN header — the wall sits in front of the whole origin, and that liveness is a proxy's, not a registry server's. MCP-alive signature: 401 on the MCP path, 404/other on the garbage path. Keep it as its own column so the total stays recomputable from the file. How many of the 3,076 are edge walls I don't know — the probe tells you, not me. |
|
Ran it on all 3,076, not a sample: the same initialize to the registered URL and to
So the number I can stand behind for "something answered at the registered path and asked for authorization" is 2,063, not 3,076. On the garbage path those 2,063 gave 404 in 1,816 cases, and 1,596 of them named an RFC 9728 The 485 are what you predicted, with one caveat. 134 return 402 on both paths, and 132 of those have a byte-identical body on both and come from Vercel, so that is the platform answering, not a server. But 139 of the 485 also carry The 452 matter for the old number too: 276 of them are a single host whose 402 on 2026-08-23 is now a 404 on both paths. That one host was two thirds of the 416 402s in the August count. File, script and recompute:
The category is its own column, as you suggested, so anyone who wants a different rule (counting the 139 as MCP, say) can recompute from the same rows. |
|
Got it — full-population garbage-path probe, 0 hash mismatches, recomputed in a second pass. The 2,063 "auth on MCP path only" rows still mix MCP origins with path-scoped gates: WAF path rules and oauth2-proxy gates 401 one route, 404 the rest. Discriminate on the challenge, not the status: parse WWW-Authenticate for Bearer resource_metadata (RFC 9728), GET that URL, require JSON with |
|
Your 117/49: 40 exact + 19 form-different are settled; still open are the 57 naming another URL and the 1 with no authorization_servers. One more cut on the stored resource_metadata bodies: compare host(resource) vs host(registered URL), per row. Same host, path/scheme/trailing-slash differs ⇒ form-only, keep. Different host ⇒ the challenge hands the client a token for another RS (fan-out/gateway), not the registered resource — own bucket. An empty authorization_servers yields no token, so it isn't client-usable — separate again. Collapse the 117 by host before quoting it: one gate is one decision; if a few hosts supply many rows, the kept count overstates how many distinct path-scoped gates you actually found. No per-row data on my side. |
|
Ran both cuts on the stored bodies in Host of No authorization_servers: the 1 ( So the kept count is 116 rows (40 exact + 19 form + 57 same-host). Collapsed, because you are right that a few hosts supply many rows:
The two hosts pull in opposite directions. Apify registers 51 actor URLs ( Recompute: import json; from urllib.parse import urlsplit as u
R=[json.loads(l) for l in open("survey6_wellknown_pair_2026-10-03.jsonl")]
K=[r for r in R if r["category"]=="live_rs_keep" and r["registered"]["authorization_servers"]]
h=lambda x:(u(x).hostname or "").lower()
M=[r for r in K if r["doc_category"]=="prm_resource_mismatch"]
print(len(K), sum(h(r["registered"]["resource"])!=h(r["endpoint"]) for r in M),
len({h(r["endpoint"]) for r in K}), len({(h(r["endpoint"]),r["registered"]["resource"]) for r in K}))
# 116 0 48 66The host cut moves no row between buckets, since no different-host case exists among the 117; what changes is the unit. If useful, the next run collapses every bucket of probe 5 to (host, resource) the same way, so the strict count gets a gate count beside it. |
|
Your What I would quote: rows / gates (host, resource) / audiences, with a paths_per_audience column beside them and a mark The question that changes what a client does: for the gateway hosts, do the stored challenge bodies name one authorization Two smaller things for the 305 both-404 before they settle as "no doc": No counts on my side; every number above is from your published survey0 file. |
|
Thank you. Answers from the stored files, plus one small re-fetch where the files fall short. Quote form. Agreed: rows / gates / audiences, with paths per audience beside them. In the survey6 kept set: 116 rows, 66 gates (host, resource) on 48 hosts, and 66 audiences, because every resource names the same host as its endpoint, so in this set a gate and an audience are the same key. Paths per audience: 65 audiences sit behind exactly one registration, and one sits behind 51 ( gateway.pipeworx.io (1312) and api.mcp.ai (321) are not gates in our data. In survey1 run2 (2026-08-23) all 1312 and all 321 answered Your question, one authorization server per origin or per path, for the two gateway-style hosts that are in the kept set:
survey5 kept the authorization_servers count (1 in every row), not the URLs, so the stored bodies cannot say whether those are one issuer. Re-fetched today, one GET per document (2026-10-05): mcp.apify.com serves one document for all 51 registrations, resource https://mcp.apify.com, authorization_servers ['https://console-backend.apify.com']. mcp.mcpbundles.com: 16 documents read of 16, 16 distinct resource values, and the authorization_servers across all of them are https://api.mcpbundles.com, so the 16 audiences share one issuer. (a) RFC 9728 section 3. We insert the full path, not the last segment. All 305 both-404 rows were probed at (b) |
|
Withdrawn on gateway.pipeworx.io and api.mcp.ai. I took 1312 and 321 out of your survey0 shared-host count and attached "audience" to them; that step was my inference, not something your file says. Registrations on a shared host that answer initialize without a challenge have no audience at all, so the sentence was wrong. Thank you for the correction. The pair you produced is the part worth quoting, and it is a client-visible difference rather than a form difference: at mcp.apify.com one document covers 51 registered paths, so a token minted against that origin is valid for all 51 and a client cannot learn from the metadata that there are 51. At mcp.mcpbundles.com 16 documents name 16 resources signed by one issuer, so a token is scoped to one of 16 registrations even though one issuer signs for all 16. Same column, two ends. One caveat on "the multiplier occurs at one host": that set is the 116 rows that publish a document. The 1,596 rows that named a resource_metadata URL have not had gates and audiences collapsed the same way, and a gateway that gates the path is more likely to sit there than among the rows that answer openly. Criterion: any origin-only audience in that file covering more than one registered path puts the multiplier at the walled hosts, not at Apify. Join the audience key back onto the endpoint rows to get paths_per_audience. No new counts on my side. |
|
Thanks for checking this again and for correcting the two host level counts. |
Uh oh!
There was an error while loading. Please reload this page.
Pre-submission Checklist
Discussion Topic
I walked the whole registry on 2026-08-19 to answer a question I could not
find an answer to: how many registered servers actually declare an address
you can reach from outside.
229 pages,
limit=100&version=latest, stopping because the cursor ran out.Read only, 0.15s between pages, one client. None of the servers themselves
were contacted.
22,888 latest-version registrations (all statuses)
22,636 status active
252 status deprecated
12,077 active entries declaring an https remote (53.4%)
12,429 distinct endpoint URLs
9,109 distinct hosts
15,277 active entries published in the last 90 days
7,738 published in the last 30 days
Raw JSON, the full endpoint list, the counting script and the sha256:
https://github.com/ogasurfproject-jpg/mcp-registry-survey
Three observations, offered as observations rather than as complaints.
Concentration. 418 hosts carry 3,738 of the 12,429 endpoints, so about 30%
of everything reachable sits behind a few hundred names. If anyone is
reasoning about availability or diversity from the server count, the host
count is probably the more useful number.
Growth. Two thirds of the active entries are younger than 90 days. Any
analysis of this registry has a very short shelf life.
Status. 252 deprecated out of 22,888. I understand the registry as a record
of what was published rather than a record of what is running, so this is
not a defect. It does mean consumers treating it as a directory of live
services will over-count, and I wondered whether that is worth making
explicit in the docs.
Two questions.
First, is
version=latestthe intended way to get one row per server? Withoutit the cursor is name:version and a naive walk counts versions, which is how I
got a wrong number on my first three attempts.
Second, I am planning a liveness pass: initialize plus tools/list against those
12,429 endpoints, read only, no tool calls. What rate would you consider
acceptable? I would rather be told here than find out from someone's error
budget.
Happy to correct anything above. If someone gets a different count I will
publish both.
All reactions