I scanned every server in the official MCP registry and checked the ones that advertise OAuth against the 2026-07-28 authorization requirements.
Read-only throughout: one initialize per host to see what it answers, then public metadata documents. No tool calls, no auth attempts, no probing.
105,315 entries are 32,380 unique servers — the registry keeps every version of every server, so entry counts overstate the ecosystem by about 3.2x. (Someone else counted this three days before me and got the same ratio, which is a good sign for both of us.)
Of those, 19,789 advertise a remote endpoint, across 13,088 unique hosts.
I asked each host to initialize:
| answered something | 12,282 (94%) | | completed an anonymous handshake | 6,957 (53%) | | returned 401/403 | 4,020 | | didn't connect at all | 806 |
Median response 811 ms.
Of the servers demanding auth, 2,967 pointed at protected-resource metadata. Those are the ones worth grading — they implemented OAuth on purpose.
| check | pass |
|---|---|
| PRM document present | 97% |
resource matches the server (audience binding) |
96% |
| authorization server metadata reachable | 96% |
| PKCE S256 | 95% |
| issuer is HTTPS and self-consistent | 94% |
| dynamic client registration | 92% |
RFC 9207 iss |
19% |
| Client ID Metadata Documents | 23% |
| all of the above | 8% |
The older OAuth machinery is in good shape. The two things the July spec newly hardened are not.
That shape matters more than the 8%. This isn't "nobody cares about security" — it's a migration that hasn't happened. Everything from before is above 92%; the two 2026-07-28 additions sit at 19% and 23%.
I expected the failures to pile up on a handful of identity providers, which would make this someone else's bug to fix. They don't.
So there are roughly 2,610 operators, each of whom would have to do this themselves.
While looking into this I found a maintainer's issue titled: "OAuth AS proxy: support Client ID Metadata Documents (CIMD) and RFC 9207 iss so ChatGPT/Claude can connect without DCR"
CIMD is the spec's preferred registration path now, with DCR as the fallback. If you skip it you're not just weaker — depending on the client, you may not be reachable at all.
I read declarations, not behavior. Credential reuse across issuers, issuer-bound client credentials, and whether a server actually validates token audience don't appear in metadata. A server that doesn't declare RFC 9207 support is certainly not doing it; one that declares it might still get it wrong.
So 19% is a ceiling, not a floor. The real conformance rate is at most this, probably lower.
The population is biased the same direction: these are servers whose operators implemented OAuth deliberately. Servers that skipped auth entirely aren't in this count at all.
Method is reproducible from the description above; happy to share the raw per-host results with anyone who wants to verify.