2,967 MCP servers advertise OAuth. 8% meet the July spec.

A developer scanned the official MCP registry's 32,380 unique servers and found that of the 2,967 advertising OAuth, only 8% meet all of the July 2026 authorization spec requirements. While older OAuth mechanisms pass at rates above 92%, the two newly hardened additions — RFC 9207 `iss` and Client ID Metadata Documents — pass at just 19% and 23% respectively, a gap the developer attributes to an incomplete migration across roughly 2,610 operators rather than indifference to security.

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 https://dev.to/leroy jenkins 951c84b2838/i-counted-the-mcp-registry-101219-entries-are-31309-servers-and-23-have-no-source-repo-33a6 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.