你的MCP服务器有一个隐秘的评分问题

你的MCP服务器在演示中完美运行。你知道它能行，因为演示是你自己搭的。你精心挑选了prompt，工具触发了，结果干干净净地返回了。所有人都点头了。上线吧。

然后生产环境来了。

在生产环境中，LLM有30%的概率选错工具。用户报告奇怪的结果。代理在应该调用fetch的时候调用了search。在需要epoch时间戳的地方传了日期字符串。完全忽略了你最强大的工具，因为它搞不清什么时候该用。

什么变了？你的代码没变。Handler没问题。逻辑没问题。问题一直都在——你只是从来没注意到，因为演示是编排好的，而生产不是。在演示中，你控制输入。在生产中，LLM必须从你的十五个工具中找出哪个匹配用户含糊的请求。而它在这一步失败的频率，远比你想象的要高。

这就是那个隐秘的评分问题。你的服务器没有bug。它有一个质量差距，只在语言模型必须对你的工具做出真正决策时才会显现。

大多数MCP开发者没有真正理解的一件事：LLM从来不读你的代码。它看不到你的handler逻辑、你的验证规则、你精心设计的错误处理。它看到的只有名称、描述和schema。

就这些。这就是你的工具和决定是否使用它的智能体之间的全部接口。

如果两个工具的描述相似，LLM就猜。它不会要求澄清。不会标记歧义。它选一个然后继续。如果你的描述说"搜索文档"，另一个工具说"查找文档"，LLM本质上是在抛硬币。

如果描述模糊，LLM就幻觉出意图。它用假设填补空白。"管理用户设置"可能意味着读取设置、写入设置、删除设置或导出设置。LLM会假定一个含义并坚持下去，不会告诉任何人。

工具选择是语言问题，不是代码问题。工程师的本能是调试handler。实际的修复几乎总是在文本中——描述你的工具做什么以及何时使用它的那二十个字。大多数团队从不看那里，因为他们忙着看堆栈跟踪。

质量评分不是一个单一数字。如果是的话，它就没用了——就像给一家餐厅打一个分而不区分菜品、服务和氛围。

真正的质量评分有六个维度，每个都可以独立衡量，每个都能单独拖垮你工具的可靠性。

描述清晰度：描述是否解释了工具做什么、什么时候用、什么时候不该用？是否指定了响应格式？这里40分意味着"LLM会经常误用这个工具。"90分意味着"LLM几乎总是正确选择这个工具。"

Schema完整性：参数类型是否精确？必填字段是否真的是必填的？受限值是否使用了enum？

命名一致性：你的工具是否遵循可预测的模式？如果你有create_user和delete_user但又有fetch_all_documents，这种不一致会给模型造成认知负担。

重叠检测：有多少工具可能合理地匹配同一用户请求？高重叠是错误工具选择的最大预测因子。

错误文档：工具是否描述了出错时会发生什么？

示例覆盖：描述中是否有使用示例？示例比段落式的解释更有价值，因为它们把LLM的理解锚定在具体的模式上。

让我具体说明。以下是每个维度40分和90分的对比。

描述清晰度40分："搜索数据库。"90分："对所有已索引文档进行全文搜索。返回按相关性排名的前10个结果。当用户想按内容查找文档时使用。不要用于精确ID查找——改用get_document。返回标题、摘要和相关性分数。"

Schema完整性40分：一个参数"query"，类型string，无约束。90分："query"为非空string，最大长度500，加上可选"limit"为integer最小1最大100默认10，加上可选"date_range"带ISO 8601日期。

命名40分：search、getDoc、user_remove、ListAllItems。90分：search_documents、get_document、remove_user、list_items。模式是verb_noun，始终一致。

重叠40分：search_documents、find_documents和query_documents都存在，做略有不同的事情。90分：每个工具都有明确的、不重叠的目的。

差异永远在于具体性。模糊的工具失败。精确的工具成功。40分和90分之间的差距通常不需要重写——一个下午的仔细编辑就够了。

大多数团队在错误的层面调试。他们看到工具选择失败就直奔代码。重写handler让它更宽容。添加重试逻辑。换更贵的模型。在MCP之上构建复杂的路由层来补偿底层的歧义。

这一切都昂贵、缓慢，而且治标不治本。

实际的修复通常是对工具描述的20字编辑。把"管理文档"改成"根据提供的标题和正文创建新文档。返回文档ID。仅用于创建新文档——更新现有文档请使用update_document。"

这个编辑花了三十秒。它消除了整整一类工具选择错误。没有代码改动。不需要模型升级。不需要重试逻辑。

质量评分会准确告诉你该改哪20个字。它指向失败的具体维度，在造成问题的具体工具上，附带具体的改写建议。它把模糊的"AI总是搞混"变成精确的"你的search_documents描述没有提到响应格式，34%的失败可追溯到LLM误解了结果。"

这就是衡量为什么重要。不是因为分数本身有价值，而是因为它把一个看不见的问题变成了看得见的、可以修复的问题。想通这一点的团队不再重写handler，而是开始重写描述。他们在几分钟而不是几天内交付修复。他们的工具就是好用——不是因为代码更好，而是因为语言更好。