The official Model Context Protocol registry has quietly become one of the largest machine-readable catalogues in software. On 30 September 2026 it listed 37,745 servers at their latest published version, and 23,348 of those declare a remote HTTP endpoint you can point an agent at today. What it does not tell you is what happens when you actually connect.
So we connected. We drew a random sample of 250 remote servers, sent each one an anonymous MCP handshake, and asked the ones that answered for their tool list. Two thirds answered. Nearly all of those handed over the full inventory of what they can do, with no credential of any kind.
TL;DR
- Of 250 remote MCP servers sampled from the official registry, 161 returned HTTP 200 to an unauthenticated
initializeand 156 completed the handshake. - 153 then returned a complete
tools/listwith no credentials, exposing 1,970 tools. Median 6 tools per server, largest 201. - 74 servers genuinely required authentication. Seven gave a client no machine-readable way to discover how: no
WWW-Authenticateheader, no protected resource metadata document. Every one of them explained it in prose in the response body instead. - Structured output is all or nothing. 37 servers declare an
outputSchemaon every tool, 116 declare it on none, and not a single server sits in between. That is 427 of 1,970 tools, 15 months after the feature shipped. - The registry describes servers. It does not describe their contracts, and you cannot plan an agent’s tool loadout from it.
How we measured it
The sampling frame matters here, because the registry is heavily skewed by bulk publishers. Two accounts alone contributed 4,035 of the 11,623 remote entries updated in September 2026, one of them 2,365 servers behind a single Cloudflare Workers hostname. Counting servers would have measured those two publishers and nothing else.
So we deduplicated by host. Taking the first declared endpoint per server across everything updated in September 2026 gave 6,561 distinct hosts. We drew 250 of them at random with a fixed seed, and probed one server per host.
Each probe sent a single JSON-RPC initialize request declaring protocol version 2025-06-18, from a User-Agent that named REPTILEHAUS and linked to our contact page. Where that succeeded we sent notifications/initialized, honoured any Mcp-Session-Id the server issued, and called tools/list. We did not call a single tool.
The response distribution: 161 HTTP 200, 76 in the 401 or 403 range, 6 other 4xx, 4 5xx, and 3 that never answered at all. Two of the 403s were Cloudflare interstitials rather than the server’s own decision, which leaves 74 servers that deliberately demanded credentials.
What the open two thirds actually expose
Of the 156 servers that completed a handshake, 153 returned a populated tool list to an anonymous caller. Not one returned an empty list. Between them they advertised 1,970 tools: 68 servers with five or fewer, 50 with six to ten, and 11 with more than 25. The largest single surface we saw was 201 tools on one server.
It is worth being precise about what this does and does not prove. An open tools/list is not automatically a vulnerability. Plenty of these servers are deliberately public, and a good number will reject an unauthenticated tools/call even though they describe themselves freely. We did not test that boundary and we are not claiming the tools are callable.
What it does prove is that the tool descriptions, parameter schemas and naming of two thirds of the sample are public information. If you have ever treated your MCP tool surface as an internal implementation detail, and written tool descriptions that name internal systems, environments, table names or business logic, that assumption does not survive contact with the registry. Tool descriptions are prompt input, which means they are written to be explicit, which means they leak.
Only 13 of the 156 issued a session identifier, which tells you most of these deployments are stateless HTTP endpoints wearing MCP as a thin adapter over an existing API.
Seven servers want a key and will not tell a machine which one
This is the finding that should worry anyone building agent infrastructure, because it is a spec failure rather than a judgement call.
The 2025-06-18 revision was unambiguous: “MCP servers MUST use the HTTP header WWW-Authenticate when returning a 401 Unauthorized to indicate the location of the resource server metadata URL.” The current 2025-11-25 revision softens that into a choice, but keeps it mandatory: servers “MUST implement one of the following discovery mechanisms”, either the WWW-Authenticate header or a well-known protected resource metadata URI.
We checked both. Of the 74 servers that demanded credentials, 62 provided both mechanisms, five provided the header only, and seven provided neither. That is just under one in ten of the authenticating servers in our sample, unreachable by any client that follows the specification.
The detail that makes it memorable is what those seven sent instead. One returned {"error":"Missing API key. Pass it in the X-API-Key header."}. Another listed its accepted schemes in a JSON array of English sentences. A third returned its instructions in Mandarin, telling the caller where to register for a key. The information is all there. It is simply addressed to a person, in a channel where the only reader is a program.
That is the whole gap in one line. These servers were built by teams who tested them by pasting a token into a config file, which works perfectly, and which is exactly the workflow the protocol’s own roadmap has been trying to design out. We wrote about that roadmap in August, in the parts of your agent stack it quietly deprecates. Agent identity was the widest gap between specification and deployment then. It still is.
Structured output is a framework decision, not a tool decision
Support for structured tool output landed in the 2025-06-18 revision, listed under major changes as “Add support for structured tool output”. A tool declares an outputSchema, returns structuredContent, and the calling model gets typed data instead of a wall of prose it has to parse with a guess.
Fifteen months later, 427 of the 1,970 tools we enumerated declare one. That is 21.7%.
The distribution is the interesting part. Across 153 servers, 37 declare an output schema on every single tool and 116 declare one on none. Zero servers are partially adopted. Not one team has shipped a mixed surface.
A number that clean is never a product decision. It is an SDK default. Teams are getting structured output because the framework they picked generates it from their type definitions, or they are not getting it because their framework does not, and in neither case did anyone sit down and choose. Your agent’s data quality is currently being decided by whichever library was top of the search results on the day someone started the spike.
This is the practical cost of the complaint you hear from harness authors: that MCP servers return text tuned for token efficiency rather than data you can compose. The registry now has a number attached to it, and the number is 78% of tools returning something your model has to interpret rather than consume.
What to do with this
- Audit your own tool descriptions as public text. If your MCP server is in the registry with a remote endpoint, assume its full tool inventory is already indexed. Strip internal hostnames, environment names and schema details out of descriptions.
- Implement both discovery mechanisms, not one. The spec permits either, but clients in the wild are inconsistent about which they try first. Serving the header and the well-known URI costs an afternoon.
- Check what your SDK does with
outputSchemabefore you pick it. It is an all-or-nothing property of your framework, it determines how reliably your agent can chain tool calls, and it is expensive to retrofit across a 40-tool surface. - Pin third-party servers by more than a registry name. Nothing in the registry entry tells you whether the endpoint requires auth, what it will return, or whether it still exists. Three of our 250 did not answer at all.
- Probe before you integrate. A ten-line handshake script tells you more about a candidate MCP server than its registry listing, its README and its landing page combined.
REPTILEHAUS builds agent infrastructure, MCP servers and the authentication and DevOps work that makes them safe to expose. If you are wiring an agent to third-party tools and cannot currently answer what each of them returns or who can call it, get in touch.
Survey conducted 30 September 2026 against the public registry API at registry.modelcontextprotocol.io. Sample: 250 hosts drawn with a fixed seed from 6,561 distinct hosts across remote servers updated in September 2026. Probes were limited to initialize, notifications/initialized and tools/list from an identifying User-Agent; no tool was invoked. The registry changes daily, so re-run the probe before quoting these figures.
📷 Photo by rc.xyz NFT gallery on Unsplash
