15% of MCP endpoints that require authentication serve their tool list anyway.
Measured 11 and 12 September 2026. One probe per endpoint, at most one per publisher domain. No endpoint is named here and none ever will be.
It previously led with "45% of remote MCP endpoints serve their tool list to anyone". That figure was accurate and misleading. 80% of remote MCP connectors declare no authentication at all, so for most of that 45% the behaviour was the documented configuration rather than a fault. The finding that survives is narrower and stronger, and it is below. The old framing is kept at the bottom of this page rather than deleted.
The finding
We sampled 119 remote MCP endpoints that declare authentication — OAuth2
or API key, according to the operator's own registry classification — at most one per
publisher domain, and sent each a single initialize followed by
one tools/list with no token.
| Outcome, of 117 conclusive | Count |
|---|---|
| Served the tool list to an anonymous caller | 18 |
| Refused, with no RFC 9728 challenge a client could follow | 19 |
| Refused correctly, with metadata that resolved | 79 |
| Advertised metadata that would not fetch | 1 |
These are servers whose operators chose to require credentials. There is no reading of this where the tool list was meant to be public. 37 of 117 have something wrong — 18 that leak it outright, 19 that refuse in a way no compliant client can act on.
Major vendors do not have this problem
We ran the same probe against the first-party MCP endpoints of twelve large SaaS vendors that document an OAuth requirement, one request each.
| Probed | 12 |
| Conclusive | 11 |
| Served the tool list anonymously | 0 |
| Refused with no followable challenge | 1 |
Zero. Every vendor endpoint that answered enforced the authentication it documents. The failures are not in the platforms with security programmes. They are in the long tail: servers built by individuals and small teams who enabled OAuth and did not check what the endpoint discloses before it.
Why the earlier framing was wrong
This page first reported that 45% of remote MCP endpoints serve their tool list to an unauthenticated caller. That measurement was correct as run. The framing was not.
Of 20,492 remote MCP connectors in the largest public index, 16,375 declare no
authentication at all. For four fifths of the population, answering
tools/list without a token is the documented configuration. A
measurement that counts those as findings is measuring a design decision and calling it a
fault. Restricting the question to endpoints that claim to require credentials is what
makes the number mean something.
Context: the shape of the population
Publishers are not evenly sized, though far less unevenly than the raw listing counts suggest. 90% of domains expose exactly one endpoint. The largest genuine fleet is 213 distinct endpoints, then 125, then 94, then a steep drop to 24.
The practical consequence: an organisation with one endpoint can check it in a second with a free command. An organisation with 213 cannot check them by hand, and cannot tell its own customers anything credible about their posture without continuous evidence.
This section first said the largest publisher listed 763 endpoints, and the population block said 4,942. Both counted registry listings rather than endpoints. The registry permits the same URL to be listed repeatedly: those 764 listings are 3 distinct URLs, and one domain lists a single endpoint 204 times. The rate is unaffected, because the sample drew at most one endpoint per publisher domain and probed 100 distinct URLs. The population described around it was wrong and is corrected here.
Limits, which apply to every number here
- One endpoint per publisher over-weights small publishers relative to the endpoint population. An endpoint-weighted rate would be a different number and we have not measured it.
- Registry listing is itself a filter. Endpoints never published to the registry are not represented.
- One probe, one timestamp, one network position. An endpoint can serve a clean refusal to a known prober and its tool list to everyone else. We reproduce this in our own testing; it is inherent to remote black-box probing.
- Some of the 45 are public on purpose. A genuinely public tool surface is a design choice, not a defect. This measurement reports what was observed; it does not decide what was intended.
- An earlier 40-of-74 figure remains withdrawn and is not restated here. Its receipts recorded no response bodies, so it cannot be recovered. That the two rates land near each other is not evidence of agreement.
Check your own
uvx x190 check https://your-host/mcpThe tool is free and always will be. If you are running more endpoints than you can check by hand, or you want the questions the probe deliberately refuses to answer — whether a token is actually validated rather than merely required, whether scopes are enforced per tool — that is what we sell.
How much of the registry actually exists
A separate counting exercise, DNS only, no endpoint contacted: 60% of remote listings in the registry are duplicate URLs, and 7.2% of hostnames do not resolve at all. Read that report. It is where the correction above came from.
Method and raw evidence
The probe, its test suite and the full methodology are public: EVIDENCE.md ↗. Every way this probe can be evaded or misled is documented in the methodology honesty ↗ section, including the ones that make our own numbers weaker.
Per-endpoint results are not published and will not be. Naming a third party's failing endpoint is a disclosure matter handled privately with the operator, not a marketing asset. Aggregate rates and methodology are the finding.