什么时候 MCP 比 CLI 更有意义？

Source: Hacker News

我将大胆宣称：MCP 正在走向死亡。我们可能还没有完全意识到，但迹象已经显现。OpenClaw 不支持它，树莓派也不支持它，而且原因充分。

当 Anthropic 宣布模型上下文协议（Model Context Protocol）时，整个行业几乎陷入疯狂。各家公司争相推出 MCP 服务器，以证明自己是 “AI 优先”。大量资源被投入到新的端点、新的线格式、新的授权方案上，只为让大语言模型（LLM）能够与它们已经能够对话的服务进行交流。

我得承认，我从未真正理解过它的必要性。你知道大语言模型真正擅长什么吗？自行解决问题。给它们一个 CLI 和一些文档，它们就能立刻上路。

我曾很久想避免写这篇文章，但我确信 MCP 并没有提供现实世界的价值，我们不使用它会更好。让我来解释一下。

大语言模型不需要特殊协议

大语言模型非常擅长使用命令行工具。它们已经在数百万的手册页、Stack Overflow 的回答以及充满 shell 脚本的 GitHub 仓库上进行训练。当我让 Claude 使用 gh pr view 123 时，它就能直接工作。

MCP 承诺提供更简洁的界面，但实际上我发现自己仍然在编写相同的文档：每个工具的功能、它接受的参数，以及更重要的，何时使用它。大语言模型并不需要新的协议。

命令行界面也适用于人类

当 Claude 在 Jira 上出现意外行为时，我可以运行相同的 jira issue view 命令，看到它看到的内容。相同的输入、相同的输出，没有谜团。

而在 MCP 中，工具只存在于 LLM 对话内部。出现问题时，我只能在 JSON 传输日志中进行探查，而不是直接运行命令。调试不应该需要协议解码器。

可组合性

这正是差距扩大的地方。命令行界面（CLI）可以组合。我可以通过 jq 进行管道处理，使用 grep 链接，重定向到文件。这不仅仅是方便；它往往是唯一可行的办法。

考虑分析一个大型 Terraform 计划：

terraform show -json plan.out |
  jq '[.resource_changes[] | select(.change.actions[0] == "no‑op" | not)] | length'

使用 MCP 时，你的选择只有将整个计划转储到上下文窗口中（成本高且常常不可行），或者在 MCP 服务器本身构建自定义过滤。无论哪种方式，你都在付出更多工作却得到更差的结果。CLI 方法使用已经存在、文档完善且人类和代理都能理解的工具。

身份验证已经可以工作

MCP 对身份验证过于主观。为什么一个为 LLM 提供工具的协议需要关注身份验证？

CLI 工具并不在乎。aws 使用配置文件和 SSO。gh 使用 gh auth login。kubectl 使用 kubeconfig。这些都是经过实战检验的身份验证流程，无论是我在键盘前操作，还是 Claude 在驱动时，都能正常工作。当身份验证出现问题时，我会像往常一样修复：aws sso login、gh auth refresh。无需进行 MCP 特定的故障排除。

无移动部件

本地 MCP 服务器是进程。它们需要启动、保持运行，并且不能静默挂起。在 Claude Code 中，它们被作为子进程生成，这在大多数情况下有效，但有时会失效。

CLI 工具只是磁盘上的二进制文件。没有后台进程，无需管理状态，也不需要初始化的繁琐步骤。需要时它们就在，不需要时则隐形。

实际痛点

• 初始化不可靠。 我已经数不清有多少次因为 MCP 服务器没有启动而重新启动 Claude Code。有时重试就能成功，有时只能清除状态重新开始。
• 重新认证永无止境。 使用多个 MCP 工具？每个工具都要进行身份验证，真是麻烦。使用 SSO 或长期凭证的 CLI 根本不存在这个问题。认证一次就够了。
• 权限要么全部，要么全无。 Claude Code 只能按名称将 MCP 工具加入白名单，除此之外无能为力。无法将权限限定为只读操作或限制参数。使用 CLI 时，我可以把 gh pr view 加入白名单，但对 gh pr merge 则需要额外批准。这种细粒度的控制非常重要。

那么 MCP 何时有意义？

我并不是说 MCP 完全没有用。如果某个工具真的没有对应的 CLI，MCP 可能是正确的选择。我在日常工作中仍然经常使用它们，尤其是在它是唯一可用选项时。

我甚至可以争辩说，拥有一个标准化的接口是有价值的，而且可能确实存在一些使用场景，在这些情况下它比 CLI 更合适。

但对于绝大多数工作来说，CLI 更简单、调试更快，也更可靠。

真正的教训

最好的工具是那些对人类和机器都有效的工具。CLI 经过了数十年的设计迭代。它们可组合、易调试，并且依托已有的身份验证系统。

MCP 试图构建一种更好的抽象。结果发现我们已经拥有相当不错的抽象。

对构建者的呼吁

如果你是一家在投资 MCP 服务器但没有官方 CLI 的公司，请停下来重新考虑你的做法。先提供一个好的 API，然后再提供一个好的 CLI。代理程序会自行解决的。