MCP 工具描述质量是被反复确认的工程短板 把 MCP 工具调用推到生产环境一段时间后,几乎所有认真做过事故复盘的团队都会撞上同一组工程观察——Agent 选错工具、不该调的工具被调了、该调的工具没被调、参数填错、返回值解析失败——大量事故的根因可以追溯到 MCP server 的工具定义本身的质量问题。这类问题不是 Agent 不够聪明,而是 server 端的工具描述、参数 schema、行为
MCP 工具描述质量是被反复确认的工程短板
把 MCP 工具调用推到生产环境一段时间后,几乎所有认真做过事故复盘的团队都会撞上同一组工程观察——Agent 选错工具、不该调的工具被调了、该调的工具没被调、参数填错、返回值解析失败——大量事故的根因可以追溯到 MCP server 的工具定义本身的质量问题。这类问题不是 Agent 不够聪明,而是 server 端的工具描述、参数 schema、行为提示、返回类型标注做得不够清晰,Agent 在没有足够信息的条件下只能靠猜测。猜测在简单任务上偶尔对,在生产复杂任务上几乎必然错。
这个问题在 2026 年下半年被一组独立工程实践系统化记录:第一个实践是 2026 年 9 月初公开的 TDQS 规范——一份对 MCP 工具定义进行评分的工程规范,基于对 856 个工具、103 个 server 的系统化测量,明确给出"97% 的描述至少有一个缺陷、89% 的描述从未说明工具何时应该被使用"的具体数据;第二个实践是 2026 年 2 月公开的 TrustVector——一份多维度信任评分框架,对模型、Agent、MCP server 进行系统化评估,把"工具定义质量"作为评分维度之一。这两条独立工程实践共同指向一个清晰的工程现实:MCP 协议层缺少一个被广泛接受的"工具定义质量"度量标准,任何想把 MCP server 推到生产的企业都需要自己建立这个标准。
TDQS 给出的工具描述质量基线
TDQS 规范的工程意义是把"MCP 工具定义好不好"这个问题从主观感受变成了可量化、可重现、可机读的工程指标。具体来说,TDQS 给出了六个加权维度评估每个工具,另四个等权维度评估整个 server。每个维度都给出 1-5 分的评分,每个分数都附有解释,最终的加权总和换算成 A/B/C/D/E 五个等级,企业可以在 CI 里设阈值,任何低于某个等级的工具不允许上线。
在六个工具维度里,几个关键维度的工程含义值得专门讲明白。第一个是"使用指南"——描述里是否明确说明"这个工具应该在什么场景下被调用"。TDQS 实测显示,89% 的工具描述从未说明这一点,意味着 Agent 在调用前不知道该不该用这个工具,只能靠工具名猜。这是 Agent 选错工具的最常见根因。第二个是"参数覆盖"——参数 schema 是否完整、是否有默认值、是否有约束。TDQS 通过确定性代码读取 schema,评估每个参数是否有清晰的定义。这是 Agent 填错参数的最常见根因。第三个是"行为提示"——描述里是否包含 Agent 调用前需要知道的行为约束(比如"会消耗 token"、"会修改外部资源"、"会触发异步操作")。这是 Agent 误调危险工具的最常见根因。
TDQS 还给出了四个 server 级维度,从更高层面评估工具集的协调性。这四个维度里,最关键的是"协调性"——server 内的多个工具之间是否在命名、参数、返回类型上保持一致,工具集作为一个整体是否逻辑清晰。这条维度对工程的意义是——一个命名风格混乱、参数类型前后不一致的 server,即便单个工具描述写得不错,Agent 在跨工具切换时仍然会犯错。这条工程现实意味着,工具定义质量不能只看单个工具,必须看工具集的协作关系。
TDQS 实测数据的工程含义
TDQS 给出的实测数据对工程治理有直接的具体含义。第一个数据是"97% 的描述至少有一个缺陷"——这意味着任何不带质量检测的 MCP server 部署,几乎必然上线就有缺陷;不带质量检测的 CI 流程,几乎不可能在 PR 阶段拦住这些问题;依赖事后监控和修 bug 的策略,在 97% 的缺陷率面前基本失效。第二个数据是"89% 的描述从未说明工具何时被使用"——这是 Agent 选错工具的最大根因,工程团队必须把"使用场景说明"作为工具描述的硬性要求。第三个数据是"重写描述单项能把任务成功率提高 6 个百分点"——这是一个投入产出比极高的优化点,工具定义质量的提升直接转化为 Agent 实际效果的提升。第四个数据是"56.4% 的工具仍然带 smell"——这是已经接受了 TDQS 评分的 server 里的比例,意味着评分本身不能保证改进,必须把评分+修复形成闭环。
这四条数据合并起来,在工程上指向一个清晰的结论:工具定义质量是一个被反复低估的、投入产出比极高的优化点。任何企业把 MCP 推到生产,都应当把"工具定义质量"作为 CI 流程的一部分——和单元测试、静态扫描、安全审计同等重要。具体的工程落地可以是:每个 MCP server 的 PR 都必须经过 TDQS 评分,低于 B 等级的不允许合并;每个 MCP server 必须有月度质量报告,持续追踪工具定义质量的演进;每个新工具上线前必须经过 6 个维度的逐项检查,而不是只由开发者自己"觉得描述够清楚"。
从单一 server 到生态级质量治理
TDQS 实测的另一个工程含义是,MCP server 的质量问题不是单个企业的工程问题,而是整个生态的质量问题。TDQS 在 Glama 的 15000+ MCP server 上跑了系统化测量,发现 56.4% 的 server 仍然带 smell——这意味着即便评分本身存在,生态级别的质量提升仍然缓慢。这条观察指向一个工程现实:MCP 协议层的"工具描述质量"是一个跨企业的公共物品,任何一家企业建立的私有评分标准,只能影响自家 server;要让生态整体提升,必须有一个被广泛接受的标准。
这条观察在工程治理上的推论是双重的。第一,任何企业内部建立的工具描述质量标准,都应当参考或对齐到公开标准(如 TDQS),而不是完全私有化——这样内部 server 可以被生态里的其他工具识别,内部评分可以和企业外部 server 对照。第二,企业内部在工具描述质量上的投入,应当尽量参与到生态标准的演进里——提交反馈、参与评分标准修订、把自家评分结果匿名化共享给标准维护方。这两条都是"公共物品"逻辑下的常规工程实践,但在 MCP 这种新兴协议上,生态正处于"标准正在建立"的关键窗口期,企业的参与会比成熟期更有价值。
从工具描述质量到 Agent 协议层质量度量
把视野拉宽到整个 Agent 协议层,工具描述质量只是众多质量维度中的一个。TrustVector 这条独立实践给出了更广义的"信任评分"维度,包括:安全性(prompt injection 抗性、数据泄漏)、隐私和合规、信任和透明(幻觉率、文档质量)、性能和可靠性、运维卓越。这五条信任维度加上"工具描述质量"这一维度,共同构成了 Agent 协议层质量度量的工程基线。
这条基线在工程上的具体落地是:任何企业 MCP server 上线前,必须通过这六个维度的系统评估;评估结果必须可以机读、可追踪、可对比;评估必须随时间持续进行,而不是一次性的"门禁检查";评估结果必须在企业内部可被检索,任何工程师在做选型时都能查到目标 server 的评估分。这套机制和软件供应链的 SBOM/SLSA 思路同构——把 server 的"质量清单"当作可机读、可验证、可追踪的工程产物,而不是一次性的人工评估。
企业 Agent 协议层质量度量的工程新基线
把上述分析汇总,可以画出企业 Agent 协议层质量度量的工程新基线。这条基线由五条构成,缺一不可。
第一条,工具描述质量必须可量化、可重现、可机读。任何 MCP server 上线前,工具描述都必须经过量化评分,评分标准基于公开发布的规范(如 TDQS),评分结果有明确的等级和阈值。这条基线解决"工具描述好不好"的主观判断问题——把它从"开发者自己觉得清楚"变成"评分系统判定为 B 以上"。
第二条,质量评分必须进入 CI。任何 MCP server 的 PR 流程都必须包含质量评分步骤,低于阈值的 PR 不允许合并;评分结果作为 PR 评论的一部分,让开发者看到具体扣分点和改进建议。这条基线解决"质量评分只在 CI 里跑一次"的问题——把评分常态化,让质量改进成为持续迭代。
第三条,质量维度必须覆盖多个层面,不能只看工具描述。除了工具描述,还应包括参数 schema 完整性、行为提示明确性、server 内工具协调性、命名一致性、返回值标注完整性等。这条基线解决"评分维度单一"的问题——多个维度联合评估,才能识别出实际生产里的真实瓶颈。
第四条,质量评估必须随时间持续进行。任何 MCP server 的质量评分必须在每次工具变更、参数变更、描述变更后重新跑;评分历史必须保留,可以画出"质量演进曲线"。这条基线解决"评分是一次性快照"的问题——质量改进需要时间维度上的追踪。
第五条,质量评分必须可被检索。任何企业内部 MCP server 的评分结果必须出现在企业内部的"工具目录"里,任何工程师在选型时都能查到目标 server 的当前评分和历史趋势。这条基线解决"评分结果无人查阅"的问题——评分必须可被消费,否则评分本身没有意义。
从 Coding Agent 协议质量推到所有企业 Agent
把视野拉宽到企业 Agent 全景,以上五条基线具有普遍意义。任何企业内部使用 Agent 调用工具(不只是 MCP,还包括自定义 tool、API 函数、内部服务)的场景,都应当有对应的"工具描述质量"评分机制。具体落地可以是:对每个 Agent 调用的工具,都用统一的评分标准评估;评分结果纳入工具目录;工具的添加、修改、删除都必须经过评分变化检查。这条思路在工程上和软件供应链的 SBOM/SLSA 完全同构——把工具当作可被质量评估的工程产物,而不是"能用就行"。
企业 Agent 治理负责人现在应当把工具描述质量度量作为整个企业 Agent 工具链质量治理的样板工程。具体来说,"量化评分、CI 强制、多维度、持续评估、可被检索"这五条规则应当通用化,覆盖企业内部所有 Agent 的所有工具调用场景。每一条规则对应一个独立的工程组件——可以是 TDQS 风格的评分工具、可以是 CI 流程里的 quality gate、可以是多维度评估清单、可以是 score history 数据库、可以是企业内部工具目录的搜索接口——实现形式各异但原则一致。
企业 Agent 治理负责人现在必须回答的三个问题
面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 MCP server 是否有量化的工具描述质量评分?如果有,评分标准是什么;如果没有,事故发生的概率是几乎确定的。
第二个问题:你企业内部 MCP server 的 PR 流程是否包含质量评分步骤?如果有,评分低于阈值是否真的会拒绝合并;如果没有,质量评分只是装饰。
第三个问题:你企业内部是否建立了工具评分历史,可以追踪质量演进?如果有,可以基于评分历史做趋势分析;如果没有,质量改进只能基于主观感受。
结语
Agent 协议层在过去一年被显著推前,从"协议本身能被用"演化到"协议本身能稳定承载生产流量"。每推前一步,工程侧的质量度量基线就必须同步推前一步。把"MCP server 工具描述质量不可量化"作为主要假设的部署,在 97% 缺陷率面前必然出问题。把"量化评分、CI 强制、多维度、持续评估、可被检索"作为基线,重新设计 MCP 协议层质量度量方案,是当下能落地的工程基线。
任何企业 Agent 项目,只要涉及 MCP 工具调用或类似协议的工具集成,工程基线就必须做到这五条——量化评分、CI 强制、多维度、持续评估、可被检索——否则,今天不是某次 Agent 选错工具的主角,也会是下一次 Agent 选错工具的主角。