Three in ten public MCP endpoints ask for a key before anything else
Our probe connects to every endpoint the same way: without credentials. It carries no token and never asks anyone for one. So when an MCP endpoint wants a key before it will even complete the handshake, the probe gets an authentication challenge and stops there.
On 2026-09-30 we were observing 2,282 public endpoints, and their latest runs fell into three groups:
| latest observation | endpoints |
|---|---|
| a tool list was returned and stored | 1,469 |
| the handshake was answered with an authentication challenge | 694 |
| neither: unreachable, or failed in another way | 119 |
The first group is the directory. The second is a separate list. For each endpoint it shows the server’s name, its transport, the endpoint address when we have one, the authentication scheme it named and when we last looked, and it says that no tool list was observed. Nothing on that list is a check result, because we never got far enough to check anything. It is 30 percent of the public endpoints we observe.
What the challenge tells us
A challenge is an HTTP 401 with a WWW-Authenticate header, and the header names a scheme. Of the 694, 690 name Bearer. The other four name two other schemes.
The header can also point to a document that describes the protected resource: which authorization server issues tokens for it, and which scopes it knows. That document is public by design, since a client needs it before it has a token. Our auth_metadata check follows that pointer, without credentials, and looks only at the structure of what it finds:
auth_metadata on the latest run |
endpoints |
|---|---|
| the challenge pointed to a document; we fetched it, it was a JSON object, and the scopes named in the challenge did not contradict the ones it lists | 631 |
| the challenge did not point to any document | 57 |
| the document could not be fetched, was not a JSON object, or contradicted the challenge’s scopes | 4 |
| not checked on that run: one blocked by our connection policy, one out of time | 2 |
So 91 percent of the endpoints that turned us away also told us, in a form we could read, where a client should go next.
What this cannot tell you
It cannot tell you how strong an endpoint’s authentication is. We never hold a token, so we never see the real authentication path run. A well-formed pointer to a well-formed document says the endpoint describes itself correctly to a client that has no key yet. It says nothing about what happens after a key is presented.
It cannot tell you what tools these endpoints offer, or whether they work. For those 694 we have observed a handshake and a challenge, and that is all.
Why we do not ask for keys
A directory that observes without credentials can say the same thing about every endpoint in it: this is what anyone on the internet would see. The moment it holds keys for some of them, that stops being true, and a reader can no longer tell which observations were made with privileges they do not have. That is why the probe observes anonymously, and why endpoints that require a key are on their own list, described only by what they show to a client that has none.
If your endpoint is on that list
The challenge and the document it points to are the first thing any client sees from you. If your endpoint is in the group of 57, your challenge carries no pointer, and a client that starts from the challenge alone, as ours does, has nothing to follow from it. You can see it for yourself: request your endpoint without a token and read the WWW-Authenticate header that comes back.
Where the numbers come from
Read-only queries against the production database on 2026-09-30. Public endpoints are targets whose status is unclaimed, claim pending or claimed. The first two groups are the directory view and the credential-required view; the third is the public targets in neither. The scheme is the one recorded from the challenge on each endpoint’s latest run. The auth_metadata counts are that check’s outcome on the same run.