Since May 2025, the MCP spec repo has carried an open question (#540): should an MCP server expose what it offers before a client authenticates? The thread ran on principle for more than a year — self-description versus auth boundaries, discoverability versus least exposure. This week it finally got data, and the data changes the shape of the argument.
This post covers the measurement from the probe side and adds the view we don't usually get in these threads: what a server directory sees when it tries to describe MCP servers at ecosystem scale.
The measurement
unempyd probed remote MCP endpoints anonymously — one initialize and one tools/list per endpoint, at most one endpoint per publisher domain — and published the method and results (full report).
The first pass sampled 100 endpoints from the official registry: 45 returned a tool list with no credentials. The correction that followed matters more than that headline. Of 20,492 remote connectors in the largest public index, 16,375 declare no authentication at all. For four fifths of the population, answering tools/list unauthenticated is documented configuration, not a fault — counting those tells you nothing about anything.
The population where the question means something is the 117 endpoints whose operators chose to require credentials (OAuth2 or an API key). Of those:
-
18 served the complete tool list to an anonymous caller — they intend to require auth and don't enforce it on
tools/list - 19 refused, but with no RFC 9728 challenge a client could follow — a refusal no compliant client can act on
- 79 refused correctly, with protected-resource metadata that resolved
- 1 advertised metadata that would not fetch
So roughly 15% of endpoints that intend to require authentication do not enforce it on tools/list, and another 16% refuse in a way no compliant client can act on.
The failure is not distributed evenly either. Against the first-party MCP endpoints of twelve large SaaS vendors that document an OAuth requirement, zero of the eleven that answered served anything. The leaks concentrate in servers built by small teams — precisely where a spec default does the most work, because a default is load-bearing exactly for the people who will not read the spec.
What the directory side sees
We index 69,077 MCP servers from GitHub, npm and PyPI source, 133,426 tracked ecosystem-wide (marketnow.site). Here is the part of the population the endpoint-side probe cannot see: most MCP servers have no reachable remote endpoint at all. They exist as repositories and packages. For the majority of the ecosystem, the only pre-auth discovery surface that exists today is source code and package metadata.
The endpoint question and the discoverability question are already decoupled in the wild. Any answer to #540 that only governs what a live endpoint serves leaves most of the ecosystem exactly where it already is: described by READMEs, package manifests, and static analysis.
A 401 is indistinguishable from a mistake
From the directory side the ambiguity is concrete. When a server 401s an anonymous caller, a crawler cannot distinguish "auth required by design" from "misconfigured" — the operator's intent isn't machine-readable. We classify from source when the endpoint refuses: tools from README and package metadata, install-risk from static analysis, and the listing gets labeled "auth required, not probed." That is a workaround, not a signal. It is honest about what we know, but it cannot tell an operator that their server is one of the 18.
Nothing can, today. That is the part of the closing argument in the thread that cuts across the whole debate: a server that intends to require authentication and fails to enforce it has no mechanism that makes the failure visible to its own operator.
The middle ground that doesn't exist yet
The thread's proposed compromise — an unauthenticated capability manifest rather than the concrete resource list — has a measurable absence. In the first pass, none of the pre-auth servers served anything resembling a manifest. What exists in the wild is binary: full refusal, or the complete callable surface — median 5 tools, maximum 302, 926 tools disclosed across the sample, with names and input schemas included.
A signed manifest with capability names and counts — no input schemas, nothing callable — would resolve both directions at once. Directories could describe a server without its auth boundary leaking anything exploitable. Operators who want discovery would get a channel that doesn't require serving the concrete tool list. And install-risk classification would become substantially less dependent on source analysis, which is currently the only honest fallback.
The RFC 9728 bar
Whatever lands long-term, there is a floor available now: a 401 should publish protected-resource metadata that resolves. Nineteen of the 117 don't even clear that bar. A crawler that understands RFC 9728 can at least record the auth boundary correctly — which is the difference between "auth required, not probed" as a guess and as a verified fact.
What we do meanwhile
Source-first indexing is the strategy regardless of how the spec lands. An auth-gated server still gets a real listing — capabilities, security classification, labeled honestly rather than silently empty. The public submission pipeline validates and lists from source, so a server can be discoverable without ever serving an anonymous endpoint. And the 29 static rules behind the install-risk tiers — injection patterns in tool descriptions, embedded secrets, dangerous APIs — run against source, where the same patterns that poison deployed tool descriptions are visible before anyone deploys.
If pre-auth discovery becomes standard, the 18 stop being a mistake. If it does not, they need something in the protocol that makes the failure visible. Either way, the directory side keeps describing servers from source — because for most of the ecosystem, that is the only side that exists.
Top comments (0)