State of the MCP Registry, week of 2026-10-19
by ka, mcpreflight
Every Monday we re-scan the whole official MCP Registry with a read-only check. We send an initialize request, then a tools/list request. We never call a tool, never use a credential, never attempt a payment, and never retry a failing endpoint into apparent health. Everything below is reproducible with one open-source command, and the per-server reports and raw JSON are published.
Headline
Of 9,991 remote endpoints in the official registry, 4,783 complete a clean anonymous handshake. That is 47.9 percent. The remaining 5,208 split into three groups that are not the same thing and should stop being reported as one number.
3,171 endpoints require authentication by design. They answer an anonymous request with 401 and a WWW-Authenticate header, and several publish RFC 9728 protected-resource metadata. These are not broken. We report them as AUTH_GATED as a first-class status.
1,984 endpoints give no anonymous response at all. Some are auth-gated without advertising it, some are simply down. From outside we cannot separate those two, and we say so rather than guess.
53 endpoints fail outright.
The published figure from earlier in October was 4,879 clean handshakes, or 48.8 percent. That number was computed before authentication was split out as its own status, so endpoints that require a login were counted as having given no anonymous handshake. Both numbers are correct for the status scheme in force when they were produced, and the weekly series now uses the split scheme.
Paid endpoints and the shape of the 402 challenge
We also probe the x402 payment endpoints found in the registry, read-only, and fingerprint the challenge each one returns. Two numbers are reported on purpose and must not be conflated. Real 402 counts endpoints whose paid resource answered with a 402 status at all. A valid challenge counts only those whose 402 also named the scheme, the network, the amount and where to pay.
Cohort of 293 endpoints, two consecutive weeks:
week cohort clean handshake rate auth gated no response failed
2026-10-15 293 218 74.4% 0 74 1
2026-10-19 293 212 72.4% 2 78 1
The same seller cohort lost two points of handshake success in one week. A 402 status on its own is not a working challenge, and a single handshake pass rate hides that gap, which is why we report the challenge shape separately.
What a server costs you before you ask it anything
On a reachable endpoint, the tools/list payload is what a client loads into context before the user has typed anything.
Median: 1,663 tokens
Heaviest observed: 245,006 tokens, on a server advertising 281 tools
Endpoints above 10,000 tokens: 479
Endpoints above 20,000 tokens: 138
Method limit, stated plainly: tokens are estimated as payload bytes divided by four, because we do not run a model tokenizer. Treat these as an order of magnitude, not a precise count.
Method and limits
Read-only. initialize and tools/list, or a discovery request. No tool is invoked, no credential is used, no payment is attempted.
Endpoints behind authentication are classified, never counted as failures.
Discovery of paid x402 resources is partial by design, because /.well-known/x402 is not universal, so the paid cohort covers only endpoints that publish their paid resources.
A single week can include transient network failures. The weekly series is the signal, not any individual scan.
Reproduce
Plain Text
1
2
npx @eidonze/mcpreflight schema
npx @eidonze/mcpreflight baseline
Per-server reports and JSON: https://xka0085-byte.github.io/mcpreflight/trust/
Citation
ka, mcpreflight, "State of the MCP Registry, week of 2026-10-19", https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html
If you quote these figures, cite mcpreflight. The weekly cadence is the point: this is a time series, not a one-off audit, and the two-week x402 movement above is only visible because the same cohort is re-probed every week.
Top comments (0)