实测 Claude Code 是否主动调用 MCP

给 AI 编程助手接上 MCP，工具就会被主动调用吗？DPOLens 的作者拿一个小商店后端做了测试：涉及个人数据的任务，Claude Code 每次都先查法规，再动代码。推动它这样做的关键，是 MCP 服务连接时发出的几句话。

这项实验值得读的地方，在于它把「工具好不好用」拆成了更靠前的问题：模型能否认出什么时候该用。结果也提醒我们，多加一层 skill，可能反而增加误调用。

接上工具之后，模型会自己想到查吗

DPOLens 是一个开源 MCP server，向 AI 助手提供隐私法规和组织内部政策，可以按条款检索。但搜索再准确，也得先有人发起查询。模型如果直接写下保存身份证件号码的代码，工具就没有发挥作用。

作者为此搭建了 Larder，一个小商店后端。它包含账户、订单、日志、Segment 分析事件和欢迎邮件，也包含不涉及个人信息的商品目录与首页。

测试共 30 个任务，分成三组：

• 12 个涉及个人数据的编码任务，例如把配送时核验的证件类型、号码存进订单，或在请求日志中加入客户端 IP 和 user agent。
• 15 个不涉及个人数据的编码任务，例如给商品列表添加 ?sort=price、?sort=newest，或给首页增加跟随系统设置的深色主题。
• 3 个规则问题，例如用户表泄露后，需要通知谁、多久内通知。

作者特意禁止编码任务出现「privacy」「GDPR」「consent」「compliant」。否则，提示词已经替模型指出了隐私问题，测不到它能否自主识别。

另外，15 个普通编码任务中，有 6 个专门测试边界。例如把 User.name 重命名为 displayName，虽然碰到了用户字段，却没有改变收集、保存或共享的数据。

该查时查、无关时不查，才是这次实验真正要验证的能力。

「36 次全中」能说明多少

每次运行都从新容器开始：固定 Claude Code 版本，使用空配置，通过 plugin marketplace 按 README 安装 DPOLens。没有 CLAUDE.md，没有记忆，也没有其他插件；项目使用全新的 Larder 副本，连接的 DPOLens 实例装有 GDPR。

测试使用 Claude Code 2.1.288 和 Claude Sonnet 5.5。每个任务重复 3 次，共 90 次运行。

评分规则也很具体：调用 search_policies 或 get_clause，才算查询，因为这两个工具会返回法规正文；查询发生在第一次文件编辑之前，才算「先查再写」。

结果是，12 个涉及个人数据的任务，合计 36 次运行全部查询，而且全部发生在首次编辑之前。所有任务在各自 3 次运行中的行为都一致，没有出现时查时不查。

不过，重复执行同一道题，和增加不同题目，提供的证据并不相同。作者给出的保守解释是：12 个任务没有漏查，只能把类似任务的漏查比例约束在「大概低于四分之一」，离保证永不漏查还很远。

还有一个更关键的边界：运行到首次搜索就停止了。因此，这项测试验证了模型是否去查法规，以及查得是否足够早，没有验证它能否正确理解条款、修改实现或完成后续工作。

为什么加了 skill，反而多查了三次

完整版 Claude Code 插件包含 MCP server、两个命令，以及一个描述使用时机的 skill。作者没有给出那两个命令的名称。

第一轮出现了 3 次被标为不必要的查询，全部来自同一个任务的 3 次运行：打开商品页时，向 Segment 发送 product_viewed 事件，携带商品 slug。

作者认为事件内容不包含访问者信息，所以标成无需查询。Claude Code 则去查了向 Segment 这类第三方发送商品浏览分析事件的问题。作者承认这个问题问得合理，但仍按预先标签计入误调用。

随后，他移除插件，只配置 MCP server，把全部 90 次测试再跑一遍。该查的仍然会查，Segment 任务却不再触发查询。

差异出在措辞。skill 描述要求「向其他服务发送数据时」使用 DPOLens；服务器指令则要求，在编写或修改收集、存储、记录、共享、删除「个人数据」的代码之前，以及回答政策或法律要求之前，先查询 DPOLens。

前者覆盖所有数据外发，后者限定个人数据。商品 slug 符合前者，却不符合作者对后者的任务标注。

工具使用说明需要写清触发条件，指令数量本身不能保证效果。

作者的做法是列出五种动作，再限定数据类型，并说明哪些内容算个人数据。这里的大白话解释就是：别只告诉模型「你有一个隐私工具」，要告诉它「遇到哪些代码变更，先停下来查」。

我的判断

我认同这项实验的方法：先定义该调用和不该调用的情况，再观察真实工具轨迹。它比展示几段成功对话更有说服力，尤其是重命名字段这类边界任务，能检查模型有没有只靠关键词触发。

但结论应收在这个测试范围里。作者只测了 Claude Code、一个模型，时间是 10 月；原文没有说明年份。Codex、Cursor 和 VS Code 中的 GitHub Copilot 虽然会读取相同指导，作者并没有测它们的执行情况。任务也都很短，项目较小，不能直接外推到业务链路复杂的大仓库。

Segment 案例同样存在标注前提。任务指定的事件字段没有个人信息，不代表完整集成链路一定没有关联身份；原文没有交代这些细节。因此，这三次查询更适合看作「不符合作者标签」，不能据此认定模型的顾虑毫无价值。

相较于不断往 CLAUDE.md 或 skill 里追加规则，先测试服务器连接指令是否已经够用，是合理的取舍。不过，实验只比较了这两种配置，不能推导出 skill 普遍多余，也不能说明查过法规的代码就符合要求。

能拿来做什么

• 给日常 AI 编程使用的 MCP 工具补上明确的触发条件，例如修改收集、存储、日志、共享或删除个人数据的代码前先查询，并写清数据范围。
• 在自己的 Node 项目中准备成对任务：一类增加 IP 日志或证件字段，另一类只重命名字段或调整商品排序，检查模型能否区分行为变化与普通维护。
• 从工具调用记录和文件编辑顺序判断规则是否生效，再单独检查查询结果有没有影响最终代码；这两步验证的是不同能力。
• 增加 skill 或项目规则前后，重复运行同一组任务，同时记录漏调用和多余调用，用结果决定新增说明是否值得保留。