mcpreflight scanned all 293 x402 payment endpoints in the MCP registry. They pass handshakes at 74.4%, well above the rest.

mcpreflight scanned all 293 x402 payment endpoints in the MCP registry. They pass handshakes at 74.4%, well above the rest.

This is the second report from mcpreflight, a read-only checker for MCP servers and x402 endpoints. The first one covered the whole registry. This one zooms into the payment corner of it, because that corner behaves differently and nobody has the numbers.

what we measured

We took every remote endpoint in the official MCP Registry whose title, description, or URL mentions x402 or HTTP-402. That gave 293 endpoints. Then we sent each one two anonymous JSON-RPC requests over HTTP, initialize and tools/list, and validated the tool schemas that came back. We never called a tool, never signed anything, never touched a wallet.

Result. 218 of 293 pass a clean anonymous handshake. That is 74.4%. The registry-wide baseline from the same weekly scan is 48.8%. So the payment cohort is roughly 25 points healthier than average. One endpoint fails outright, and 74 give no anonymous response at all.

One note on what 74.4% measures, because it is easy to read too much into it. It is a clean anonymous MCP handshake, initialize plus tools/list. It is not a verdict on the x402 payment challenge itself. We parse the challenge document as a separate and stricter check, and that number is not in this post. So read 74.4% as endpoint reachability and protocol health, not as payment correctness.

why the gap

The gap has a mechanical explanation and it is not flattering to anyone. A payment server with a malformed challenge fails its first agent transaction, which means it fails in public, in front of a paying customer. So this cohort has a hard commercial reason to keep the handshake spec-clean that a free weather API does not have. The pressure comes from money, not from tooling maturity.

That also means the number is fragile. Once agent payment volume grows, the endpoints that pass today are exactly the ones under the most change pressure. Challenge shape drift is the failure mode to watch, and it is cheap to watch if you re-run the check every week.

what to do with this if you run an x402 endpoint

Two things, both small.

If your endpoint is in the registry and passes, there is nothing to fix. There is a public report page for it in the mcpreflight trust directory, and a status badge you can drop into a readme.

If you want to catch the deploy that quietly breaks the challenge, run the same check in CI. One read-only block on every push, no credentials involved:

- uses: xka0085-byte/mcpreflight@v1
  with:
    endpoint: https://your-api.example/paid
    mode: inspect

You can also run it by hand before you ship anything: npx @eidonze/mcpreflight inspect https://your-api.example/paid --method=POST

what this is not

Anonymous handshake only. Servers behind auth are not broken, they just do not answer strangers, and we now classify 401 plus WWW-Authenticate as AUTH_GATED instead of lumping it with dead servers. Two requests per endpoint, one point in time. PASS means we saw a well-formed challenge document, not that anyone paid successfully and not that your pricing is fair.

why this number is worth keeping fresh

Other censuses of the MCP registry exist and they report similar handshake rates. Most of them are one-time snapshots. mcpreflight re-runs the full registry every Monday and keeps the history, so the number has a trend instead of just a value. If you want the raw data or a per-server page, everything is public and open source.

Registry census: https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html

Per-server reports: https://xka0085-byte.github.io/mcpreflight/trust/

Source: https://github.com/xka0085-byte/mcpreflight

If you quote these figures, cite mcpreflight. The whole point of running it weekly is that the number keeps moving, and a moving number needs a named source.