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.
The registry is smaller than it looks
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.
The 2,967 that expose RFC 9728
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%.
It isn't a vendor problem
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.
- 2,823 distinct issuer hosts. The top ten account for 1% of failures.
- 60% run their own authorization server on their own domain.
- Servers delegating to a third-party IdP do barely better: 24% / 25% versus 18% / 23%. The IdPs haven't shipped it either.
So there are roughly 2,610 operators, each of whom would have to do this themselves.
And it isn't really a security story
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.
What I can't tell you
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.
Two things I'd like checked
- If anyone has already published RFC 9207 / CIMD conformance numbers, I'd like to compare. I searched and didn't find any — but "I didn't find it" isn't "it doesn't exist."
- If you run one of these servers and think I've graded you wrong, tell me and I'll recheck and correct the post.
Method is reproducible from the description above; happy to share the raw per-host results with anyone who wants to verify.
Top comments (0)