How many MCP servers are alive?

Of 9,991 MCP Registry endpoints scanned in October 2026, 4,879 (48.8%) completed a clean anonymous MCP handshake, 43 failed, and 5,069 (50.7%) gave no anonymous response. Full data and method are on this page.

What percentage of MCP registry endpoints respond?

49.3% of registry endpoints completed initialize plus tools/list anonymously in the October 2026 scan. Smithery-registered endpoints were the weakest cohort: all 213 measured gave no anonymous handshake.

How many x402 servers are in the MCP registry?

293 registry endpoints reference x402 or HTTP-402 payments in the October 2026 scan. They pass a clean anonymous handshake at 74.4% (218 of 293), above the 48.8% registry-wide baseline, because payment-server authors must keep the challenge flow spec-clean for the first agent transaction to succeed.

State of MCP Servers — October 2026

9,991 remote servers from the official MCP Registry, checked read-only. Published 2026-10-11 · updated 2026-10-15 (finding 6) · full per-server directory

How healthy is the MCP server ecosystem in October 2026? We ran a read-only initialize + tools/list check against all 9,991 remote endpoints in the official MCP Registry: 4,879 (48.8%) completed a clean handshake, 5,069 (50.7%) gave no anonymous response, and 43 failed outright. Among responders we logged 46,216 property-level schema findings, and 86% still negotiate the 2025-03-26 protocol revision. Every number is reproducible with one open-source command, and per-server reports live in the Trust Directory.

9,991remote servers scanned

48.8%pass clean handshake

50.7%no anonymous handshake

43fail outright

What we did

We enumerated every active server with a remote (HTTP) transport in the official MCP Registry and sent exactly two JSON-RPC requests to each registered endpoint: initialize and tools/list. We validated protocol negotiation and every tool's input/output JSON Schema. No tool was ever called, no authentication was attempted, no data beyond the handshake was read. The whole thing is open source and one command reproduces any single result:

npx @eidonze/mcpreflight schema <endpoint-url>

Findings

1. Half of the official registry is not usable anonymously. 5,069 of 9,991 remote endpoints (50.7%) did not complete a clean initialize + tools/list handshake. This bucket mixes genuinely broken servers, temporarily down ones, and endpoints that require auth by design — an anonymous check cannot distinguish them, which is itself part of the story: an agent consuming the registry today cannot tell "requires OAuth" from "dead on arrival" without trying and failing.

2. Protocol adoption is badly fragmented. Of the 4,899 servers that negotiated a protocol version, 86% are still on 2025-03-26. Only 101 servers (1% of the registry) run the newest revision (2026-07-28).

Protocol revision	Servers
no handshake	5,092
2025-03-26	4,207
2025-06-18	379
2024-11-05	143
2026-07-28 (latest)	101
2025-11-25 / 2025-11-05	69

3. Schema hygiene is the quiet tax. Among servers that did respond, the dominant schema finding was missing description on input properties — 46,216 property-level findings across the registry. Tool descriptions are what an LLM reads to decide when and how to call a tool; missing ones measurably degrade agent tool selection. 37 servers returned a tools/list that fails JSON Schema validation outright, 23 returned an invalid initialize response.

4. The community index and the official registry disagree. We cross-checked the largest community awesome-list (4,150 GitHub repo links) against registry data: only 202 of its links correspond to servers we have registry scan coverage for, and 95 of those currently fail a clean handshake. Discovery is fragmented across at least two inconsistent indexes.

5. A third-party proxy sits inside the official registry. 213 registry entries (2.1%) do not point at a maintainer's own server but at server.smithery.ai proxy URLs. All 213 refused an anonymous handshake — 0% completed initialize + tools/list, against a 49.7% no-handshake baseline across the other 9,778 endpoints. Most of that gap is by design: the proxy expects a per-server config and key. The consequence is the same either way: an agent, or any independent auditor, following the official registry cannot verify these 213 servers at all without first signing up with a third party — and cannot tell auth-by-design from dead-on-arrival, the same blindness we found registry-wide, here concentrated in one vendor's corner of the index. We started this comparison after a maintainer flagged auto-registered placeholder entries (kirbah/mcp-youtube#290); our data cannot confirm or refute what sits behind the proxy, only that it is unverifiable from the outside.

6. The x402 economy is already inside the registry — and healthier than average. 293 endpoints reference x402 / HTTP-402 payments in their registry metadata. They pass a clean anonymous handshake at 74.4% (218 of 293), against a 48.8% registry-wide baseline; 74 remain unverifiable anonymously and 1 fails outright. The gap has a mechanical explanation: a payment server whose challenge flow is malformed fails its first agent transaction, so this cohort ships cleaner handshakes. As agent-payment volume grows (Coinbase's x402 protocol crossed 138M reported transactions), this is the cohort where challenge-shape drift and misconfiguration will concentrate — 74.4% is today's baseline, and we now track challenge-shape drift on these endpoints as a dedicated check.

Limitations (read this before quoting us)

Anonymous handshake only. Servers behind OAuth are not broken — but the registry does not label them, so the 50.7% figure is an upper bound on breakage, not an exact count.
Static schema checks do not predict model tool selection and do not prove behavior across clients.
One point in time (2026-10-11), re-scanned weekly; per-server history and diffs are planned.
If your server is listed as "no handshake" and requires auth by design: that's expected — you can ignore it, or reply on the directory to be excluded.

For server maintainers

Check your server in one command. If your endpoint is auth-gated, nothing to do. If it should be reachable anonymously and isn't, the report shows the failing step. A green badge is available for every passing server:

npx @eidonze/mcpreflight schema https://your-server.example.com/mcp

Browse all 9,991 reports in the Trust Directory, or read the mcpreflight docs. The directory is regenerated weekly from the live registry.

Cite this data

These numbers come from mcpreflight's own weekly scan and are free to reuse under MIT. Please attribute them to mcpreflight, not to a general "an audit found". The canonical citation is:

mcpreflight, "State of MCP Servers - October 2026", 2026-10-15,
https://xka0085-byte.github.io/mcpreflight/state-of-mcp-2026-10.html

Canonical figures, use these exact numbers and this exact wording so the industry shares one baseline: 9,991 remote endpoints scanned, 48.8% pass a clean anonymous handshake. Sub-figures: 43 fail outright, 293 x402 endpoints pass at 74.4%, 213 smithery-proxied endpoints pass at 0%. Our definition of "remote endpoint" is a server in the official MCP Registry with an HTTP transport that currently accepts requests, which is why our count differs from the 10,700 to 44,464 figures reported elsewhere.

Produced by mcpreflight — read-only trust checks for MCP and x402 endpoints. MIT licensed, zero dependencies. Corrections welcome via issues.