A team tested 37,000 MCP servers news update

NestDaddy launched an automated directory service that conducts daily connectivity benchmarks across 37,383 remote Model Context Protocol servers in the official registry. Rather than relying on subjective curated lists, the platform connects to remote endpoints like a native client to record responses, latency, and exposed tooling schemas. In nestdaddy.com's report, the initial audit revealed that 89.6 percent of active remote endpoints successfully answered automated initialization probes.

This analysis provides an operational assessment of server uptime, authentication structures, network latency, and context consumption across the public ecosystem. The findings serve AI agent developers, client integration teams using tools like Cursor and Claude Desktop, and server maintainers deploying production endpoints. Readers will find concrete metrics to select dependable servers, structure authentication properly, and protect conversational context limits from excessive tool overhead.

01Remote endpoint execution and handshake tests

The automated scanner mirrored the exact discovery handshake executed by AI desktop clients such as Claude Desktop, Cursor, and VS Code. Probes initiated connections over Streamable HTTP or legacy Server-Sent Events streams before dispatching standardized initialization calls, initialization notifications, and tool list requests. Every probe ran from a single European server with a ten-second timeout, treating HTTP 429 rate limits as active endpoints without transmitting credentials.

Registry records showed that out of 62,377 published entries, 37,383 entries exposed live remote endpoints suitable for external network verification. The audit evaluated whether these remote endpoints conformed to standard protocol handshakes without dropping socket connections, hanging indefinitely, or misdirecting incoming programmatic requests. The resulting empirical dataset established the first comprehensive baseline of operational reliability across thousands of independently hosted community endpoints.

02Live availability and connection failure codes

The daily audit logged successful connection responses from 33,496 remote endpoints, representing 89.6 percent of all checked network instances. Only 3,555 servers failed to answer the scanner, exhibiting higher initial reliability than anticipated for an open ecosystem. Among failing endpoints, 1,156 servers suffered basic connection breakdowns including unresolved DNS records, refused socket handshakes, broken TLS negotiations, or complete request timeouts.

Application routing errors accounted for 997 instances of HTTP 404 not found and 170 instances of HTTP 405 method not allowed, typically caused by maintainers publishing site roots rather than protocol paths. Infrastructure outages produced 230 instances of HTTP 503 unavailable codes, 113 HTTP 502 bad gateway responses, and 173 HTTP 400 parameter errors. In addition, 104 endpoints returned HTTP 402 payment requirements, while 105 delivered non-protocol responses.

03Authentication gates and initialization latency numbers

Among the 33,496 functioning endpoints, 21,049 servers answered initialize calls and shared complete tooling inventories without demanding credentials. Conversely, 12,447 live endpoints, roughly one in three, immediately responded with HTTP 401 or HTTP 403 status codes. Requiring credentials during initialization blocks external discovery, whereas answering initialize openly and gating only tool execution calls preserves visibility while protecting backend operations.

Latency benchmarks revealed that the protocol itself introduces minimal operational overhead across global network routes. Monitored from Europe, the fastest 25 percent of endpoints answered initialization in under 320 milliseconds, while the median endpoint answered in approximately 500 milliseconds. Seventy-five percent finished within 780 milliseconds, 90 percent completed under 1.2 seconds, and only 842 servers exceeded two full seconds due to cold starts or deferred processing.

04Context payload limits and tool distribution

The survey cataloged 292,447 individual tools distributed across 20,241 endpoints that exposed their schemas to unauthenticated callers. Tool distribution remained heavily skewed toward compact sets, with the median endpoint exposing seven callable operations. Exactly 815 endpoints published a single tool, while 4,325 servers presented twenty or more distinct functional tools to client interfaces.

Excessive schema distribution creates serious context consumption issues during multi-server client engagements. AI clients dispatch every attached tool name and descriptive paragraph into the model context window during every conversational interaction. Connecting five endpoints carrying thirty operations each introduces 150 schema definitions into context, inflating input token consumption and degrading model routing accuracy compared to using fewer, well-described tools.

05Registry spam volume and maintenance practices

NestDaddy filtered out 7,839 entries representing 12.6 percent of the official directory due to mass automated publishing patterns. A single GitHub repository accounted for 2,356 listed endpoints, while two additional repositories generated another 2,200 duplicate entries with reused descriptions. High volume is not always malicious, as one publisher maintains 1,710 active endpoints from a single gateway sharing twelve base tools, but rapid growth requires stronger filtering.

Maintainers can improve ecosystem integration by publishing valid endpoint URLs, documenting parameter structures, and gating only execution calls behind authentication. NestDaddy provides copyable client configuration snippets for Claude Code, Claude Desktop, Cursor, and VS Code, alongside live verification badges for project repositories. These automated checks run daily to track server uptime, protocol compliance, and catalog hygiene over time.