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

> Source: <https://dev.to/baramwork/2967-mcp-servers-advertise-oauth-8-meet-the-july-spec-5d1m>
> Published: 2026-09-17 06:04:11+00:00

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.