Quandri 那篇《MCP is dead》标题很凶，但真正有用的不是死亡宣告，而是一笔工程账。
他们在自己的 Claude Code 环境里接了 4 个 MCP server：Linear、Notion、Slack、Postgres。光工具定义就有 77 个，约 84,308 个字符，估算 21,077 tokens。放进 Claude 200K 上下文，占约 10.5%；放进 GPT-4o 128K 上下文，占约 16.5%。
更刺眼的是 Linear。单独 42 个工具定义，约 12,807 tokens。查同一个 issue，MCP 路径约 12,957 tokens，CLI 路径约 200 tokens，差约 65 倍。
这不是全行业基准。它只是 Quandri 这套 Claude Code 工作流里的测量。但它足够提醒工程团队：支持 MCP 四个字，听起来像能力，落到真实工作流里，可能是上下文、进程、认证和调试成本。
Quandri 测出的核心问题：连接不是免费的
MCP，Model Context Protocol，常被叫作 AI 生态里的 USB-C。它让模型连接 Linear、Notion、Slack、数据库这类外部工具。
这个比喻好懂，也容易误导。USB-C 插上就能用，MCP 接上以后，还要承担工具定义、server 进程、权限边界、失败重试和调试路径。
| 项目 | Quandri 案例里的数字 | 直接影响 |
|---|---|---|
| MCP server | 4 个 | 多进程、多认证、多初始化状态 |
| 工具定义 | 77 个，约 21,077 tokens | 一度吃掉 Claude 200K 上下文约 10.5% |
| Linear | 42 个工具，约 12,807 tokens | 只用少数功能，也要背大量定义 |
| 同一 issue 查询 | MCP 约 12,957 tokens；CLI 约 200 tokens | token 成本约 65 倍差距 |
这里必须补一刀刹车。Claude Code 后来推出了 Tool Search with Deferred Loading，官方称可减少 85% 以上上下文占用。
所以，把上下文膨胀写成 MCP 当前不可修复的硬伤，不准确。这个问题已经被明显缓解。
但缓解不等于消失。MCP 仍然多了一层协议和一组 server。初始化失败、重复认证、server 中途挂掉、调用链变慢、权限解释不清，这些不会因为延迟加载就自动消失。
对 AI 工具链开发者来说，这意味着一件具体的事：不要只问某个 SaaS 有没有 MCP。要问它的工具定义怎么加载、调用失败怎么查、权限怎么收口、日志能不能复现。
对工程负责人来说，采购和接入可以慢半拍。先做 POC，拿自己的任务测 token、延迟、失败率和调试时间。别拿供应商页面上的支持 MCP 当架构决策。
CLI、Skills、MCP，不是同一个答案
Quandri 的结论并不极端。他们没有说 MCP 全删，而是重新分工：日常工具走 Bash/CLI，可重复流程走 Skills，MCP 留给没有强 CLI 或需要团队权限治理的服务。
这比标题里的 dead 更接近工程现实。
| 路线 | 更适合什么 | 优势 | 现实约束 |
|---|---|---|---|
| CLI / API | 本地开发、查 issue、拉 PR、跑脚本 | 低 token、可复现、好 debug | 凭证和权限容易散，靠团队纪律 |
| Skills | 可重复流程、固定操作说明、常用 API 模板 | 按需加载，流程可沉淀 | 仍依赖模型遵守说明，不是硬边界 |
| MCP | 无 CLI 的 SaaS、非终端用户、统一认证、生产环境护栏 | 可集中管权限、加只读和拦截 | 多 server、多状态、多故障面 |
CLI 的好处很土，也很硬。人和模型用同一套东西。
gh、psql、aws、curl，终端里能跑，日志能看，出错能复现。还能接 jq、grep、pipe。模型也早就从文档、代码样例和公开问答里学过这些接口。
Skills 更像一本按需取用的小手册。比如查 Linear issue，不必常驻 42 个工具定义。需要时再加载 API 地址、认证方式、curl 示例和 JSON 解析方法。
MCP 的价值在更重的地方。统一认证、权限控制、团队级治理、生产数据库只读、危险查询拦截。这些不是体验优化，是安全边界。
尤其是生产数据库。CLI + Skills 再轻，也挡不住模型误跑危险命令。MCP server 如果能在服务端硬拦，它就不是多余中间层，而是护栏。
所以问题不在 MCP 本身。问题在默认崇拜。
很多任务本来是一条命令、一次 API 请求、一个可复现脚本。硬塞进 MCP，开发者看到的是接入更多，实际得到的是工作台更乱。
接下来该看什么：不是标签，是治理能力
我不太买账的，是把 MCP 包装成所有 AI 工具连接的默认答案。
“天下熙熙，皆为利来。”这句老话放到今天的 AI 工具链里并不突兀。很多产品上 MCP，未必是因为用户已经有明确需求，也可能只是官网需要一个新标签。几年前是 blockchain，后来是 AI-powered，现在轮到 MCP。
但也不能反着来，把 MCP 打成营销废料。它在权限和治理上有现实价值。无 CLI 的 SaaS、非终端用户、团队共享权限、生产环境操作，这些场景确实需要一个可控边界。
真正的分水岭不是支不支持 MCP，而是你是否需要一层可治理的工具边界。
如果是个人开发者或小团队，主要任务是查 issue、改代码、跑脚本、看日志，CLI + Skills 往往更便宜、更稳、更好查错。动作也很简单：先把常用 CLI 和脚本整理好，再把重复流程写成 Skills。
如果是平台团队、企业工程团队、生产数据库负责人，MCP 可以继续评估。但评估标准要换掉。别看接了多少服务，要看权限模型、审计日志、只读策略、危险操作拦截、server 崩了怎么降级。
接下来最该观察两个变量。
一个是延迟加载能否在不同 Agent 和 IDE 里稳定落地。Claude Code 已经做了 Tool Search with Deferred Loading，但 Quandri 的数字只来自它自己的 Claude Code 工作流。在 Cursor、自研 Agent、服务器侧代理里，成本结构可能不同，不能偷懒外推。
另一个是 MCP server 能不能把安全治理做实。只会暴露一堆工具定义的 MCP，价值有限。能把认证、授权、审计、限权和拦截做成硬规则，才有资格成为团队默认层。
Quandri 这篇文章最值得带走的，不是 MCP 死没死，而是它逼大家重新算账。
连接能力不是越多越好。默认加载也不是架构美德。AI 工具链的下一轮分水岭，可能不是谁接得最多，而是谁知道什么时候不该接。