MCP 注册表随机抽样审计精读：48.8% 握手率背后的工具生态幸存者偏差

题目：What a Random Draw from the MCP Registry Contains, and What Tool-Use Benchmarks Contain Instead 链接：https://arxiv.org/abs/2609.10962 团队：Independent researcher（Haseeb Mohammed Afsar） 数据日：2026-09-11

一、题目与背景

MCP（Model Context Protocol）生态研究正在爆炸：工具选择、安全审计、基准评测都依赖从注册表抽服务器。但所有既有研究的抽样方式都在悄悄筛选"能跑的服务器"——引用集（reference sets）、流行榜、手工精选框架（curated frames）、或者"修复到能启动为止"的管线。这些样本回答不了的问题是：一个不加修复的随机 MCP 服务器，接上会发生什么？

这个问题的重要性在于生态测量的方向性偏差：如果一半以上的服务器在握手阶段就死掉，那么基于精选样本的"生态安全水位"“工具质量分布"结论都在描述一个比现实更健康的平行世界。测量学的第一课：样本怎么来的决定了结论能说什么。

二、研究定位

这是一篇测量（measurement）论文而非方法论文，对标 MCP 生态的既往快照审计与 Bharti 的 88.6 天/19,099 服务器漂移追踪（那篇聚焦 drift，本文做的是横截面概率抽样的"生态体检”）。独特之处：不修、不筛、不弃——抽到什么测什么，把失败模式本身当作发现。

三、问题定义

三个研究问题：RQ1——未修复的随机样本里有什么（可启动率、失败模式分布）；RQ2——能跑起来的服务器长什么样（协议硬一致性、安全注记、协议版本）；RQ3——基准语料与真实部署工具的关系（冗余度、近重复结构）。

四、解法

• 普查层：24,135 个注册表服务器全量清点。
• 抽样层：概率抽取 400 个有 published seed 的 npm/stdio 服务器——seed 的存在保证了可复现（任何人可重放同样的样本）。
• 探测层：逐个在线（over the wire）执行 initialize 握手、拉取工具清单、检查 JSON Schema 硬一致性（致命违规）、可选安全注记（readOnlyHint 等注解）、协议版本协商。
• 冗余层：对工具描述语料做 MinHash 近重复聚类，定位"原始发布多为重复"的结构。

五、实验结果

两个方向的修正同时成立：随机样本比精选样本更糟（握手、安全注记），但能跑的部分在协议合规上完美——生态的问题是"存活率与标注"，不是"质量参差"。工具描述与实际行为的关系、以及基准语料用近重复撑体积的结构，直接制约 tool-use benchmark 的效度（与 SWE-bench 系的 shortcutting 批评同构）。

六、知识反推

1. “能跑"本身就是筛选变量。任何以启动为前提的采样（修复管线、精选列表）都在对生态做条件化——条件化后的指标（安全率、质量分）不能回推总体。做生态研究先报告"条件化率”（本文的 48.8%），它决定所有后续数字的外推范围。
2. 协议合规与运维健壮性是两个正交轴。硬一致性 100% 说明协议规范的机器可校验部分执行得极好；37.5% 无法启动说明打包/依赖/环境的工程实践极差。生态干预（注册表准入检查、CI 模板）应瞄准后者而非继续加规范约束。
3. 基准语料的近重复结构会制造能力幻觉。工具评测集里头部家族的近重复条目让"见多识广"的模型得分虚高——基准设计需要显式的多样性约束（dedup + 家族配额），这一课与代码基准的去重完全同构。

七、通用灵感

• 给依赖外部生态的系统做"条件化率审计"：你的 Agent 接插件市场/Skill 仓库/API 集成面，“装上就能用"的比例是多少？先测这个无条件数字，再谈质量——它决定真实部署的故障预算。
• 抽样框要可复现：published seed 的设计让"我抽的样本"变成"任何人可重放的样本”，审计结论因此可检验。给任何评测/采样工作配上种子与抽帧协议，是被引用的必要条件。
• 把失败模式当结果报告：13.3% 缺凭证 vs 37.5% 起不来的区分直接改写干预优先级。测量工作里"失败的具体形状"往往比均值更有信息量。