我要先抛出一个大胆的观点：MCP 已经在走下坡路了。我们现在也许还没有完全意识到，但迹象已经在那里了。OpenClaw 不支持它。Pi 不支持它。而且这是有充分理由的。
当 Anthropic 发布 Model Context Protocol（模型上下文协议）时，整个行业几乎集体沸腾。每家公司都急着推出 MCP 服务器，以证明自己是“AI first”。大量资源被砸进新的端点、新的通信格式、新的授权方案，只为了让 LLM 能和那些它本来就已经能对话的服务继续“对话”。
我承认，我一直都没完全理解为什么需要它。你知道 LLM 真正擅长什么吗？自己把事情搞明白。给它一个 CLI，再给它文档，它就能立刻开工。
我其实一直不太想写这篇文章，但我现在确信，MCP 在现实世界里并没有提供什么真正的收益，而且没有它我们反而会更好。下面我来解释原因。
LLM 并不需要一种特殊协议
LLM 非常擅长使用命令行工具。它们已经在数百万份 man page、Stack Overflow 回答和 GitHub 仓库里的 shell 脚本上受过训练。当我让 Claude 用 gh pr view 123 时，它就是能直接用。
MCP 承诺提供一个更干净的接口，但实际使用中，我发现自己还是得写同样的文档：每个工具是做什么的、接受哪些参数，更重要的是，应该在什么时候使用它。LLM 并不需要一个新协议。
CLI 也是给人类用的
当 Claude 在 Jira 上做出某些出乎意料的事情时，我可以直接运行同样的 jira issue view 命令，看见它看到的内容。输入一样，输出一样，没有任何神秘之处。
而在 MCP 里，这个工具只存在于 LLM 的对话内部。出了问题，你就得钻进 JSON 传输日志里摸索，而不是自己直接跑一遍命令。调试不应该还得先拿个协议解码器。
可组合性
这正是差距被真正拉开的地方。CLI 天生可以组合。我可以接 jq，可以串 grep，可以重定向到文件里。这不只是方便，很多时候甚至是唯一现实可行的方式。
比如分析一个大型 Terraform plan：
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'如果用 MCP，你的选择只有两个：要么把整个 plan 全都塞进上下文窗口（代价高，而且往往根本做不到），要么就在 MCP 服务器里自己实现定制过滤逻辑。无论哪种，你都做了更多工作，结果却更差。CLI 的方式则是直接利用那些已经存在、文档完善、并且人类和 agent 都能理解的工具。
认证本来就已经能工作
MCP 在认证这件事上加入了太多不必要的主张。一个只是给 LLM 提供工具使用能力的协议，为什么还需要自己去管认证？
CLI 工具根本不需要这样。aws 用 profile 和 SSO。gh 用 gh auth login。kubectl 用 kubeconfig。这些都是经过实战检验的认证流程，不管是我自己在键盘前操作，还是 Claude 在驱动，工作方式都一样。认证出问题时，我就按原来的办法修：aws sso login、gh auth refresh。完全不需要做任何 MCP 专属排障。
没有额外运转部件
本地 MCP 服务器是进程。它们需要启动、保持运行，还不能悄悄卡死。在 Claude Code 里，它们会以子进程的形式被拉起，这套机制在能工作时确实能工作，但问题是它并不总能工作。
CLI 工具只是磁盘上的可执行文件。没有后台进程，没有额外状态要维护，没有初始化仪式。你需要它时它就在那里，不需要时它也不会制造存在感。
实际使用中的痛点
除了设计理念之外，MCP 在日常使用里还有很具体的摩擦：
初始化不稳定。 我已经记不清有多少次因为某个 MCP 服务器没起来，而不得不重启 Claude Code。有时重试就好了，有时则得清状态、从头再来。
重新认证没完没了。 你在同时使用多个 MCP 工具？那就准备好一个个重新认证吧。带 SSO 或长期凭证的 CLI 根本没这个问题。认证一次，就结束了。
权限控制要么全给，要么不给。 Claude Code 可以按名称对白名单中的 MCP 工具放行，但也就到此为止了。你不能把权限限定为只读操作，也不能限制参数范围。而对 CLI，我可以允许 gh pr view，但对 gh pr merge 依然要求审批。这种细粒度是很重要的。
那么，MCP 什么时候才有意义？
我并不是说 MCP 完全没用。如果某个工具确实没有对应的 CLI，那么 MCP 也许就是正确选择。在我日常工作里，我也还在用不少 MCP，尤其是在它是唯一可用方案的时候。
我甚至愿意承认，拥有一个标准化接口本身是有一定价值的，而且也确实可能存在某些场景，让它比 CLI 更合理。
但对于绝大多数工作而言，CLI 更简单、更容易调试，也更可靠。
真正的启示
最好的工具，是那些既适合人类，也适合机器的工具。CLI 已经经历了几十年的设计迭代。它们可以组合、可以调试，而且还能直接复用已经存在的认证系统。
MCP 试图建立一个更好的抽象层。结果却是，我们其实早就已经有一个足够好的了。
如果你是一家公司，正在投入资源做一个 MCP 服务器，但你甚至还没有官方 CLI，那你应该停下来，重新想想自己在做什么。先把 API 做好，再把 CLI 做好。至于 agent，它们自己会搞明白的。