1,274个MCP工具描述评分后，模型选工具靠什么？

MCP（Model Context Protocol）正成为连接AI模型与外部工具的关键协议。一个核心问题始终悬而未决：工具描述写得好不好，究竟会不会影响模型选择工具的正确率？Forecall团队对55个公开MCP服务器、共1,274个工具的描述进行了结构化评分，并进一步用前沿模型做了端到端测试。结论既有意外，也有现实启示。

评分体系：六个维度，满分100

Forecall的评分规则v2从六个方面评估每个工具描述：是否说明工具用途、何时使用、参数含义、返回内容、约束条件以及示例。每个工具描述得分在0到100之间，55个服务器的平均分从19.9到82不等，中位数仅为44。在所有1,274个工具中，497个得分低于40，仅有18个达到80分以上。

数据来源分为两部分：46个服务器来自Smithery注册表API的十月份快照，包含最常用服务器及其工具的输入schema，但注册表不保留输出schema、注解和服务器指令；另外9个服务器通过forecall dump直接从运行中的服务器提取，包括Notion、Playwright、Chrome DevTools、Context7、Filesystem、Memory、Firecrawl等，保留了更完整的元数据。

MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在为AI模型与外部工具、数据源之间建立标准化的通信接口。在MCP架构中，每个工具通过一份JSON Schema描述自身，包括名称、描述文本、输入参数schema以及可选的输出schema和注解。模型在决定调用哪个工具时，能看到的全部信息就是这份描述。因此，工具描述的质量直接决定了模型可获取的上下文信息量，这也是Forecall团队选择对描述文本进行结构化评分的根本原因。

Smithery是MCP生态中最主要的公开服务器注册表之一，开发者可以将自己构建的MCP服务器发布到该平台供他人发现和安装。注册表API提供服务器及其工具的输入schema，但出于标准化和精简考虑，通常不保留输出schema、注解和服务器级指令。这意味着仅从注册表提取的数据会天然缺失一部分元数据，研究者需要结合forecall dump直接从运行中的服务器提取，才能获得更完整的工具信息。

描述中最常见的三块缺失

何时使用工具是最大的信息缺口。885个工具（占69%）从未在描述中说明使用场景，且注册表来源与直接提取来源的缺失比例几乎一致（69% vs 71%）。这意味着无论数据来源如何，开发者普遍忽略了这一关键信息。

返回内容的缺失同样严重。在156个直接提取的工具中，87个（56%）既没有输出schema，也没有在描述中说明返回什么。由于注册表本身会丢弃输出schema，这部分数据仅基于dump组统计。

近义描述问题突出。55个服务器中有18个存在至少一对几乎相同的工具描述，共129对。其中Notion（24个工具中有57对）和Paper Search（25个工具中有29对）两个服务器贡献了绝大多数重复。这种冗余描述在工具数量增长时会显著增加模型混淆的风险。

低分是否导致模型选错工具？

这是整项研究最反直觉的部分。Forecall在4个服务器（Memory、Notion、Playwright、Chrome DevTools）的88个工具上，为每个工具生成8个单步请求，分别用Claude Sonnet 5.5和GPT-6.1 Sol测试模型选择正确率。

结果令人意外：即使平均分低至33.0的Notion服务器，Sonnet和Sol的正确率仍分别达到96%和96%；Chrome DevTools（平均分45.1）更是高达99%和98%。所有服务器的正确率区间为91%到99%。Spearman相关系数仅为0.04，统计上几乎不存在工具得分与模型正确选择之间的关联。得分低于40的工具被正确选择的比例为95.5%，而得分60到79的工具反而达到100%。

为了增加难度，研究者将其他服务器的25到55个工具混入候选集。结果没有一次请求被误导向其他服务器的工具，准确率保持在91%到98%。

Spearman相关系数是一种非参数统计量，用于衡量两个变量的排序之间的单调关系，取值范围为-1到1。与Pearson相关系数不同，它不要求变量服从正态分布，也不假设线性关系，因此适合用于评估工具描述得分（0-100的序数）与模型正确选择率之间的关联。研究中得到的0.04意味着两者几乎不存在单调关系——即描述得分高并不意味着模型更可能选对工具。

单步请求是指用户提出一个只涉及一次工具调用的任务，例如“列出所有页面”或“填写表单中的某个字段”。相比之下，多步任务需要模型依次调用多个工具才能完成。研究者选择单步请求作为测试场景，是因为它能直接检验模型在面对一组候选工具时的选择能力，排除多步规划带来的额外混淆因素。这也意味着研究结论的适用范围应限定在单步场景，作者在讨论中也明确指出了这一边界。

模型为什么还能选对？

工具名称和输入schema承载了足够的信息。即使描述文字简略，模型能从工具名（如list_pages、browser_fill_form）和参数schema推断出用途。

模型还表现出合理的多步行为。当请求中未指定页码时，模型在77%到87%的情况下会先调用list_pages再执行操作；对于browser_fill_form，模型会先获取页面快照，因为字段引用来自快照。这些“先侦察再行动”的模式说明，前沿模型在单步选择中并不依赖描述文本的完整性。

输入schema（input schema）是MCP工具定义中的核心组成部分，采用JSON Schema格式描述工具接受的参数，包括参数名称、类型、是否必填以及枚举值等。例如，一个名为list_pages的工具，其schema可能要求一个可选的page_size整数参数。模型在推理时会将schema作为结构化上下文的一部分，从中推断工具的功能和调用方式。相比之下，描述文本是自然语言的自由形式，信息密度和一致性往往不如schema。

“先侦察再行动”模式指的是模型在执行目标操作前，先调用信息获取类工具来补齐缺失的上下文。例如，当用户请求填写表单但未提供字段引用时，模型会先调用页面快照工具获取当前DOM结构，再根据快照中的字段标识执行填写操作。这种模式说明前沿模型具备一定的任务分解和状态感知能力，能够在单步请求中隐式地进行多步规划，从而降低对描述文本完整性的依赖。

静态评分的边界与真实价值

这项研究传递的核心信息是：静态评分衡量的是描述“写了什么”，而非模型“会怎么选”。Forecall已将网站措辞从“容易混淆的工具对”改为“近乎相同的描述”，并在每个结果中标注静态评分无法告知的内容。

文本缺失仍可能在测试未覆盖的场景中造成问题：用户没有工具所需的ID时、多步任务中、较小模型上，以及人类阅读文档时。但更长的描述不等于更好。在早前测试中，一次将工具得分从31提升到74的改写，反而让两个模型的选择表现变差。这说明描述优化必须针对实际使用的模型进行验证，而非盲目追求评分提升。

开发者可以做什么

Forecall提供了多种检查方式。可以访问forecall.dev/en/servers查看已有评分，或在forecall.dev/en/lint粘贴公开的Streamable HTTP服务器URL进行在线检查。本地使用时，运行npx forecall dump -o tools.json -- <启动命令>导出工具信息，再通过npx forecall lint tools.json获得评分，整个过程不向外部发送数据。其linter已在GitHub开源。

对于使用Pro或Team计划的用户，Forecall的评估功能可报告模型选择正确率、前置查找率、参数有效性和错误调用等指标。这些动态评估与静态评分互补，共同构成更完整的工具质量视图。

核心结论：描述质量确实有提升空间（尤其是“何时使用”和“返回什么”），但在前沿模型的单步工具选择中，得分高低几乎不预测正确率。工具名和schema才是模型决策的主要依据。优化描述时，请以实际模型行为为准绳。