MCP 是一套开放协议，让 agent 能接上外部的工具和数据源。 接得越多它越能干——也越危险。 这一篇讲怎么按风险给工具分级，以及一条比什么都管用的原则：最小工具集。
本文写什么MCP 是什么、工具的风险分级、装第三方 server 的代价。 本文不写我们自己接了哪些 server。
一句话：一套让模型和外部工具对话的开放协议。
在它之前，每个工具都要为每个 agent 单独适配一遍。有了协议之后变成两边各实现一次： 一边是 server（提供能力的那头，比如一个数据库、一个 API、一个文件系统）， 另一边是 client（agent 那头）。任意组合。
对使用者来说，实际感受就是：装一个 MCP server，agent 就多了一组新能力。 这也是它的风险来源——装得太顺手了。
市面上给工具分级的方式很多，最实用的是这一种，因为它直接对应后果的不可逆程度：
| 级 | 能力 | 最坏后果 | 默认态度 |
|---|---|---|---|
| 🟢 只读 | 读文件、查数据库、搜索 | 读到了不该读的东西（但还在你机器上） | 可以开 |
| 🟡 可写本地 | 改文件、跑命令、改配置 | 搞坏本地状态。有版本控制就能退 | 看情况，配好权限 |
| 🔴 能对外发出 | 发消息、发邮件、调外部 API、动钱、发帖 | 不可撤销，而且可能到别人那里 | 默认不开 |
前两级的错误都还关在你的机器里，你能回滚、能重来。 第三级一旦执行，东西已经出去了——消息发出去了、钱转走了、帖子公开了。
而这一级恰恰是最容易被「顺手装上」的：接个消息推送、接个邮件、接个自动发布， 每一个单独看都很方便。
推荐姿势：红色能力永远保留一道人工确认， 哪怕这让自动化不那么「全自动」。第 10 篇那条判据 （做错了你承受得起吗）在这里落地。
只读工具能把敏感内容读进上下文，对外工具能把上下文里的东西发出去。 两个单独看都「还好」，凑在一起就是一条完整的泄漏链路。
这也是上一篇第二层威胁真正危险的原因： 被骗的 agent 如果同时拥有这两类工具，一句话就能把你的密钥送走。
MCP server 是一个真实的程序，跑在你的机器上，通常拥有你给它的全部权限。 「装一个 MCP server」在信任模型上，等同于「装一个来路不明的命令行工具并且给它跑」。
而且它比普通工具多一层：它的工具描述会进入模型的上下文—— 也就是说，server 作者写的文字，会作为指令性内容被模型读到。
三条自保：
① 优先用开源且你能看懂来源的；
② 装之前看一眼它要什么权限——一个「查天气」的工具要读你的 home 目录，那就不对；
③ 不确定的先在隔离环境里跑（Docker 或远端沙箱，见第 17 篇）。
这一条很多人不知道：每个启用的工具，它的名字和描述都要占上下文。
后果有两重：
| 后果 | 说明 |
|---|---|
| 更贵 | 工具定义是每一轮都要重发的固定开销（第 9 篇） |
| 更笨 | 可选项越多，选错的概率越高。二十个工具里挑一个，比五个里挑一个更容易挑歪 |
大部分工具支持随时开关（Hermes 是 hermes tools）。
正确姿势是常态只留一小组，需要时临时开，
而不是「反正装着也不碍事」。
一个自检：你能不能一口气说出当前启用了哪些工具？ 说不出来就是装多了。
如果不知道从哪开始，这是个能覆盖大多数场景的起点：
| 要 | 不要（一开始） |
|---|---|
| 读文件 / 搜索 | 任何能发消息、发邮件的 |
| 跑命令（配好 deny 规则） | 任何涉及支付、转账、下单的 |
| 版本控制操作 | 任何会公开发布内容的 |
| 抓网页（只读） | 能改你账号设置的 |
右边那一列不是「永远别用」，是「等你对这套东西的行为有把握了再说」。 先用两周，再决定要不要往上加。
hermes tools 启用/禁用工具。官方文档，2026-08-21 核。