文章指出MCP服务器会占用大量上下文窗口的token资源，导致AI代理实际可用的对话和推理空间大幅减少。例如三个MCP服务器可能消耗14.3万token，占200K上限的72%，严重影响AI代理的实际功能表现。

标题：MCP服务器吞噬上下文窗口？CLI是更优解

核心问题： - MCP服务器工具定义会占用大量上下文窗口资源，例如三个MCP服务器可能消耗20万token限额中的14.3万（72%） - 典型场景：连接GitHub/Slack/Sentry等工具后，未处理用户消息前就已消耗5.5万token - 每个MCP工具需要550-1400token描述其功能，50个API端点可能占用5万+token

现有解决方案对比：

1. MCP优化方案（压缩/按需加载）

• 优点：适合高频使用的小型固定操作
• 缺点：需额外构建中间件，仍存在单工具token成本

2. 代码执行方案（如Duet）

• 优点：适合复杂工作流和状态保持
• 缺点：存在安全隐患，需沙箱机制

3. CLI方案（Apideck采用）

• 渐进式披露：基础提示仅需80token，按需通过--help获取细节（每次50-200token）
• 可靠性：本地执行避免28%的远程调用失败率
• 安全性：内置权限分级（GET自动批准/DELETE默认阻止）
• 兼容性：通用shell支持，无需额外协议

CLI优势数据： - 执行会计查询总消耗约400token，相同功能MCP需预加载1万+token - 月度成本：CLI方案$3.2 vs MCP方案$55.2（17倍差距）

适用场景建议： - MCP：高频固定工具/多租户场景 - 代码执行：复杂状态工作流 - CLI：通用API集成/自主代理

对API提供商的建议： 1. 避免完整OpenAPI规范直接转换 2. 采用渐进式披露设计 3. 内置结构化安全机制 4. 默认提供机器友好输出

注：保留核心数据对比和方案特性，删除重复案例和过细的技术实现描述，突出不同方案的适用场景和关键差异。

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持CLI的观点

1. 节省token开销：CLI相比MCP能大幅减少token消耗（4-32倍），通过渐进式发现（--help）和二进制权限控制优化。

   • 引用：
     "tool definitions alone burned 50,000+ tokens... CLI: ~80 tokens in the system prompt" (gertjandewilde)
     "CLIs return results efficiently... CLI wins" (m3kw9)

2. UNIX哲学与兼容性：CLI符合UNIX的管道和进程设计理念，更易组合。

   • 引用：
     "UNIX solved this with files and pipes... AI agents are solving this with sub-agents" (nzoschke)
     "love asking Claude Code to wrap an API in a CLI... fantastic ergonomics" (TheTaytay)

支持MCP的观点

1. 安全与标准化：MCP提供集中式策略管理（如禁止财务操作后搜索），且避免CLI的密钥泄露风险。

   • 引用：
     "MCP gives a registry to enforce chain policies... no implicit way with skills" (caust1c)
     "MCP embeds secrets securely... hard for agents to dump" (TheTaytay)

2. 上下文窗口扩展：随着模型支持更大上下文（如1M token），MCP的token问题将缓解。

   • 引用：
     "context windows getting larger... non-issue soon" (enraged_camel)
     "from 200K to 1M tokens this year... non issue in 6 months" (machinecontrol)

中立/折中观点

1. 工具选择应基于场景：MCP适合非技术用户和安全需求，CLI适合低延迟和组合性。

   • 引用：
     "Use whatever gets the job done... no desire to teach parents CLIs" (dend)
     "CLIs trade latency for cost... MCP trades money for latency" (kristjansson)

2. 技术改进空间：MCP可通过懒加载工具定义（如分阶段连接）或智能搜索优化。

   • 引用：
     "lazy loading... tools registered but 80% 'not connected'" (bazhand)
     "modern MCP clients do smart tool search" (dend)

其他关键争议

• 可行性争议：部分认为MCP当前不成熟（"way too early", rirze），另一些反驳其信息过时（"bad outdated information", nicoritschel）。
• 开源工具：已有MCP转CLI工具（如mcp2cli, bkummel）和执行框架（如executor, drewbitt）。

总结：争论核心是权衡效率、安全与用户体验，未来可能随技术（如更大上下文）趋同。