NestDaddy 实测官方 MCP 注册表全部远程服务器：约一成无响应，12% 为垃圾条目

我们按照 MCP 客户端的方式，连接了官方 MCP registry 中每一个远程服务器。十分之九的服务器有响应，三分之一在展示工具之前就要求提供密钥，而整个 registry 中有 12% 是垃圾条目。以下是数据，以及这些数据对构建 agent 的人意味着什么。

NestDaddy 团队 · 2026 年 11 月 14 日 · 阅读时间 5 分钟

官方 MCP registry 目前列出了超过 62,000 个服务器。大多数“最佳 MCP 服务器”榜单只是从其中几十个里手工挑选出来的。我们想要看到全貌，于是构建了一个目录，每天按照 MCP 客户端的方式连接 registry 中每一个远程 MCP 服务器，并记录结果。

以下是首次完整运行的结果。

完整列表每天实时测试，见 nestdaddy.com/mcp/servers。

对于每个有远程端点的服务器，我们做了 Claude、Cursor 或 VS Code 在添加服务器时会做的事：

我们从不发送凭据。返回 HTTP 401 或 403 的服务器计为在线、需要密钥：它是运行的，只是不会和陌生人说话。HTTP 429（被限流）也计为在线。每个请求有 10 秒超时，所有检查都从欧洲的一台服务器发起，因此响应时间包含穿越互联网的往返。

89.6% 的远程服务器有响应。对于一个任何人都能发布的 registry 来说，这比我们预期的要好。没有响应的服务器以下列方式失败：

404 或 405 通常意味着 registry 条目指向了错误的路径，例如指向站点根目录而不是 /mcp。如果你维护一个服务器，值得检查你发布的 URL。

更友好的模式是对所有人响应 initialize 和 tools/list，只在 tools/call 时要求密钥。用户在创建账户之前就能确切看到他们将得到什么，而实际工作仍然留在密钥之后。

从欧洲的一台服务器测量，响应 initialize 的时间：

地理位置在这里影响很大：一台位于美国的服务器从欧洲看会比美国用户感觉到的更慢。请把这些数字当作粗略参考，而不是排名。它们确实表明的是，协议本身不是瓶颈。一个仅仅打招呼就要花几秒钟的服务器，通常是从冷启动开始，或者在做它应该稍后再做的工作。

在展示了工具的服务器中，我们发现了 292,447 个工具。

工具数量的重要性超过表面看起来的程度。每个工具的名称和描述都会在每次对话中发送给模型，无论该工具是否被使用。添加五个各有 30 个工具的服务器，模型每次聊天开始时上下文里就有 150 个工具描述。这会消耗 token，并且会让模型更难选对工具。工具清晰、描述良好的少量服务器，胜过工具列表冗长的众多服务器。

registry 是开放的，这一点很明显。在测试任何东西之前，我们隐藏了明显属于批量发布的条目：

不过，批量发布并不总是垃圾。有一个发布者通过单一网关运行 1,710 个在线服务器，每个公共 API 一个，每一个都在自身工具之上共享同样的 12 个基础工具（remember、recall、forget、company_facts 等）。这是一种合理的设计，但它表明 registry 中有多大一部分来自少数几个发布者，以及为什么原始条目数几乎不能说明有多少不同的产品。

registry 也在快速增长。10 月发布了 17,515 个条目，仅 11 月前 13 天就发布了 16,819 个。除非 registry 增加更强的检查，否则垃圾占比预计会增长。

在把服务器添加到 Claude、Cursor 或你自己的 agent 之前，检查三件事：

我们的 MCP 服务器目录为每个服务器展示这三项，并提供可直接复制的 Claude Code、Claude Desktop、Cursor 和 VS Code 设置。

目录中每个服务器页面都有一个可添加到 README 的徽章。当你的服务器通过每日检查时，它会变绿。

目录每天重新测试每个服务器，因此我们会定期重复这份报告，并展示变化：有多少服务器来了又走，以及 registry 是变得更干净还是更嘈杂。如果你想要我们没有覆盖的特定数字，请通过 [email protected] 告诉我们。