核心看点:一家工程团队用实测数据挑战 MCP(Model Context Protocol)的实用性,证明其上下文窗口吞噬、可靠性低、与现有 CLI/API 重叠严重。 作者测量了实际接入的 4 个 MCP Server(Linear/Notion/Slack/Postgres),工具定义合计占用约 21,077 tokens——在 Claude 200K 上下文中占 10.5%,在 GPT-4o 128K 中占 16.5%。 仅 Linear 一个 Server 的 42 个工具定义就吃掉 12,807 tokens,而用户可能只用其中两条。性能上,MCP 比直接调用 REST API 慢 3 倍(含初始化慢 9.4 倍),且存在初始化失败、进程崩溃、权限不透明等运维问题。 作者用具体 token 对比展示:查一条 Linear Issue,CLI 方式仅需 ~200 tokens,MCP 需要 ~12,957 tokens(65 倍)。替代方案是 CLI-First + Skills 模式——把 CLI 命令嵌入按需加载的 Skill 中,既复用开发者已有的工具知识,又零上下文开销。 文章也承认 MCP 的合理场景:无 CLI 的 Web-only SaaS、非开发者用户、实时双向通信,以及生产数据库的安全防护需求(MCP 可强制只读和防 DROP TABLE)。 Quandri 团队的实际做法是三种方案并存——日常工具走 CLI+ Bash,重复工作流走 Skills,无 CLI 或需要统一权限的服务走 MCP。结论是「教得好比连接一切更重要」,释放了 ~21K tokens 的上下文空间。 文章有明确立场、一手测量数据、可复现的方法论,是典型的「人味 + 工程实践」写作,推荐给关注 AI 工具链效率的开发者阅读和讨论。