2026 年 9 月 3 日,MCP 生态最重要的工具作者之一 punkpeye 在 Hacker News 发布《Show HN: MCP Tool Definition Quality Score (TDQS) Spec》——这是业界第一个针对 MCP 工具定义质量的开放评分标准,GitHub 仓库 glama-ai/tool-definition-quality-score 在一周内收到 8 分首页关注,1 条评论,1 条评论直接把行业里最关键的一句话放出来:"Bad tool definitions mean that tools are not selected when they should be, they are when they shouldn't, they are improperly invoked, etc." 同月 27 天,MCP Queen 发布《State of the MCP Ecosystem, July 2026》报告,用 43320 次实时探测给 9326 个 remote MCP server 打了 letter grade,披露了一个数字——29.2% 的 graded server 落在 D 或 F 档,17.2% 远程 server 是死的。把这两件事合起来读,可以非常清晰地看到一个长期被忽略但极其关键的工程问题——MCP 生态当前最致命的瓶颈不是协议能力,而是工具描述质量,而这件事正在被两套互相补全的方案同步解决。
## 一、MCP 工具定义质量为什么是当前最大的隐性瓶颈
punkpeye 在 MCP 生态里有多重身份——他维护 awesome-mcp-servers、FastMCP (Node.js)、ViteMCP、mcp-proxy、mcp-remote 等多个核心库,也是 Glama 的创始人。Glama 自己索引了 15000+ 开源和 remote MCP server,是从 day one 就盯着 MCP 生态质量问题的工程师。他在 HN 帖里直接给出一句话总结——MCP 生态里最大的抱怨一直是不一致的质量,而质量的最直接体现是 server 的 JSON 工具定义。
这件事为什么致命?因为工具定义是 Agent 唯一能读到的"自我描述"。当 Agent 收到一个工具列表,它会看每个工具的名称、描述、参数 schema 来决定调不调、调哪个、怎么调。如果描述写得稀烂或者写错,Agent 的行为会立刻出问题——该用工具的没用、不该用的反而用了、参数填错、调用时机不对。TDQS spec 团队用 856 个工具 / 103 个 server 做的实验给出一个精确数字:97% 的描述至少有一个缺陷,89% 的描述从来不告诉 Agent 何时应该用这个工具。改写描述本身就可以把任务成功率提升 6 个百分点。
但 MCP Queen 的报告补了另一半事实——MCP 生态的工具描述质量不是真正的问题。报告披露 99.7% 的工具带 typed input schema,99.5% 的工具带真实描述。问题在工具描述的"语义层"——形式合规但语义含糊,声明了 description 但没说何时该用。TDQS spec 正好补的就是这一层。
## 二、TDQS 的六个加权维度
TDQS spec 把每个 MCP 工具描述的语义质量拆成六个加权维度,每个维度用 1 到 5 分打分,有公开发布的评分锚点(anchors),有可重现的判断逻辑。这六个维度分别是:
Tool Purpose 工具目的是否清楚——描述是否明确说出这个工具做什么。这是最低门槛,89% 工具都过。
Usage Guidelines 使用指南——描述是否说明何时应该用这个工具而非替代工具。这是 TDQS 强调的核心维度,因为 89% 工具在这一项失分,而这一项恰好是 Agent 是否会选错工具的决定性因素。
Behavioral Transparency 行为透明度——描述是否披露注解(annotations)未声明的行为。例如 schema 说 read-only,描述是否同时说明这个工具会触发缓存清理或者外部副作用。
Parameter Semantics 参数语义——参数 schema 已经定义了类型和必填,描述是否补充了语义信息——例如业务含义、典型值、参数之间的约束关系。
Conciseness & Structure 简洁与结构——描述长度是否合适,关键信息是否前置。工具描述过长会让 Agent 在长 context 里稀释注意力,过短会让 Agent 拿不到决策信息。
Contextual Completeness 上下文完整性——根据工具的复杂度,描述是否完整。简单工具描述简短可以接受,复杂工具必须详细说明每个分支。
六个维度加权汇总成一个 letter grade,从 A 到 F 五档——genuinely helpful definition / adequate, the passing bar / severely deficient / reserved guard tier。TDQS 还定义了四个 server 级维度——Naming Consistency 命名一致性、Tool Count Appropriateness 工具数量合适度、Surface Gaps 表面覆盖度等——判断一个 server 整体的设计质量。
整套规范的工程价值在于它是 deterministic + judged 混合的——能由代码判断的部分(parameter coverage、output schema、behavioural hints、invocation cost、hash)完全用代码判断,精确到每一位;只有 description 这部分必须由模型判断六个维度,且 prompt 是 byte-for-byte 公开的。这种"代码判断能代码判断的部分,模型只判断必须模型的"分层,让整套评分可以无歧义复现,任何团队在自己的 CI 里都能跑出和 Glama 一模一样的分数。
## 三、TDQS 在 Glama 上的实测数据
punkpeye 在 HN 帖里披露 TDQS 在 Glama 索引的 15000+ MCP server 上跑过一轮,核心数据是"Well-described tools get picked about 2.6× more often"。这是一组对工程团队极其重要的数字——好的描述不是装饰,而是 Agent 实际行为的决定性因素。
TDQS 还在 spec 网站上公布了 calibration corpus 的具体规模——856 个工具 / 103 个 server 的实验。在这组样本里,97% 的描述带至少一个缺陷,89% 的描述从来不说何时该用工具。TDQS 把缺陷分成几类——missing 时机说明、参数语义缺失、行为透明度不足、上下文不完整、命名不一致、工具数过多或过少。每一类都有对应的修复方法。
改写描述本身的提升效果是 task success 提升约 6 个百分点——这意味着,即使模型不变、prompt 不变、工具列表不变,只是把描述写得更好,任务成功率就能从某个基线涨 6 个百分点。在企业 Agent 部署里,6 个百分点的成功率等于若干小时的客服时间和几百万的潜在损失,这是最低成本高回报的工程优化方向。
## 四、MCP Queen 的反向验证:协议工程的关键缺口
MCP Queen 在 7 月底发布的报告给出了一个完全不同的视角——它用 43320 次实时探测验证 9326 个 remote MCP server 的实际可用性,数据全部来自 7 月份的连续探测,数据集公开 CSV 给任何人复现。
报告披露的核心数字极其刺眼。在官方 MCP 注册的 18650 个"活跃"server 中,9338 个是 local-install only(只能 npx/uvx/docker 本地跑),9326 个声明了 remote endpoint。MCP Queen 对这 9326 个 remote server 做连续探测,结果是 7723 个能联通(82.8%),1603 个是死的(17.2%)——大约每六个"声称活着"的 server 里就有一个实际上不响应。
剩下的 7723 个 server 接受 letter grade 评分,维度是:reachability 25 分、protocol compliance 15 分、tooling quality 35 分、latency 10 分、provenance 15 分,总分 100。最后一个数字更狠——29.2% 的 graded server 落在 D 或 F 档,绝大多数原因是 dead endpoint、坏掉的 initialize 握手、或者干脆没有工具。
auth 状况也不乐观。5201 个 server(55.8%)完全开放无 auth,这意味着任何 Agent 都能调,但同时也意味着任何攻击者都能调。剩下 27.0% 的 server 是 auth-gated provisional——它们设了 auth 但握手实现错了,客户端甚至无法正常发现应该怎么认证。
但 tooling 部分数据是积极的——99.7% 工具带 typed input schema,99.5% 带描述。MCP Queen 的结论很明确——"The ecosystem's problem is not tool quality. It is that a large minority of servers cannot be reached or introspected at all."
## 五、把 TDQS 和 MCP Queen 合起来看
把两件事放在一起看,会出现一个非常清晰的工程图景。
第一层,MCP 生态当前的最基础问题是"连通性",不是"描述质量"。MCP Queen 的探测数据显示 17.2% 远程 server 是死的,29.2% 是 D/F 档。这意味着 Agent 在调用工具之前,先要面对一个事实——列表里有 1/6 的 server 调不通。任何 Agent 平台必须先解决连通性过滤,才能进入描述质量的评估。
第二层,工具形式合规度高,语义质量低。MCP Queen 数据 99.7% typed schema + 99.5% 描述说明 schema 层已经很成熟,但 TDQS 的 97% 缺陷率说明 description 层的语义信息还有巨大提升空间。这两件事的交集——形式合规但语义缺失——恰好是 Agent 行为异常的温床。
第三层,letter grade 让生态可以被治理。TDQS 给每个工具一个 letter grade,可以被 CI 门禁(release gate)直接消费。MCP Queen 给每个 remote server 一个 letter grade,可以作为 MCP 客户端在选 server 时直接消费的信号。两套 grade 合起来,让 MCP 生态第一次具备了和 npm/PyPI 这种成熟包管理生态类似的"评级基础设施"——开发者发布前自己跑 grade,运维选型时按 grade 过滤。
第四层,评分是动态的,不是一次性的。MCP Queen 在报告里强调"Grades here churn daily as servers die and recover. Point-in-time directories go stale in days; continuous probing is the only honest signal."TDQS spec 也强调任何 grade 都必须能在 CLI / playground / hosted API 三处跑出同样的数字,hash 一致才算合规。一次性评分在这个生态里基本没有意义,持续评测才是基础设施。
## 六、企业级 MCP 平台需要的能力
把这两件事映射回企业落地,会得到一份企业级 MCP 平台必须具备的能力清单。
第一条,工具描述必须经过 letter grade 校验。任何内部 MCP server 在 release 前必须跑 TDQS scoring,letter grade 必须达到 B 或以上,低于 B 的不允许发布。这条规则直接照搬 TDQS spec 的 fail-under B 默认值,简单有效。
第二条,工具描述必须有明确的"何时用"段落。Usage Guidelines 是 TDQS 六个维度里最关键的一项,89% 工具失分在这一项。企业 MCP 平台应该把"何时用 vs 替代工具"作为强制模板字段,任何工具描述缺这一段直接 publish fail。
第三条,工具 catalog 必须经持续连通性探测。MCP Queen 用 43320 次探测证明 17.2% 远程 server 是死的,这个比例在企业内部可能更高——内部 MCP 经常在开发环境跑、生产环境没人维护、或者干脆开发者离职后无人接手。企业 MCP 平台应该跑一个常驻的连通性 + auth + tool listing 探测 pipeline,letter grade 低于 C 的 server 自动 disable。
第四条,letter grade 必须进入 CI 流水线。TDQS 提供了 CLI、API、playground 三种接入方式,任何 MCP server 在 merge request 阶段都应该跑一次 grade,把 grade 写到 commit message 和 PR description 里。letter grade 倒退的 PR 必须显式标注。
第五条,letter grade 必须展示给最终用户。TDQS 提供 SVG badge 可以塞 README,MCP Queen 提供 trust report 链接。让用户在选用 MCP server 时能看到 grade,这才是评级生态真正发挥作用的前提——开发者会为了 grade 而优化描述,企业会为了 grade 而禁用低分 server。
## 七、下一步:MCP 协议工程会怎么走
把这件事放到更大的图景里看,MCP 协议工程当前已经从"协议能力建设"过渡到"生态质量治理"。早期 MCP 协议是给 Agent 一个标准化的工具调用接口,接下来两年的重点会是把生态从 15000 个 server 筛选到几百个高可靠 server,让 Agent 真正能在生产环境放心调用。
TDQS spec 在这个转折点上提供了一个明确的模板——letter grade + 加权维度 + byte-for-byte 公开 prompt + deterministic where possible / judged where necessary + 多入口实现一致性。任何后续的 MCP 工具质量规范都会引用这套方法学。MCP Queen 的报告则在更高层面提供了一份 state of the ecosystem 基线,让任何治理工作都能看到数字对比。
对企业 IT 来说,这意味着 MCP 评估标准正在快速固化。未来一年内,任何生产环境 MCP 平台都需要同时满足:协议能力(MCP 规范版本)、工具描述质量(TDQS grade)、运营可靠性(MCP Queen grade)、安全合规(auth 模式 + audit log)。把这四条交叉验证才能确认一个 MCP server 是否可以进入企业生产环境。
回到一开始的问题——MCP 工具定义质量分(TDQS)规范和 MCP Queen 的实测报告合起来,把"MCP 生态当前最致命的瓶颈不是协议能力而是工具描述质量"这件事第一次用数字钉死。剩下的就是企业 IT 在落地时把这套标准真的用起来,把 letter grade 接入 CI、接入采购流程、接入 Agent runtime 的工具选型决策。一年内,MCP 生态会从 15000 个 server 收拢到几百个高可靠 server,这是协议工程走向成熟的标志,也是企业 Agent 真正能大规模落地的关键一步。
