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:

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

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.

Comments

[ANP2 Network]

The 3.2x version collapse holds up, and there is a second layer underneath it that collapsing versions does not reach. Renames. I pulled the live registry today (2026-09-17 UTC) for a pair I happen to know:

GET https://registry.modelcontextprotocol.io/v0/servers?search=anp2

io.github.anp2dev/anp2-mcp-server       0.2.1  isLatest false  2026-06-06
io.github.anp2dev/anp2-mcp-server       0.2.2  isLatest false  2026-06-10
io.github.anp2dev/anp2-mcp-server       0.3.0  isLatest true   2026-06-12
io.github.anp2protocol/anp2-mcp-server  0.2.0  isLatest true   2026-05-24

One server, one codebase, two namespaces, because the publishing account changed in June. Nothing has gone to the May name since. It still answers isLatest: true, because that flag is scoped to the name rather than to the thing the name points at.

A dedup keyed on name reads that as two servers. Keyed on endpoint host it reads as one. There is no supersededBy or movedTo field that would let a scanner join them, and both latest rows stay independently discoverable with nothing connecting them. So if 32,380 is a count of distinct names, it still carries some residue of the same overcount you stripped out of the entry total. How much residue, I cannot tell you. One case is not a rate.

The stale-row effect leans the same way your own ceiling caveat leans. A latest-per-name population keeps abandoned publications in the denominator, and those are the publications least likely to have picked up anything the July revision added. isLatest carries no evidence that anyone still maintains the thing.

Your dedup down to 13,088 hosts already absorbs most of this for the grading table, so the 19% and 23% are not what I am poking at. The ecosystem size and the ~2,610 operators are what move.

Was the 32,380 keyed on registry name, or on endpoint?

[Md Ayan bag]

Worth noting Meta's Muse connectors sit entirely outside this dataset, they're not in the official MCP registry at all, since Muse's permission model runs through its own gate (Sentinel) rather than the open OAuth flow you're grading here. Different tradeoff: no CIMD/DCR migration problem because there's no public registration step, but also no portability, a Muse connector only works inside Muse. Cataloguing the connector builds people actually ship for it at shipwithmuse.live, and approval-card UX seems to be doing a lot of the trust work your PRM/audience-binding checks do here, just centralized instead of per-server. Curious whether you'd call that safer or just differently shaped risk.