Seven In Ten Gated MCP Servers Will Let An Agent In Unaided

We hold 1,661 MCP servers we have proven are real by POSTing a tools/list at them and reading what came back. Of those, 1,055 answer with a 401.

We used to record that as one fact: gated. It is not one fact. It is the start of a chain an agent has to walk, and until last week we had never measured whether the chain completes.

So we walked it, on all 1,052 gated endpoints with a usable URL. Read-only, one POST and a few GETs of public metadata documents, no registration attempted and no token requested.

401  →  resource_metadata  →  authorization_servers  →  AS metadata  →  registration_endpoint

Seven in ten gated MCP servers are not a wall. A 401 from them is an invitation with directions attached: RFC 9728 protected-resource metadata naming an authorization server, RFC 8414 metadata naming a registration endpoint, and RFC 7591 dynamic client registration at the end of it. An agent that speaks those three can get itself a client and keep going.

That is a better state of affairs than “1,055 servers behind auth” suggests, and it is worth saying plainly, because the number of people who assume an authenticated MCP server is a closed door is larger than the number who have checked.

Where the other three in ten break

The failures are not vague. Each one is a specific missing or malformed thing, and we counted them.

The bottom three rows — 51 servers — are broken implementations rather than design decisions. Nobody ships a metadata document that returns 404 on purpose. Somebody built the thing and one pointer does not land.

Here is one, whole, because the shape of it is the point:

POST https://mcp.kinde.com/mcp
→ 401
WWW-Authenticate: Bearer resource_metadata="mcp.kinde.com/.well-known/oauth-protected-resource/mcp"

RFC 9728 wants resource_metadata to be a URI. That is a bare hostname with no scheme, so a client treating it as a URL cannot resolve it — our prober raised unknown url type, which is exactly what an agent’s HTTP library does. And the document is fine:

GET https://mcp.kinde.com/.well-known/oauth-protected-resource/mcp
→ 200
{"authorization_servers":["https://mcp.kinde.com/"],
 "resource":"https://mcp.kinde.com/mcp",
 "bearer_methods_supported":["header","query"]}

Everything is built. Eight characters — https:// — stand between it and an agent that can use it. That is the median shape of a failure at this layer: not an absent capability, a pointer that does not point.

The part where we were the problem

Four dimensions of our own Agent Readiness score measure this layer — Auth Clarity, Protected Resource Metadata, Delegated Identity, Dynamic Client Registration. Twenty-seven of a hundred and thirty-nine points.

All four read a harvested copy of a provider’s .well-known documents. That harvest visits a provider’s primary hosts. MCP auth metadata lives on the MCP host — mcp.example.com/.well-known/oauth-protected-resource — and 98.5% of the documents we found were there, on a host our harvest was not visiting.

Roughly 4,980 points of real agent-readiness capability that our own rating could not see. Those providers stood up an MCP server, put it behind OAuth, served the metadata, and enabled dynamic client registration — the top of the ladder — and we scored them as though they had done none of it.

Kinde is in that column too. Their score says protected_resource_metadata: false. They have been serving it the whole time, at 200, on a host we never asked.

We are fixing the harvest. It is roadmap#321, and it needs no rubric change at all — the endpoint is already recorded in each provider’s MCP manifest, and the harvest simply has to visit it.

Why we are publishing the error alongside the finding

A rating that only ever reports other people’s gaps is a rating nobody should trust. The same week’s work found 292 providers being paid full credit for a tool surface a platform built for them, which we are proposing to correct downward — roadmap#317 — and 918 providers whose own auth work we could not see, which corrects upward. Both come from the same principle, and it is the only one that makes a score worth anything: pay for what the provider actually built.

If you run an MCP server, two things are worth ten minutes today. Fetch your own endpoint with an unauthenticated tools/list and read the WWW-Authenticate header you get back — check that resource_metadata is an absolute URI and that the document it names returns 200. Then check whether your authorization server metadata carries a registration_endpoint. One of those is the difference between an agent getting in by itself and a developer filling in a form at 2am.

Every number here is on disk, per provider, with the rung each one reached and the URL that broke.