1,000 Public MCP Servers Checked: 55% Complete a Handshake

We wanted one number we had not seen published with its data: of the remote MCP servers listed in the official registry, how many actually answer a client that shows up with no credentials? On November 5, 2026 we fetched the whole registry, 57,041 servers of which 38,270 declare a remote endpoint, drew a fixed-seed sample of 1,000 endpoints with at most two per hostname, and sent each one a standard initialize request. 550 answered with a valid handshake. 338 replied that we needed to authenticate. 42 answered with something that was not MCP, 31 returned another HTTP error, 29 failed at DNS or TLS and 10 timed out at 20 seconds.

The number this page is careful never to print is "45% of MCP servers are broken". Asking for credentials is what a protected server should do, so the 338 are their own category, and the honest failure count, 112 of 1,000, covers endpoints that did not resolve, did not negotiate TLS, timed out, or returned a web page, a 404 or a 5xx where a JSON-RPC result should have been. Even that figure is a sample of one afternoon from one network, which is why we ran it twice: 991 endpoints gave the same outcome both times.

This is a measurement, not a review. A registry listing is not an endorsement, answering is not a quality signal, and no server is singled out here for failing. The one server named below is named because it had the largest tool list in the sample. The dataset, both rounds and the standard-library Python script are published in section 08; our MCP adoption statistics page carries the registry's growth figures that this census does not repeat.

The official MCP Registry exposes a paged API at /v0.1/servers. At 12:51 UTC on November 5 it returned 216,306 version records across 2,164 pages. Keeping the record the registry flags as the latest version of each server leaves 57,041 servers. Of those, 38,270 declare at least one remote endpoint, 39,182 remote rows in total, each with a transport type, a URL, any headers the publisher declares and whether those headers are marked required. The rest are packages to run locally, which this census does not touch.

Some remote URLs contain placeholders for a tenant or region, so we dropped those and kept the 38,788 unique transport-and-URL pairs that can be called as written. From that pool we drew a random sample of 1,000 with a fixed seed, 20261105, and a cap of two endpoints per hostname so that one platform hosting thousands of tenant endpoints could not dominate the result. The sample covers 974 hosts and 997 distinct registry names; 970 endpoints are streamable HTTP and 30 are the older SSE transport; 989 are marked active in the registry and 11 deprecated.

Each endpoint got the same light sequence: one initialize request offering protocol version 2025-11-25 with an identified user agent and no credentials, the initialized notification, a tools/list call paged up to three times, and a session delete where the server had issued a session id. Streamable-HTTP endpoints also received one server/discover request under the 2026-07-28 revision, which replaced the handshake, to see whether the newest method is served yet. No tool was ever called, and no endpoint received more than about eight requests in a round. For what the July revision changed and why servers might lag it, see our stateless migration guide.

Every endpoint lands in exactly one of six categories per round. An endpoint is ok when its initialize reply is a JSON-RPC result that carries a protocol version. It is auth_required when the reply is HTTP 401 or 403 or carries a WWW-Authenticate header; in round 2 that was 305 WWW-Authenticate headers, 22 bare 401s, 5 bare 403s and 6 SSE streams refused with 401. It is a protocol_error when the server answers but not with MCP: a JSON-RPC error object, an HTTP 400, 404, 405, 406, 415 or 422, or a 200 whose body is not an initialize result. The remaining three are infrastructure: other HTTP statuses such as 402, 410, 5xx and Cloudflare's 52x codes; DNS or TLS failure; and a 20-second timeout.

In round 1 the split was 550, 338, 42, 31, 29 and 10. In round 2 it was 551, 338, 42, 28, 32 and 9. The chart shows round 1 as shares of the 1,000. An example of the right reading: 88.8% of sampled endpoints are up and either answered the handshake or asked for credentials. The failure case is reading the 45% that did not complete the handshake as 45% broken, which folds 338 correctly protected servers into the failures.

The table below is the summary file rendered as rows: the six outcomes, the protocol versions the ok servers negotiated, the server/discover results on the 970 streamable-HTTP endpoints, the tool-count and latency figures, and the round-to-round agreement. Each row is a count from the published summary, and the per-endpoint CSVs let anyone recompute any of them.

A third of the sample, 338 endpoints, refused the anonymous handshake and said so properly. That figure was identical in both rounds, and 305 of the 338 sent a WWW-Authenticate header, the challenge the specification's authorization flow starts from (303 with HTTP 401, 2 with HTTP 200); we recorded the header's presence, not its contents. We did not follow those challenges, request tokens or try any credential, so this census says nothing about whether those 338 servers work once a user signs in. It says they are up and gatekeeping.

What the registry says about authentication and what the servers do are different things. Publishers can declare headers on a remote entry and mark them required. Only 89 of the 1,000 sampled entries carry such a declaration. Of those 89, 48 did ask for authentication, but 26 completed the handshake without it, 6 failed at DNS or TLS and the other 9 were protocol or HTTP errors. Among the 911 entries declaring no required header, 290 demanded authentication anyway. An example of the right use: a client that wants to know whether a server will need a login should ask the server, not the registry metadata. The failure case is a tool picker that filters the registry on the declared-headers field and believes the result.

The 2026-07-28 server/discover probe, which goes out without credentials too, drew an authentication response from 368 of the 970 streamable-HTTP endpoints, 322 of which (323 in round 1) were among the 332 streamable endpoints that had also answered the initialize with 401, 403 or a challenge. The two methods agree closely on who is gatekeeping. Our MCP security incident ledger is the right page for what has gone wrong when servers did not gatekeep; this one only counts who does.

Our client offered protocol version 2025-11-25, the newest revision that still uses the initialize handshake. A server that supports it echoes it back; a server that does not proposes an older version. Of the 550 endpoints that completed the handshake in round 1, 423 (76.9%) returned 2025-11-25, 88 (16.0%) returned 2025-06-18, 18 returned 2025-03-26, 18 returned 2024-11-05, the original revision, and 2 returned 2026-07-28 to a legacy initialize call. One server returned the string 2025-11-05, which is not a revision we recognise; we report it as received. Round 2 was identical except that one more endpoint negotiated 2025-03-26.

The newest revision, 2026-07-28, removed the stateful handshake in favour of a server/discover method, so we also sent that to every streamable-HTTP endpoint. 140 of 970 answered it correctly in round 1 and 141 in round 2, and 139 of those listed 2026-07-28 among their supported versions. 192 returned JSON-RPC error −32601, method not found, which is the signature of a server that speaks MCP but has not been updated for the July revision. 117 returned −32000, a server-defined error, and 34 returned −32600, invalid request. 137 endpoints were ok on both the legacy handshake and the new method, which is the group a client can talk to either way.

Read as adoption, roughly one in seven public streamable endpoints had moved to the stateless method fourteen weeks after the revision shipped, while three in four still answer the handshake at the revision immediately before it. Whether that is slow or fast depends on the SDK release cadence behind those servers, which this census did not record; our note on SDK conformance tiers explains why server versions trail the specification.

After a successful handshake we asked each server for its tool list, following up to three pages of results. 544 of the ok endpoints returned one in each round; 6 in round 1 and 7 in round 2 failed on that second call after a successful initialize. The median server lists 7 tools. 219 list between one and five, 246 between six and twenty, 59 between 21 and 50 and 19 more than 50. One server returned an empty list. Nine servers listed 100 or more tools; the largest, TinyFn's all-functions endpoint, listed 572, and the 544 lists together held 7,822 tools (7,727 in round 2).

Initialize latency is measured on our side from opening the connection to receiving the handshake reply, so it includes DNS, TLS and the server's work. In round 1 the median across the 550 ok endpoints was 263.5 ms and the 90th percentile 922 ms: 196 answered in under 200 ms, 213 in 200 to 500 ms, 88 in 500 to 1,000 ms and 53 took a second or more. Round 2 was slower across the board, median 374 ms and p90 1,289 ms, with the slowest single reply at just under 27 seconds. We do not know whether the shift was on the servers' side or ours, and a single vantage point cannot tell. The reliability framework in our MCP server SLO design guide treats these as the kind of numbers an operator should collect continuously rather than once.

Round 2 started at 13:48:03 UTC, 46 minutes and 1 second after round 1 finished, and probed the same 1,000 endpoints in the same order. 991 produced the same outcome category. Of the 9 that changed, 7 crossed the line between ok and not ok: two endpoints that had timed out answered, one that had returned a Cloudflare 530 answered, one that had returned a 503 with no healthy upstream answered, and three that had answered in round 1 failed in round 2, two at DNS resolution and one on the timeout. The other two moved between non-ok categories, one from auth_required to a DNS failure and one from another HTTP error to auth_required.

An example of the right inference: the headline shares are stable to within a point over an hour, so a reader can quote 55% without worrying that a different minute would have given 50% or 60%. The failure case is treating 991 of 1,000 as a reliability figure for MCP servers in general. Two probes an hour apart from one network cannot distinguish a flaky server from a flaky route to it, and we name none of the nine.

Everything above can be re-derived from the two round files and the summary. The rows below state how the census was run and what it cannot tell you.

Download round 1 and round 2 (1,000 rows each: transport, URL, HTTP status, outcome, a trimmed detail string, negotiated protocol version, server name and version, tool count, initialize latency, and the server/discover status, outcome and supported versions), the sample with each endpoint's registry fields, and the summary file with every count on this page. The checker is a single standard-library Python script; the registry API is public.

Three uses, and one misuse. First, as a baseline: if your own agent platform connects to registry-listed remote servers, an unauthenticated first-contact success rate around 55%, with another third needing a login flow, is what the public population looked like on November 5, 2026, and a connector that assumes every listed URL will answer is designed for a world that does not exist. Second, as a version planning input: three in four responding servers are on 2025-11-25 and one in seven streamable endpoints serves the 2026-07-28 method, so a client that drops the legacy handshake today loses most of the public servers it could reach. Third, as a sizing fact: the median server offers 7 tools, so tool-selection budgets built for hundreds of tools per server are sized for the outliers.

The misuse is turning any row here into a verdict on a named server. The per-endpoint files are published so the counts can be checked, not so individual publishers can be ranked on a single unauthenticated probe from one network. Our companion measurement of structured data on 543 top homepages follows the same rule. Teams that need this run against their own server inventory, with credentials and from more than one region, can do it with the published script or ask our AI transformation practice to run it as part of an agent-infrastructure review.