36款MCP服务器大考：三分之一不及格
I graded 36 popular MCP servers on agent usability. A third got a D or F
我开发了一款名为mcpgrade的工具，对36款热门MCP服务器进行了深度扫描。结果令人担忧：尽管许多服务器完全符合协议规范，但三分之一在AI代理可用性上得了D或F。问题核心不在于协议层，而在于描述缺失、命名混乱和Schema设计缺陷。MongoDB、Notion和GitHub等知名厂商的官方服务器也未能幸免，大量参数缺乏描述导致模型无法正确调用。合规不等于可用，文档纪律才是决定AI代理表现的关键。
你的MCP服务器可以100%符合规范，但对AI代理来说依然完全无法使用。
HN 评论区
10- brookst
文档完善的庞大目录集是可行的，只是很少见。
它们其实没那么罕见，只是扁平化的大目录效果不好。
MCP 服务器设计最常见的失败模式是将 MCP 工具映射到系统 API。这会导致出现列出文件的工具、重命名文件的工具、复制文件的工具等等。
你可以有 100 个“工具”，但你只需要定义 10-12 个领域（MCP 模型中的实际工具），并在每个领域内定义操作。这就创建了一个层次结构，模型在需要时可以深入其中，而在不需要该领域时避免上下文杂乱。
所以，与其有 15 个文件操作工具，不如只有一个“file”工具，包含 list、copy、rename 等操作。
这是任何 MCP 服务器（好吧，任何拥有不止几个操作的服务器）最重要的架构要求。
- codeonline
颇具讽刺意味的是，你结果表的链接坏了。
- kittikitti
我不会去标准化一个 MCP 服务器。我来自设计 REST API 和 Python 宽松语法的背景。与其他框架相比，MCP 相对较新，由于 Anthropic 的专有方案，存在合理的怀疑。听起来 AI 公司正在根据他们自己制定的定义对 MCP 服务器进行把持，并且可以让他们的打手四处进行“纯洁性测试”。