MCP 已死？
- #MCP
- #AI工程
- #开发者效率
- #Hacker News
- #quandri.io
TL;DR
MCP 消耗上下文、可靠性低，且与现有 CLI/API 功能重叠。
问题一：吞噬上下文窗口
上下文窗口是 LLM 的桌面。连接 MCP 服务器时，仅工具定义就占据了很大一部分。以我们的环境为例，连接 4 个 MCP 服务器后，工具定义消耗了 10.5% 的上下文（Claude 200K 模型）。其中 Linear 的 42 个工具定义就占用了约 12,800 tokens，即使你只使用 get_issue 和 save_issue 也是如此。
问题二：运行可靠性低
- 初始化失败、反复重新认证
- AI 响应变慢：每次工具调用都需外部服务器往返
- 会话中工具崩溃：MCP 服务器进程可能挂掉
- 权限不透明：不清楚每个工具有什么权限
性能方面，原作者对 Jira MCP 与直接 REST API 的基准测试显示，MCP 每次调用慢 3 倍，首次调用（含初始化）慢 9.4 倍。这是架构性问题：每个 MCP 服务器都在 LLM 和底层 API 之间增加了一个进程层。
问题三：与现有 CLI/API 重叠
| 方面 | CLI / API | MCP |
|---|---|---|
| 人机一致性 | 人类和 LLM 使用相同命令 | 仅存在于 LLM 对话中 |
| 可组合性 | 自由组合管道、jq、grep | 受限于服务器返回格式 |
| 调试 | 终端中可立即复现 | 只能在对话上下文中复现 |
| 训练数据 | 已从 man 页面、StackOverflow 学习 | 需要单独的工具定义 |
| 安装成本 | 大多已安装 | 需要服务器设置、认证、进程管理 |
Token 对比：查询 Linear Issue
- CLI 方式：~200 tokens（curl 命令约 50 tokens，响应约 150）
- MCP 方式：~12,957 tokens（始终加载的工具定义约 12,807 tokens，工具调用+响应约 150） MCP 消耗约 65 倍的 tokens。
替代方案
方案一：CLI 优先
按 CLI → API → 文档的顺序提供。LLM 已从 man 页面和 StackOverflow 学习过。直接使用现有 CLI：
- 不浪费上下文在工具定义上
- 人类和 AI 使用相同接口，易于调试
- 可自由通过管道组合
方案二：Skills 模式
如果说 MCP 是“一开始就把所有菜单摊在桌上”，那么 Skills 就是“只向图书管理员要你需要的书”。
| 方面 | MCP | Skills |
|---|---|---|
| 加载时机 | 连接时加载所有工具定义 | 仅在需要时加载 |
| 上下文消耗 | 始终占用 | 仅在使用时占用 |
| 可扩展性 | 上下文压力随服务器数量增长 | 与技能数量不成比例 |
关键是将 CLI 使用说明嵌入 Skills 中。例如 Linear skill：
# Linear Issue Lookup Skill
- Linear API: https://api.linear.app/graphql
- Auth: Bearer Token ($LINEAR_TOKEN env var)
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql
- Search issues (GraphQL): adjust the query field for JQL-like filtering
- Results are JSON, parse with jq
这样，仅当调用 skill 时 LLM 才加载上述内容，无需一直携带 42 个工具定义。
MCP 真的死了吗？
并非完全如此。MCP 在以下场景仍有用：
- 服务没有 CLI：纯网页 SaaS，MCP 可能是唯一连接方式
- 非开发者用户：MCP 对不熟悉终端的人更友好
- 实时双向通信：超出简单请求-响应的场景
数据库怎么办？
简短回答：看情况。LLM 已熟悉 SQL 和 MongoDB 查询。将数据库信息和 CLI 用法放在 skill 中即可，无需 MCP。但 MCP 在数据库方面有优势：
- 查询安全：MCP 服务器可强制只读模式，阻止危险查询。Skills + CLI 无法阻止 LLM 执行 DROP TABLE。
- 凭据保护：CLI 方式可能暴露连接字符串，MCP 服务器内部管理凭据。
| 场景 | 推荐 | 原因 |
|---|---|---|
| 本地开发/个人数据库 | Skills + CLI | 轻量快速，容易从错误中恢复 |
| 生产数据库/共享团队 | MCP | 需要安全护栏，服务器级的查询验证和访问控制 |
但大多数开发者工作流中，MCP 是过度工程化。
在 Quandri 我们如何使用 Skills
我们同时使用三种方法，根据服务选择：
- Bash + CLI：用于日常工具（gh, psql, aws）。零上下文成本，完全灵活，直接在终端调试。
- Skills：用于可重复的多步骤工作流，如提交草稿和 PR 审查。仅在调用时加载。
- MCP：用于没有强 CLI 的服务（Slack, Linear, Notion），以及需要团队统一认证或权限范围的情况（如生产数据库访问）。
结论
教得好比连接一切更重要。对我们而言，用封装了现有 CLI 的 Skills 替换 MCP 服务器，释放了约 21K tokens 的上下文，消除了日常工作中的初始化失败，并将调试保留在终端中。只加载你需要的工具，只在需要时加载，并内嵌 CLI 指令。MCP 可能会进化来解决这些问题，但目前 Skills 获胜。
测量方法：工具定义大小通过从 Claude Code 环境中实际加载的 MCP 服务器提取每个工具的 JSON schema（名称+描述+参数）测量。Token 估算使用约 4 字符/token 的启发式方法。完整服务器估算基于采样工具平均值外推。
评论