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

Correction (2026-09-19). I framed RFC 9207 iss and Client ID Metadata Documents as July-spec requirements. They are SHOULD, not MUST — and the CIMD SHOULD applies to authorization servers and clients, not to MCP servers. DCR is deprecated but explicitly kept for backwards compatibility, with no sunset date. Claude's connector docs also state that when CIMD is absent it falls back to DCR, so "may not be reachable at all" was wrong; a DCR-only server connects fine today. The nextcloud issue I quoted was about a broken registration_endpoint, not about CIMD being required — I misread it.

The numbers stand (19% / 23% / 8%). The right reading is: most servers haven't adopted the two July recommendations yet, which the spec itself expects to upgrade to MUST in a future revision. Servers with neither CIMD nor a working DCR endpoint — the only ones actually at risk — are about 57 of 2,967 (1.9%). Title left as-is so the link doesn't break; the body below is unchanged so the correction is visible against it.

Thanks to no one but my own re-read for catching this — which is the point of posting numbers publicly.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:

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.

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

1. 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."
2. 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.