一个AI创业团队的实测结果：4台MCP服务器占用了Claude 10.5%的上下文窗口，同样一次Linear查询，MCP比CLI多消耗65倍token。但MCP并非全无价值——在数据库安全和团队协作场景，它依然是不可替代的选择。
事件回顾：MCP争议再起
2026年5月29日，加拿大AI保险科技公司Quandri的后端工程师Chloe Kim发表了一篇引发广泛讨论的文章《MCP Is Dead》，在Hacker News上获得了47个赞和38条评论。
这不是MCP第一次被判"死刑"。早在2026年3月，开发者Charlie Schn就发表过《MCP is dead; long live MCP》，在HN上获得295分的高分。但Chloe Kim的文章之所以引起关注，是因为她带来了真实的生产环境数据，而不是理论推演。
MCP（Model Context Protocol）自2024年底由Anthropic推出以来，被誉为"AI生态系统的USB-C接口"。它让LLM能够连接GitHub、Linear、Notion、Slack等外部工具。几乎每个SaaS产品都在登陆页加上"支持MCP"的标签。
但真正每天在生产环境使用MCP的开发者，开始发出不同的声音。
三个致命问题：来自真实生产环境的数据
问题一：上下文窗口杀手
Chloe的团队连接了4台MCP服务器到Claude Code环境，然后测量了实际的工具定义大小：
| MCP服务器 | 工具数 | 预估Token |
|---|---|---|
| Linear | 42 | ~12,807 |
| Notion | 14 | ~4,039 |
| Slack | 12 | ~3,792 |
| Postgres | 9 | ~438 |
| 合计 | 77 | ~21,077 |
在Claude的200K上下文窗口中，仅MCP工具定义就占用了10.5%。如果用GPT-4o的128K窗口，这个比例上升到16.5%。
▲ MCP上下文消耗实测：4台服务器·77个工具·21,077 tokens
!MCP上下文消耗实测：4台服务器·77个工具·21,077 tokens
最糟糕的是Linear服务器——42个工具定义始终加载，但你日常可能只用到get_issue和save_issue两个。
好消息是：Chloe在文章中也更新了一个重要进展——Claude Code已经推出了"Tool Search with Deferred Loading"（工具搜索与延迟加载），将MCP工具按需加载，上下文占用降低了85%以上。但性能、调试和架构方面的问题依然存在。
问题二：可靠性堪忧
MCP不只是消耗token，它的运行稳定性也不太理想：
- 初始化失败和重复认证：需要单独启动和维护MCP服务器进程
- 响应变慢：每次工具调用都要经过外部服务器往返
- 会话中途崩溃：MCP服务器进程随时可能挂掉
- 权限不透明：不清楚每个工具到底有什么权限
原作者在对比测试中发现：用MCP查询Jira比直接调REST API慢3倍，首次调用（含初始化）更是慢了9.4倍。这不是Jira特有的问题，而是MCP架构性的开销——每台MCP服务器都在LLM和底层API之间增加了一个进程层。
问题三：与CLI/API高度重叠
Chloe做了一个震撼的对比——查询同一个Linear Issue：
- CLI方式：curl命令约50 token + 响应约150 token = ~200 token
- MCP方式：工具定义（始终加载）约12,807 token + 工具调用约150 token = ~12,957 token
!CLI vs MCP：同一查询65倍token消耗差异
▲ CLI vs MCP：同一查询65倍token消耗差异
65倍的token消耗差异。 而且CLI方式可以使用pipe、jq、grep自由组合，调试时直接在终端复现；MCP方式只能在对话上下文中排错。
MCP的价值：什么时候它还是对的
尽管文章标题是"MCP Is Dead"，但Chloe的结论其实非常务实——MCP并没有完全死掉，它在以下场景依然有价值：
1. 没有CLI的服务 纯Web端的SaaS产品，MCP可能是唯一的连接方式。
2. 非开发者用户 对于不使用终端的团队成员，MCP提供了更友好的工具访问方式。
3. 数据库安全场景
这是MCP最强的护城河。CLI方式下LLM可以执行DROP TABLE，而MCP服务器可以在服务端强制只读模式、拦截危险查询。对于生产数据库和共享团队库，MCP的安全防护是不可替代的。
4. 实时双向通信 超出简单请求-响应模式的场景，MCP的协议设计更有优势。
Quandri的真实方案：三种方式并行
最有价值的部分是Chloe分享的实际使用策略——不要强迫只用一种方式：
| 场景 | 方案 | 原因 |
|---|---|---|
| 日常CLI工具（gh, psql, aws） | Bash + CLI | 零上下文成本，终端直接调试 |
| 可重复的多步骤工作流 | Skills | 按需加载，嵌入CLI使用说明 |
| 无强CLI的服务（Slack, Linear, Notion） | MCP | 唯一连接方式，团队权限管理 |
| 生产数据库 | MCP | 安全防护，权限控制 |
关键洞察：教得好比连得多更重要。 如果你已经有一个好用的CLI工具，把它包装成Skill（在里面嵌入CLI命令和认证方式），比架设MCP服务器更加高效。
对AI创业者的启示
这场争论对我们的读者——AI创业者——意味着什么？
1. 不要被"MCP支持"的营销话术迷惑
现在每个SaaS都在宣称"支持MCP"，但这不等于它的MCP服务器真的好用。Chloe的文章提醒我们：真正接上线之后，可能会面对初始化失败、会话崩溃和天文数字般的token消耗。
2. CLI优先是最务实的策略
如果你在构建AI Agent工作流，从CLI开始是最安全的选择。LLM已经从man pages和StackOverflow学会了CLI的使用方式，不需要额外的工具定义。等业务验证成功后，再评估是否需要MCP来做安全加固。
3. Skills模式是你应该学习的
Skills介于CLI和MCP之间——把CLI使用说明嵌入一个Skill文件，LLM只在调用时才加载。这种方式兼具了CLI的低成本和MCP的结构化，是当前性价比最高的方案。Hermes Agent和OpenClaw都原生支持Skills模式。
4. 关注上下文预算
不管你选什么工具连接方式，记住一个核心指标：上下文预算。 Chloe的团队替换MCP为Skills后，释放了约21K token的上下文空间——这意味着AI能记住更长的对话历史，做出更准确的决策。在Agent开发中，节约上下文就是提升智力。
行动建议
- 本周就做：检查你的Agent工作流中哪些MCP服务器是你真正用到的，哪些工具定义是从未被调用过的。把低频使用的服务迁移到CLI+Skill方案。
- 评估标准：如果一个服务有成熟的CLI且你团队中有人能用终端，优先CLI方案。如果服务只有Web界面或团队中有非技术用户，MCP仍有价值。
- 关注进展：Anthropic的延迟加载功能正在改善MCP的上下文问题，关注Claude Code的更新日志，MCP可能在2026年下半年迎来真正的成熟。
本文由AI辅助创作，经人工审核编辑发布。参考来源：Quandri Engineering Blog《MCP Is Dead》（2026年5月29日），Hacker News讨论（47 points, 38 comments）。
本文由AI辅助创作，经人工审核编辑发布