MCP 已死吗？评估模型上下文协议与 CLI 优先策略
模型上下文协议（Model Context Protocol，MCP）曾被誉为 AI 生态系统的 “USB‑C”，承诺提供一种通用标准，将大型语言模型（LLM）连接到 GitHub、Slack、Notion 等外部工具。然而，随着开发者从早期尝鲜转向日常生产使用，一场激烈的争论浮出水面：MCP 是优雅的解决方案，还是阻碍性能的过度设计层？
最近，Quandri 工程团队的分析表明，对于许多开发者工作流来说，MCP 可能是一种不必要的抽象。通过将 MCP 与 “CLI‑first” 策略以及 “Skills” 模式进行对比，他们认为该协议往往在上下文消耗和运行可靠性方面带来显著开销。
反对 MCP 的理由：上下文与可靠性
对 MCP 的主要批评集中在它如何使用 LLM 的上下文窗口上。在标准的 MCP 设置中，工具定义——即告诉 LLM 工具功能及调用方式的模式——通常会提前加载。
“上下文膨胀”问题
Quandri 的测量显示，工具定义会吞噬出乎意料的大量上下文窗口。在他们的堆栈中，仅连接四个 MCP 服务器（Linear、Notion、Slack 和 Postgres）就消耗了约 21,077 个 token。对于拥有 128K 窗口的 GPT‑4o 来说，这相当于在实际工作开始前就已经占用了 16.5% 的可用“桌面空间”。
Linear 是一个特别突出的例子，42 条工具定义就占用了超过 12,800 个 token。这意味着模型必须携带每一种可能的 Linear 操作的重量，即使用户只需要一次 get_issue 调用。
运行开销
除了 token 之外，MCP 的架构层还引入了若干运行摩擦：
- 延迟：每一次 MCP 调用都会在 LLM 与 API 之间增加一个处理层。基准测试显示，MCP 在初始化阶段尤其比直接的 REST API 调用慢得多。
- 可靠性：MCP 服务器是独立进程，可能在会话中途崩溃或在认证阶段失败，导致 AI 对话中出现不透明的错误。
- 冗余：对于开发者而言，MCP 常常与已有的命令行界面（CLI）功能重叠。如果某工具已经拥有稳定的 CLI，创建 MCP 服务器往往意味着在一种更难组合的格式中重新实现相同功能。
替代方案：CLI‑First 与 Skills 模式
为了解决这些问题，一些团队开始采用 CLI‑First 策略。他们不使用专门的协议，而是向 LLM 提供 CLI、本身的 API 文档以及必要的环境变量。这种做法利用了 LLM 已经在大量手册页和 StackOverflow 数据上进行过训练的事实。
Skills 模式
MCP 被描述为 “一次性把所有菜单摆在桌面上”，而 Skills 模式 更像是 “向图书管理员只要你需要的那本书”。
在这种模型下，LLM 只在特定技能被调用时才加载该工具的具体指令（例如用于 Linear Issue 查询的 curl 命令）。这避免了上下文窗口被未使用的工具定义永久占用。例如，通过 CLI 执行一次 Linear 查询大约消耗 200 个 token，而 MCP 方式则需要约 12,957 个 token。
反驳观点：MCP 仍有价值
尽管有上述批评，许多行业专家——包括 OpenAI 的人员——认为 “MCP 已死” 的说法忽视了更大的图景。该协议的价值不在于传输层，而在于 服务发现的标准化。
对非开发者的可及性
CLI 对工程师来说很强大，但对人力资源、财务或营销团队来说几乎是不可行的。MCP 为非技术用户提供了一种通过 UI（如 Claude 或 ChatGPT）连接服务的方式，无需安装二进制文件或管理 SSH 密钥。
安全性与防护栏
安全是 MCP 最有力的论点之一。基于 CLI 的代理拥有执行用户所有权限命令的能力，甚至可以执行 DROP TABLE 等危险操作。而 MCP 服务器可以充当安全代理，在查询到达数据库之前就实现只读模式、查询校验等防护。
“长尾” API
并非所有服务都有 CLI。许多 SaaS 产品仅提供网页界面或复杂的 API，且这些 API 并未针对 LLM 使用进行设计。MCP 让这些公司能够构建一个 “桥梁”，使其服务能够被代理使用，而无需用户自行编写包装脚本。
综合：选择合适的工具
争论表明，MCP 与 CLI 之间的选择并非二元对立，而是基于使用场景的光谱：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 本地开发 / 个人工具 | CLI + Skills | 速度最快，token 成本最低，终端调试最方便。 |
| 企业 / 共享团队 | MCP | 集中式认证、权限范围划分，便于非技术用户上手。 |
| 生产数据库 | MCP | 确保查询安全与访问控制。 |
| 无 CLI 的 SaaS | MCP | 提供结构化工具访问的唯一可行方式。 |
结论
随着生态系统的演进，MCP 的技术摩擦——例如上下文膨胀——正逐步得到解决。Claude Code 中引入的 Tool Search with Deferred Loading 已经通过按需加载模式将上下文使用量降低了超过 85%。
最终目标并非寻找唯一的 “制胜” 协议，而是优化信息流动。无论是轻量的 CLI 还是强大的 MCP 服务器，核心任务始终相同：最小化上下文窗口噪声，最大化工具执行的可靠性。