近23万条MCP工具参数数据集发布

做 AI Agent 安全检查，先得知道它能调用哪些工具、每个参数接受什么。Correctover 发布了一份包含 229,827 条工具记录的 MCP 数据集，每条都带有机器可读的 input_schema，试图为参数风险研究提供可核验的样本。

这份数据值得看的地方，不只是规模。作者调查了 42,163 个服务器，只有 13,120 个具备工具级参数 Schema。不过，「没有采集到参数定义」与「部署的服务器不提供参数定义」之间，还需要方法细节来支撑。

为什么检查工具名还不够

工具名能告诉你大概能做什么，参数定义才决定 Agent 如何发起调用。同样是一个读取工具，接收 URL、文件路径，还是可以拼入命令的字符串，风险并不相同。

作者关注的是参数级风险分类：哪些参数可能携带 URL、文件路径或 Shell 片段。这些入口与注入攻击、数据外传有关，也是安全工具需要重点识别的位置。

input_schema 就是 Agent 调用工具时能读到的参数说明。它可以作为风险识别和调用检查的依据，但原文没有展示任何拦截实现，也没有给出攻击防御效果的数据。

参数定义提供检查依据，实际拦截还需要额外机制。

作者同时提出了一份 IETF 个人草案 draft-correctover-gg-mcp-parameter-risk，希望为这些参数建立统一的风险分类。这份数据集是该草案的经验基础。这里的「个人草案」不能当成已经通过的标准，原文也没有交代其后续状态。

229,827 条记录，能证明什么

作者称，这是目前已知规模最大的同类数据集，包含 229,827 条工具记录，来自 13,120 个具有工具级 Schema 的服务器。调查总量则是 42,163 个服务器。

另外约 29k 个没有工具级 Schema 的服务器也被记录，但没有继续展开工具参数。这让数据集同时呈现了两件事：已经获取的参数定义，以及调查中未获取到这类定义的服务器。

需要分清统计单位：229,827 是工具记录数，42,163 是被调查的服务器数。原文没有说明工具记录如何去重，不能直接理解为存在这么多种互不重复的工具能力。

在数据完整性上，作者声明做了字节级计数核验，畸形记录为零，并提供 SHA-256 校验依据，允许使用者自行验证数据包。数据集以 CC0 发布，校验哈希、引用方式和方法说明放在仓库中。

这些措施有助于确认拿到的是哪一份数据，以及记录能否被正常解析。它们不能证明每份 Schema 都准确描述了工具行为。作者也明确承认，不同服务器的 Schema 质量存在差异。

我的判断

我认可它把关注点推进到参数层。对于安全研究和工具调用合规检查，仅有服务器清单或工具名称，确实不够生成细致的检查用例。机器可读的参数定义更适合做批量分析。

但原文有两处需要保留判断。

首先，采样偏向英语内容，且约 29k 个服务器没有展开参数。因此，这份数据适合研究已采集样本，不能直接代表整个 MCP 生态。「大多数已部署服务器不暴露机器可读参数」是作者给出的判断；原文未提供足够方法细节，无法排除采集条件对结果的影响。

其次，原文没有提供与其他数据集的规模对照，也没有给出风险分类的准确率、误报率或拦截效果。「目前已知最大」应保留为作者声明，安全收益也不能靠记录数量推导。

相比只收集服务器地址，这份数据更适合研究参数；相比真实调用测试和运行时验证，它提供的是静态描述。两类工作可以配合，不能相互替代。

能拿来做什么

• 如果你在 Node 项目中开发 MCP 安全检查工具，可以把这份数据集作为批量输入，先识别可能承载 URL、路径和 Shell 片段的参数，再抽样核对分类结果。
• 如果你在生成工具调用的合规测试，可以依据 input_schema 生成测试输入，同时单独记录 Schema 缺失或质量不足的情况，避免把无法检查算作检查通过。
• 如果团队正在选用 MCP 服务器，可以检查其参数定义是否完整、是否与实际调用行为一致，并把数据包的 SHA-256 和使用版本记录下来，方便复现分析结果。