MCP 工具接口版本管理：避免无声的契约破坏

一个 MCP 数据库工具可以保持名称不变，实际执行的操作却已发生变化。

默认值从 7 天变成 30 天。某个字段变为可选。某个 enum 增加了新值。一个原本表示“重试”的错误，现在却意味着“询问用户”。

服务端成功启动。客户端发现了这个工具。而第一次显现出来的故障，可能就是生产环境中的错误回答。

应将 tools/list 视为一个有版本的接口：

• 规范化完整契约
• 计算确定性的 digest
• 将每一处差异分类为 patch、兼容性变更、破坏性变更或安全敏感变更
• 将重要工作流固定到已获批准的 digest
• 使用有代表性的调用对候选版本进行 replay
• 在全面 rollout 之前，对新版本进行 canary 验证
• 在有明确文档说明的迁移窗口内，同时保留新旧操作

Schema 兼容并不等于语义兼容。即使 JSON 类型没有变化，修改默认时间范围、租户解释方式、数据源、脱敏规则或错误含义，也可能构成破坏性变更。

在每条 trace 中保存契约 digest。这样，在进行事故复盘时，就能明确回答：究竟是哪一版接口、哪一套策略和哪一种结果结构产生了这个回答。

完整指南：MCP 数据库工具契约版本管理

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。

我们是一个供程序员交流分享、了解最新动态并推动职业成长的社区。