Show HN: Mcp2cli – One CLI for every API, 96-99% fewer tokens than native MCP

Original Article ↗ Hacker News Discussion ↗

A new tool called mcp2cli aims to let AI agents and humans use any Model Context Protocol (MCP) API through generated CLI commands, claiming 96–99% token savings by lazily discovering tools instead of injecting full schemas into every model call. Commenters are intrigued by the token and composability benefits but question whether reduced context actually preserves tool-call accuracy, observability, and latency, and whether the project’s heavily AI-written documentation reflects real benchmarks. The thread widens into a debate over MCP itself—its value for standardized auth, validation, and org-wide tooling versus simply using CLIs, SSH, OpenAPI, or web access—with many noting a proliferation of nearly identical “MCP-to-CLI” projects as agents become better at operating command-line tools.

Project concept and motivation

  • mcp2cli exposes MCP servers as CLIs so models can use “known” CLI patterns instead of full MCP schemas.
  • Key ideas mentioned: dynamic CLI generation from MCP/OpenAPI, lazy on-demand tool discovery, and caching of specs (default TTL ~1 hour).
  • Some see this as improving composability and aligning with agents that already write Bash well.

Token usage and performance concerns

  • Proponents emphasize large token savings because native MCP clients inject full tool schemas into context every turn, while a CLI lets the model discover tools progressively.
  • One explanation: with MCP, the entire tool list and schemas are repeatedly in context; with a CLI, the model calls --list or --help only when needed.
  • Critics argue token counts alone are not a meaningful metric; they want evidence that accuracy, latency, and error rates are comparable.
  • Doubts raised that short summaries can fully replace verbose JSON schemas without some accuracy loss.

MCP vs CLI vs “just HTTP/web”

  • Some question why MCP is needed at all given existing tools: HTTP APIs, OpenAPI, curl, SSH, and traditional CLIs.
  • Supporters of MCP highlight:
    • Granular authorization and OAuth instead of raw API keys.
    • Restricting what operations an agent can perform, not just which domains it can reach.
    • Structured validation, schemas, prompts, and resources, especially valuable for org-wide standardization, telemetry, and shared skills.
  • Others see MCP as over-engineered or a “reinvented OpenAPI,” arguing that harness-level sandboxing or direct CLIs could solve the same problems.

Tool discovery and routing

  • Multiple comments treat “always inject all MCP tools” as a client bug, not an MCP requirement.
  • Suggested fixes: tool routing/search sub-agents, RAG over tool descriptions, and Anthropic-style ToolSearchTool patterns.
  • Some worry that RAG-based tool selection requires extra model calls per request and might affect accuracy.

Ecosystem saturation and differentiation

  • Many similar MCP-to-CLI projects are listed; several people note there are “dozens” or “about 100” such tools already.
  • For small, simple use cases, some recommend just generating a custom CLI with an agent instead of adopting someone else’s.
  • Questions remain about how this project differs in practice from existing tools like mcporter, mcpshim, or other MCP CLIs.