MCP（Model Context Protocol）自诞生以来就被视为 AI 编码助手交互的事实标准，但Quandri工程团队最近的一篇博文提出了一个反直觉的结论：MCP的开销可能远超预期，有些场景下干脆用CLI更划算。

实测数据说话

先看数字。4个MCP服务器注册的工具定义就要消耗约21000个token，占用一个20万token上下文窗口的10.5%。而在查询Linear issue的场景中，通过MCP调用需要消耗约13000 token，用CLI方式只需要约200 token——差距高达65倍。这不是边缘场景的极端值，而是日常开发中反复发生的操作。

[ CLI approach: ~200 tokens ]
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

-> Prompt (curl command): ~50 tokens
-> Response: ~150 tokens

[ MCP approach: ~12,957 tokens ]
-> Tool definitions (always loaded): ~12,807 tokens (42 tools)
-> Tool call + response: ~150 tokens

Measurement: Tool Definition Sizes (Quandri Stack)

除了token开销，响应延迟也是问题。实测MCP的调用速度比直接API调用慢约3倍。这在交互式编程场景下会直接影响开发体验。

所以问题出在哪？核心在于工具定义的暴露方式。当你连接多个MCP服务器时，所有工具的签名和描述都被塞进上下文——不管你当前是否需要。这意味着即使只用到其中一小部分工具，也要为全部工具付出token成本。

替代方案一：CLI优先策略

对于已经有成熟CLI工具的服务，直接调用CLI是更合理的选择。以GitHub CLI（gh）、PostgreSQL（psql）为例，它们没有额外的上下文开销、没有额外的延迟、人机使用方式一致、调试路径也清晰。把这些已有工具利用起来，远比为了"统一协议"而引入MCP更务实。

替代方案二：Skills模式

另一个思路是让工具指令在需要时才加载，而非提前全部注册。这就像去图书馆：你告诉管理员你要借什么书，管理员去取，而不是把整个图书馆的书架都摊在你面前。这种按需加载的模式能极大减少上下文占用，同时保持工具集的可发现性。

MCP仍然适用的场景

这不意味着MCP没有价值。对于没有CLI访问方式的服务、非技术用户的使用场景、需要对生产数据库进行查询安全限制的场合，MCP的抽象层仍然有意义。它的价值在于降低了连接"没有CLI接口的服务"的门槛，而不在于把一切连接都通过MCP来做。

Quandri自己的实践是：日常工具用Bash+CLI、需要可复用工作流时用Skills、需要连接没有强CLI的服务时才上MCP。三种方式各司其职，而非一种协议包打天下。

这个结论背后的工程哲学值得玩味：连接一切不等于教好一切。工具的价值不在于数量，而在于用得恰到好处。与其花时间配置MCP服务器，不如把时间花在让工具本身更好用上。

参考来源：https://www.quandri.io/engineering-blog/mcp-is-dead