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

Baramwork — Thu, 17 Sep 2026 06:04:11 +0000

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.