Hacker News 中文摘要

RSS订阅

显示HN：Mcp2cli——一个为所有API设计的命令行工具，比原生MCP节省96-99%的令牌 -- Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP

原文链接 | HN讨论 | 2026-03-09 21:29:35

文章摘要

mcp2cli是一个工具，可将任何MCP服务器或OpenAPI规范在运行时转换为命令行界面(CLI)，无需代码生成。它能显著减少工具模式消耗的token，并附带AI代理技能，使AI编码代理能发现和调用API接口，还能从API生成新技能。安装简单，支持pip或直接运行。

文章总结

项目名称：mcp2cli —— 将任何MCP服务器或OpenAPI规范转换为CLI工具

核心功能
mcp2cli 是一个运行时工具，无需代码生成即可将MCP服务器或OpenAPI规范动态转换为命令行界面（CLI）。它能显著减少每次调用时因工具模式浪费的令牌数（节省96%-99%）。

安装方式
```bash pip install mcp2cli

或直接运行

uvx mcp2cli --help ```

AI代理技能
mcp2cli 附带可安装的技能，可教导AI编码代理（如Claude Code、Cursor、Codex）如何使用它。安装后，代理能发现并调用任何MCP服务器或OpenAPI端点，甚至能从API生成新技能。

使用场景
- MCP HTTP/SSE模式：连接MCP服务器并调用工具，支持认证头。
- MCP stdio模式：通过标准输入输出与MCP服务器交互，支持环境变量传递。
- OpenAPI模式：从本地或远程规范生成CLI，支持JSON/YAML格式，可指定基础URL和认证。
- 输出控制：支持JSON美化、原始响应体、TOON编码（针对LLM的高效令牌编码）。
- 缓存机制：规范和工具列表默认缓存1小时，支持自定义缓存目录和TTL。

解决的问题
传统方法中，每个MCP服务器或OpenAPI端点的完整模式会注入系统提示，导致大量令牌浪费。例如，50个端点的API在对话开始前就消耗3,579令牌，且每次消息都会重复这一开销。

mcp2cli的优势
1. 无需代码生成：直接指向规范URL或MCP服务器即可生成CLI，新端点即时生效。
2. 跨平台兼容：适用于任何LLM（Claude、GPT、Gemini等），不依赖特定API。
3. 高效发现：--list和--help返回简洁信息，比原生JSON模式节省令牌。
4. 支持OpenAPI：统一处理MCP和OpenAPI规范，提供一致的CLI接口。
5. 可配置缓存：支持本地缓存和强制刷新，减少网络请求。

性能对比
- MCP服务器：在120个工具的场景中，25轮对话节省357,169令牌（99%）。
- OpenAPI规范：200个端点的企业API节省99%令牌。
- 多服务器场景：连接3个MCP服务器（60个工具）时，20轮对话节省97.7%令牌。

工作原理
1. 加载：获取规范或连接MCP服务器，解析引用并缓存。
2. 提取：生成统一的命令定义和参数类型。
3. 构建：创建带有子命令、标志和帮助文本的解析器。
4. 执行：发起HTTP请求（OpenAPI）或工具调用（MCP）。

开发与测试
```bash

安装测试依赖

uv sync --extra test

运行测试

uv run pytest tests/ -v ```

致谢
灵感来自Kagan Yilmaz对CLI与MCP令牌成本的分析及其CLIHub项目，以及Anthropic的“高级工具使用”指南。

许可证
MIT

（注：原文中的技术细节、命令示例和性能数据已精简保留核心信息，冗余的URL和重复内容已删除。）

评论总结

以下是评论内容的总结：

支持观点

  1. 实用性与创新性

    • 认为MCP在CLI中的实现具有实用价值，特别是对AI代理的兼容性
    • 引用："cool!" (nwyin)；"Nice work!" (philipp-gayret)

  2. 性能优化

    • 赞同通过减少token使用提升效率，但需验证工具调用性能是否保持
    • 引用："Tokens saved should not be your north star metric..." (stephantul)；"the token math is compelling..." (vicchenai)

质疑与批评

  1. 必要性存疑

    • 认为MCP可能冗余，现有方案（如Web访问或CLI直接调用API）已足够
    • 引用："Why is the concept of 'MCP' needed at all?" (DieErde)；"MCP itself is a flawed standard..." (rvz)

  2. 内容真实性

    • 批评项目文档可能由AI生成，缺乏可信度
    • 引用："the prose... seem to be fully generated..." (stephantul)；"obviously generated slop..." (liminal-dev)

  3. 重复开发

    • 指出类似工具已大量存在，质疑重复造轮子
    • 引用："How is this the 5th one of these I have seen..." (jofzar)；列举了12个同类项目 (jancurn)

技术讨论

  1. 改进建议

    • 提出动态工具发现、延迟加载等优化方案
    • 引用："mcp just need to add dynamic tools discovery..." (tuananh)；"on each turn, a subagent searches..." (acchow)

  2. 适用场景差异

    • 认为CLI更适合技术用户，而MCP对非技术用户更友好
    • 引用："MCP is working great... for non technical employees" (rakamotog)

其他观点

  1. 标准化问题

    • 批评MCP标准设计存在缺陷
    • 引用："We had curl, HTTP... but we created MCP" (Doublon)

  2. 开发动机

    • 开发者分享类似项目经历，寻求社区反馈
    • 引用："I started a similar project... nobody seemed interested" (kristopolous)

总结显示评论呈现两极分化：支持者肯定技术价值，质疑者则从必要性、真实性和生态冗余角度提出批评，同时伴随具体技术改进建议。