Tens of thousands of remote MCP servers are now listed in the official MCP Registry. An agent can only use one of them if a few basics work. The server has to answer, say which protocol revision it speaks, list its tools in a form the agent can read, explain how to authenticate when it needs credentials, and report errors so the agent can tell a call failed.
We measured how often those basics hold. In a pre-registered study, Remote MCP Server Reliability, we probed a random sample of 3,000 remote endpoints from the registry, using only protocol and metadata requests.
The short version: most servers get the basics right, but error reporting is the weak spot, and very few have moved to the current protocol revision yet.
One in four MCP servers that answered our call to a non-existent tool did not return an error an agent can recognise. 272 of them replied HTTP 200 as if the call had worked. For an agent, a failure that looks like a success is worse than a failure.
What We Did
On 12 October 2026 we took a snapshot of the official MCP Registry: 26,365 unique remote endpoints after de-duplication. We drew a simple random sample of 3,000 with a fixed seed. They came from 2,245 different hosts.
Our probe followed the backward-compatibility procedure in the MCP 2026-07-28 specification:
- It first tried the modern
server/discoverrequest, with per-request_metaand headers. - If that failed, it tried the legacy
initializehandshake, using sessions where the server issued them. - Otherwise it checked for the deprecated HTTP+SSE transport.
For servers that completed a handshake, it listed their tools and made one call to a tool that doesn't exist, to see how the error came back. For servers that wanted authentication, it fetched their RFC 9728 protected-resource metadata.
We never called a real tool and never sent a security payload. Each endpoint got at most 8 requests, one endpoint per host at a time. The probe identified itself as GlintbaseResearch/1.0 and linked to our bot page, which has an opt-out.
We validated the classifier on 30 endpoints, stratified by outcome. A separate minimal client agreed automatically on 23 of 30. All seven disagreements traced back to limitations of that deliberately simple client, and after reviewing them against the raw logs we agreed on all 30. The reviewer also wrote the probe, so this is a documented self-check, not an independent audit.
Finding 1: Most Listed Servers Work
- 95.3% of endpoints were reachable, and 87.1% answered as MCP servers.
- 56.9% (55.2–58.7) completed a handshake and listed their tools without credentials.
- 24.2% required auth and gave a challenge an agent can follow.
- Smaller groups were unreachable (4.7%), weren't MCP servers at all (4.1%), or demanded payment with HTTP 402 (2.1%).
Some hosts publish hundreds of endpoints, and the largest accounted for 261 in our sample. Counting each host once, the share that worked anonymously is 48.1%.
Finding 2: Auth Is Mostly Done Right
29.3% of endpoints required authentication. Of those, 82.7% (80.0–85.0) returned a challenge an agent can actually follow: a Bearer WWW-Authenticate header plus valid RFC 9728 protected-resource metadata, which tells a client where to get a token.
That's better than we expected. It means most auth-gated servers can, in principle, be connected to by an agent without a human reading setup docs.
A compliant challenge only shows the front door is labelled correctly. It says nothing about whether the server checks that a token was issued for it. In both official MCP SDKs, the fix that checks a token's audience is currently opt-in: the security advisories published in early October say upgrading alone doesn't turn it on. That check isn't visible from outside, so our study couldn't measure it.
Finding 3: Tool Schemas Are Strong, Safety Annotations Are Patchy
Among the endpoints that listed tools anonymously:
| Metric | Value |
|---|---|
| Median number of tools (first page) | 9 |
| Every tool strictly typed | 98.7% |
| Every tool described | 100% |
At least one readOnlyHint declared | 56.7% |
At least one destructiveHint declared | 50.5% |
Schemas are close to universal, probably because SDKs generate them. Safety annotations are not. They're what lets an agent, or the person supervising it, tell a lookup from a delete before calling it, and about half of servers don't declare them on any tool.
Finding 4: One in Four Servers Can't Report an Error
We asked every server that completed a handshake to call a tool that doesn't exist. 75.1% answered in-channel, with a JSON-RPC error or a result marked isError: true. Of the 442 that didn't:
- 272 replied HTTP 200 with no error signal. Any error message was buried inside normal content.
- 133 returned a bare HTTP 404, outside the protocol.
- The rest asked for auth, rate-limited us, or did something else.
This matters more than it looks. An agent decides what to do next from the response. A 200 with no error flag looks like success, so the agent may carry on with a result that doesn't exist, and nothing in the response tells it to stop and retry.
Finding 5: The Current Protocol Revision Is Still Rare
Of the 1,772 endpoints that completed a handshake, only 13.3% spoke MCP 2026-07-28, the stateless revision that replaces the initialize handshake with server/discover. A quarter of those also accept older revisions.
2026-07-28 was published about 11 weeks before we collected data, so this is an early snapshot. Since then, the MCP project's reference servers moved to it with their v2.0.0 release on 19 October. We plan to re-probe the sample in a few weeks to see how fast adoption moves.
This finding applies to us too. The ARS scanner's MCP probe still detects the new revision through initialize, which 2026-07-28 removed. The study harness does it correctly, but the scanner doesn't yet, so ARS can misjudge fully modern servers. Porting the study's probe into the scanner is first on the list for the next ARS release.
What This Means If You Run an MCP Server
- Return errors in-channel. An unknown tool, bad arguments or a failed call should produce a JSON-RPC error or
isError: true, never a 200 with an error message in the text. - Annotate your tools. Mark read-only tools
readOnlyHint: trueand anything that changes or deletes datadestructiveHint: true. - If you require auth, publish RFC 9728 metadata and send a
Bearerchallenge pointing to it, as 82.7% of auth-gated servers already do. - Plan your move to
2026-07-28, and keep answering older clients while they're still common. - If you use the official SDKs, turn on token audience validation. It's off by default in current releases.
Limitations
- One registry. Listings in the official MCP Registry are unvetted. Other registries weren't included.
- One vantage point, back-to-back rounds. Re-probing immediately gave the same classification for 99.6% of endpoints, after excluding one host whose anonymous quota our own probing had used up. Stability over days or weeks isn't measured.
- First page of
tools/listonly. - Some "failures" are deliberate, such as paid endpoints (HTTP 402) and servers that expect configuration headers declared in their registry entry.
- We changed one result ourselves. Across the study's rounds, including discarded ones, we used up one gateway's free daily anonymous quota, and it then correctly began asking for auth. Future rounds will cap requests per host per day below published quotas.
Read the Full Study
- Report: Remote MCP Server Reliability (2026)
- Pre-registration, data and harness: github.com/Glintbase/research
- Our crawler: GlintbaseResearch bot page
The report names no servers, and raw responses aren't published. Any security-relevant observations go privately to the maintainer, never into a public list.
Disclosure: Glintbase sells agent-readiness scoring (ARS), which includes MCP checks. This study was pre-registered before data collection, and its three deviations are logged in the pre-registration.
Run a Free AI Readiness Audit
Identify broken parameter signatures, missing Model Context Protocol schemas, and sitemap issues in your developer documentation.
