我们真的需要 MCP 吗？
先说清楚一件事，否则整篇文章就成了对着稻草人打靶：我只讨论在本地运行的 MCP 服务器，也就是和 agent 跑在同一台机器上的那种，比如用 npx whatever-mcp 启动、用来连接你的数据库、文件或基础设施的服务。云端远程 MCP 服务器是另一回事：它们让浏览器中的 agent 通过 OAuth 访问某个 SaaS 服务，解决的是另一个问题，我对它们没有意见。如果你关心的是这种场景，这篇文章不是写给你的。
好了，下面说说一直让我不舒服的地方。
我想让编程 agent 在长时间构建结束后发一条 Slack 消息。2026 年的标准答案是：找一个 Slack MCP 服务器，把它加进 JSON 配置，把 webhook 粘贴到环境变量里，然后重启客户端。如果我使用三个不同的 agent 工具，就得用三种不同的配置格式，把这件事重复做三遍。
而整个过程里，我脑子里一直有个声音在问：agent 本来就有 shell，我为什么还要装一个服务器？
看看本地 MCP 服务器到底是什么：它是我机器上一个长期运行的进程，以我的用户身份运行，环境变量里带着我的凭据，通过 stdin 用 JSON-RPC 跟 agent 通信；而同一个会话里的 agent 本来就能执行任意 shell 命令，也能发起 API 调用，用的同样是“我的凭据”（agent 以用户凭据行事本身就是个大问题，文末再展开）。这里根本不存在安全边界。agent 完全可以绕过服务器，直接自己动手。服务器纯粹是一层接口。
所以真正的问题比乍看之下要窄：对于一个已经能访问 shell 的 agent 来说，JSON-RPC 服务器真的比一个好用的 CLI 更合适吗？
也许吧。MCP 从一开始就为 agent 设计，有定义良好的输入 schema，通常也会返回结构清晰、可预测的 JSON。但是……
我们早就知道 agent 很会用 CLI。它们今天就能熟练使用 gh、docker、kubectl、stripe，而最顶尖的 harness 还依赖 cat、grep、curl、ssh，既不需要协议层，也不需要为每个客户端单独配置。没有人给 git 写 MCP 服务器。也没人觉得有这个必要。
我通过实际构建并在日常使用中发现，答案可以是一个再普通不过的命令行工具（CLI），在我的场景里就是一个二进制文件，用一条简单的 curl 命令安装，就像市面上成千上万的其他 CLI 工具一样：
安装 CLI：
curl https://whatever.com/my-cli/install.sh | sh
安装时会问一句：要不要安装 my-cli 的 SKILL.md？这个技能文件可以向 agent 解释 CLI 的用法，并暴露部分命令。但其实你直接让 agent 调用 --help 就行——这样 agent 就知道了每个命令的输入结构，而按照约定，--json 告诉它该期待什么输出格式。整套思路就是这么简单。
这个方案可能哪里不对
我写这篇文章，就是想搞清楚哪个反驳能真正推翻它。我相信这样的反驳应该不少，下面是我目前能想到的候选。
也许 schema 比我以为的更重要。 我认为 --json 输出加上严格校验，再加上能够纠正 agent 行为的错误信息，或许足以弥补错误调用的差距。但我还没测过 agent 调用 CLI 与调用 MCP 工具的错误率对比。应该有人去测一下。我是真心想看到这份数据。
也许无 shell 的环境才是未来。 如果大多数 agent 的使用场景都迁移到没有 shell 的沙箱环境，那 CLI 优先就成了小众选择，MCP 反而成为默认方案，我说的“可信本地开发机”这个前提也就没那么重要了。
也许我低估了 MCP 存在的根本原因。 N×M 集成问题确实存在。CLI 加 Skill 的约定说白了也只是另一种标准，而且是一个非常薄的标准——而“非常薄的标准”，恰恰是所有人都在碎片化之前会说的话。
也许长连接才是常态，而不是边缘情况，那些做一次性 CLI 的人最后都会把守护进程写得很糟糕。
如果你有指向任一方向的经验，尤其是在错误率方面，那正是我希望看到的反馈。
双方都没解决的问题——但我觉得我找到了突破口
有件事我一直在反复琢磨，它对 MCP 和我的 CLI 方案同样适用：两者都没有回答信任问题。无论用哪种接口，最终状态都一样——我没读过的第三方代码，带着我的权限运行，握着我的凭证，由自主智能体驱动。相比之下，JSON-RPC 和命令行参数的区别几乎是表面功夫。如今想知道一个工具到底会做什么，只有三条路：读源码、扫描代码，或者祈祷。
简单说说我的实现：工具附带一份签名清单，精确声明它需要什么——哪些主机、哪些路径、哪些密钥。人类审批一次。然后运行时强制执行边界，代码无论下一步做什么，都物理上无法超出已批准的范围。智能体可以使用授予的权限，但不能扩大它。代码可以使用密钥，但不能读取它。
我把一些想法和实际实现写在了《攻击已授权：AI 智能体缺失的安全边界》这篇文章里，到目前为止，用这种方式运行我自己的工具还算站得住脚。
我在这里提它，是因为它重新定义了上面的一切：CLI 与 MCP 之争关乎便利性。我们真正该讨论的是权限。
我真正想问的
如果你构建过 MCP 服务器：它真的是你这个工具的最佳接口，还是你为了让智能体能使用它而默认构建的东西？
如果你的工具本来就已经是 CLI，那层封装在本地使用时到底增加了什么？