{"slug": "1000-public-mcp-servers-checked-55-complete-a-handshake", "title": "1,000 Public MCP Servers Checked: 55% Complete a Handshake", "summary": "A census of 1,000 sampled remote endpoints from the official MCP Registry found that 550 completed a valid unauthenticated initialize handshake, while 338 asked for credentials, according to results published November 5, 2026 from a fixed-seed sample drawn from 57,041 servers, 38,270 of which declare a remote endpoint. The census counted 112 genuine failures (111 in a second round), covering DNS or TLS failures, timeouts, and non-MCP responses such as HTTP 404s, and found that registry metadata poorly predicts authentication needs: 290 of the 911 entries declaring no required header still demanded credentials, while 26 of the 89 declaring one completed the handshake without it. Of 550 responding endpoints, 423 (76.9%) negotiated protocol version 2025-11-25 and only 140 of 970 streamable-HTTP endpoints (14.4%) answered the 2026-07-28 server/discover method, with a median of 7 tools listed per server.", "body_md": "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.\n\nThe 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.\n\nThis 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](https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol) page carries the registry's growth figures that this census does not repeat.\n\n1. 01Just over half of sampled public MCP endpoints complete an unauthenticated handshake.550 of 1,000 in round 1 and 551 in round 2 returned a valid initialize result. Another 338 asked for credentials both times. The two groups together are 888 endpoints that are reachable and either completed the handshake or asked for credentials.\n2. 02The real failure rate in this sample is about 11%.112 endpoints in round 1 (111 in round 2) returned a protocol error, another HTTP error, a DNS or TLS failure or a timeout. Twenty-two of the 42 protocol errors were a plain HTTP 404 at the listed URL; three returned HTTP 200 with a body that was not an initialize result.\n3. 03Registry metadata is a poor predictor of who needs a key.Only 89 of the 1,000 sampled entries declare a required header. 290 of the 911 that declare none still demanded authentication, and 26 of the 89 that declare one completed the handshake without it.\n4. 04Most responding servers speak 2025-11-25; the July 2026 method is rare.423 of 550 ok endpoints (76.9%) negotiated protocol version 2025-11-25, the version our client offered; 88 fell back to 2025-06-18 and 36 to 2025 or 2024 revisions. Only 140 of 970 streamable-HTTP endpoints (14.4%) answered the 2026-07-28 server/discover method.\n5. 05Servers are small: median 7 tools, and 40% list five or fewer.Of 544 endpoints that returned a tool list, 219 had 1 to 5 tools, 246 had 6 to 20, 59 had 21 to 50 and 19 had more than 50. Nine listed 100 or more; the largest, an aggregator endpoint, listed 572.\n\n## 01 — The SampleWhat we checked, and how *many*.\n\nThe 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.\n\nSome 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.\n\nEach 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](https://www.digitalapplied.com/blog/mcp-2026-07-28-spec-stateless-migration-guide).\n\n## 02 — Outcome SplitSix outcomes for *1,000* endpoints.\n\nEvery 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.\n\nIn 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.\n\n#### Outcome of an unauthenticated initialize, round 1\n\nSource: our census of 1,000 endpoints sampled from the MCP Registry, round 1, November 5, 2026, 12:57 to 13:02 UTC. Shares of the 1,000 sampled endpoints.\n##### ok plus auth_required\n\n550 completed the handshake and 338 asked for credentials. Both groups are live endpoints; the second asked for credentials we did not send, so the census cannot confirm the protocol behind them.\n\n##### protocol_error\n\n20 returned HTTP 404 and 3 returned 405 to the initialize POST, and 2 SSE streams returned 404. Three returned HTTP 200 with a body that was an HTML page or an unrelated JSON object. The other 14 were JSON-RPC errors such as disabled, not found or an internal error.\n\n##### other, dns_tls_error and timeout (69 in round 2)\n\nIn round 2: 22 DNS failures, 10 TLS failures, 6 SSE streams answered 402, 6 HTTP 500, 4 HTTP 503, 6 Cloudflare 522, 525 or 530, 9 timeouts and a handful of 402, 410, 502, 526 and connection resets.\n\n##### The legacy transport fares worse\n\nOf the 30 SSE endpoints sampled, 7 completed the handshake, 6 asked for credentials, 10 returned another HTTP error, 4 failed at DNS or TLS and 3 were protocol errors. Thirty is too few to generalise.\n\n## 03 — Full RegisterEvery count, both *rounds*.\n\nThe 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.\n\n| Our census, November 5, 2026. Round 1 ran 12:57:24 to 13:02:02 UTC and round 2 13:48:03 to 13:54:07 UTC against the same 1,000 endpoints. Outcome rows are of 1,000; version, tool and latency rows are of the ok endpoints; server/discover rows are of 970 streamable-HTTP endpoints. |  |  |  | \n|---|---|---|---|\n| Measure | Round 1 | Round 2 | Note | \n|---|---|---|---|\n| ok | 550 | 551 | initialize returned a result with a protocolVersion | \n| auth_required | 338 | 338 | HTTP 401 or 403, or a WWW-Authenticate header | \n| protocol_error | 42 | 42 | JSON-RPC error, HTTP 4xx of a protocol kind, or a 200 that was not MCP | \n| other | 31 | 28 | Other HTTP statuses (402, 410, 5xx, 52x) or unclassified errors | \n| dns_tls_error | 29 | 32 | Hostname did not resolve or TLS failed | \n| timeout | 10 | 9 | No response within 20 seconds | \n| Negotiated 2025-11-25 | 423 | 423 | Of ok rows; the version our client offered | \n| Negotiated 2025-06-18 | 88 | 88 | Of ok rows | \n| Negotiated 2025-03-26 | 18 | 19 | Of ok rows | \n| Negotiated 2024-11-05 | 18 | 18 | Of ok rows; the original revision | \n| Negotiated 2026-07-28 | 2 | 2 | Of ok rows; returned to a legacy initialize call | \n| Negotiated other string | 1 | 1 | One server returned 2025-11-05, not a revision we know | \n| server/discover ok | 140 | 141 | Of 970 streamable-HTTP endpoints; 2026-07-28 method | \n| server/discover auth_required | 368 | 368 | Of 970 | \n| server/discover −32601 | 192 | 192 | Method not found: server speaks MCP but not the new method | \n| server/discover −32000 | 117 | 119 | Server-defined JSON-RPC error | \n| server/discover −32600 | 34 | 35 | Invalid request | \n| tools/list returned | 544 | 544 | Of ok rows; 6 and 7 failed after a successful initialize | \n| Median tool count | 7 | 7 | Of endpoints that returned a list | \n| Largest tool count | 572 | 572 | An aggregator endpoint; 9 endpoints listed 100 or more | \n| Endpoints with 51+ tools | 19 | 18 | Bands: 0: 1 · 1–5: 219 · 6–20: 246/247 · 21–50: 59 | \n| Initialize latency, median | 263.5 ms | 374 ms | Of ok rows, from connection open, one vantage point | \n| Initialize latency, p90 | 922 ms | 1,289 ms | Of ok rows | \n| Same outcome in both rounds | — | 991 | 9 changed; 7 of them between ok and not ok | \n\n## 04 — AuthenticationAsking for credentials is not *failing*.\n\nA 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.\n\nWhat 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.\n\nThe 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](https://www.digitalapplied.com/blog/mcp-security-incident-ledger) is the right page for what has gone wrong when servers did not gatekeep; this one only counts who does.\n\n## 05 — Protocol VersionsWhich revisions *answered*.\n\nOur 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.\n\nThe 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.\n\nRead 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](https://www.digitalapplied.com/blog/mcp-sdk-conformance-tiers-what-tier-1-means) explains why server versions trail the specification.\n\n## 06 — Tools and LatencySmall servers, mostly *quick*.\n\nAfter 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).\n\nInitialize 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](https://www.digitalapplied.com/blog/mcp-server-reliability-metrics-slo-design-framework-2026) treats these as the kind of numbers an operator should collect continuously rather than once.\n\n## 07 — Two RoundsForty-six minutes *later*.\n\nRound 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.\n\nAn 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.\n\n## 08 — MethodMethod, limits and the *dataset*.\n\nEverything 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.\n\n- Source\n- The official MCP Registry API, /v0.1/servers, fetched November 5, 2026 at 12:51 UTC: 216,306 version records, 57,041 latest-version servers, 38,270 with at least one remote endpoint, 39,182 remote rows. Local-package servers were excluded.\n- Sample\n- 1,000 of the 38,788 unique untemplated remote endpoints, drawn with seed 20261105 and at most two endpoints per hostname. 970 streamable-HTTP, 30 SSE; 974 hosts; 997 registry names. The whole registry was not probed.\n- Probe\n- One unauthenticated initialize offering 2025-11-25, the initialized notification, tools/list paged up to three times, a session delete, and one server/discover under 2026-07-28 for streamable endpoints. User agent DigitalAppliedResearch/1.0 with our site URL. 20-second socket timeout per request (a slowly streaming reply can take longer in total), 8 workers, no tool calls.\n- Outcomes\n- ok: a result with protocolVersion. auth_required: 401, 403 or WWW-Authenticate. protocol_error: JSON-RPC error, HTTP 400, 404, 405, 406, 415, 422, or a 200 that was not an initialize result. other: remaining HTTP statuses or unclassified exceptions. dns_tls_error. timeout.\n- As-of date\n- Round 1 November 5, 2026, 12:57:24 to 13:02:02 UTC; round 2 13:48:03 to 13:54:07 UTC. One network location.\n- Limits\n- A sample, not the registry. Unauthenticated, so protected servers are counted as auth_required and never tested further. One vantage point, so latency and the DNS and TLS failures include our route. Only 30 SSE endpoints. A listing is not an endorsement and an answer is not a quality signal.\n- Refresh\n- Maintained by the Digital Applied Team. Re-run against the then-current registry roughly quarterly with the same seed and cap; each run is published as its own dated dataset and earlier figures are not re-dated.\n\n[Download round 1](https://www.digitalapplied.com/data/mcp-census-2026-11-05/round1.csv) and [round 2](https://www.digitalapplied.com/data/mcp-census-2026-11-05/round2.csv) (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](https://www.digitalapplied.com/data/mcp-census-2026-11-05/sample.csv) with each endpoint's registry fields, and the [summary file](https://www.digitalapplied.com/data/mcp-census-2026-11-05/summary.json) with every count on this page. The checker is a single standard-library Python script; the registry API is public.\n\n## 09 — How to UseWhat to do with *these numbers*.\n\nThree 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.\n\nThe 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](https://www.digitalapplied.com/blog/schema-markup-adoption-top-homepages-2026) 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](https://www.digitalapplied.com/services/ai-transformation) to run it as part of an agent-infrastructure review.\n\n## 10 — ConclusionNine in ten are *up*; just over half let a stranger in.\n\n### Quote 55% with its denominator and its date, treat auth_required as a separate category, and expect most public servers to still want the legacy handshake.\n\nWe sampled 1,000 of the 38,788 unique untemplated remote MCP endpoints listed in the official registry and probed each one twice, unauthenticated, 46 minutes apart. 550 then 551 completed the handshake, 338 asked for credentials both times, and 112 then 111 failed at the protocol, the HTTP layer, DNS, TLS or the clock. 991 gave the same answer in both rounds.\n\nAmong the servers that answered, 77% negotiated protocol version 2025-11-25, 16% fell back to 2025-06-18, and only 14% of streamable endpoints served the 2026-07-28 server/discover method. The median server lists 7 tools and answered the handshake in about a quarter of a second from our location.\n\nThe sample, both rounds, the summary and the script are published so every count can be re-derived. The next run will be a new dated file beside this one, with the same seed and the same cap.", "url": "https://wpnews.pro/news/1000-public-mcp-servers-checked-55-complete-a-handshake", "canonical_source": "https://www.digitalapplied.com/blog/mcp-remote-server-health-census-november-2026", "published_at": "2026-11-05 00:00:00+00:00", "updated_at": "2026-11-05 19:24:23.196226+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "ai-infrastructure"], "entities": ["MCP Registry", "Model Context Protocol", "server/discover"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/1000-public-mcp-servers-checked-55-complete-a-handshake", "markdown": "https://wpnews.pro/news/1000-public-mcp-servers-checked-55-complete-a-handshake.md", "text": "https://wpnews.pro/news/1000-public-mcp-servers-checked-55-complete-a-handshake.txt", "jsonld": "https://wpnews.pro/news/1000-public-mcp-servers-checked-55-complete-a-handshake.jsonld"}}