Apideck CLI – An AI-agent interface with much lower context consumption than MCP

Original Article ↗ Hacker News Discussion ↗

LLM tooling frameworks are being reevaluated as teams discover that Model Context Protocol (MCP) servers can consume tens of thousands of tokens just to load tool schemas, straining context windows and costs. Several developers report success replacing MCP with agent-accessible CLIs that rely on `--help`-style progressive discovery, which dramatically cuts token usage but can increase latency and complicate secure secret handling. Others argue MCP still excels for hosted, policy-controlled, multi-user environments—especially when paired with tool search and caching—framing the choice as a trade-off between efficiency, governance, and distribution rather than a clear winner.

CLI vs MCP for agents

  • Several commenters hit the same pain point: rich MCP servers can consume tens of thousands of tokens in tool definitions before any user input.
  • A proposed alternative is giving agents a CLI with a tiny bootstrap prompt plus --help-style progressive discovery; this can cut context cost drastically.
  • Critics argue this trades off latency and reliability: progressive CLI exploration means more back-and-forth steps, especially in new threads.
  • Some see MCP and CLI as complementary: CLIs are great for local, composable, Unix-style workflows; MCP is better when you need schemas, remote hosting, and more structured integrations.

Context windows, caching, and tool search

  • One side claims growing context windows (hundreds of thousands to 1M tokens) will make MCP context overhead a non-issue.
  • Others counter that cost scales with tokens regardless of window size, and bigger windows just encourage more tools and bloat.
  • Tool search and lazy loading in modern MCP clients are cited as major mitigations, but critics note:
    • You still pay for whatever subset gets loaded.
    • These features depend on specific clients; simple scripts/agents may fall back to loading everything.
  • Context caching is raised as another mitigation, but commenters say it doesn’t solve reasoning degradation in huge contexts or over-eager integration sprawl.

Security and policy

  • MCP is described as providing “rails” and a registry that enables cross-tool policies (e.g., disallowing certain tool combinations).
  • Others argue this is not unique to MCP; any capability isolation mechanism or service mesh can enforce similar constraints.
  • Some enterprises reportedly ban arbitrary MCPs as unsafe, preferring tightly controlled or custom servers.
  • Several point out that CLIs can be riskier on user machines if they get broad access to the filesystem and network.
  • A nuanced point: MCP servers can embed secrets and keep them out of the agent’s process; achieving the same with CLIs often requires more complex setups or starts to resemble MCP.

Discoverability, ergonomics, and composability

  • Progressive discovery via CLI --help is praised for low token usage and universal availability.
  • Others note MCP can also implement hierarchical help-style endpoints; the core problem is oversized tool surfaces, not the protocol itself.
  • Some emphasize Unix-style composability: give agents a shell, small CLIs (possibly wrapping MCP APIs), and let them script; this keeps tools modular and testable.

Use cases and maturity

  • Commenters stress context: MCP seems more compelling in large organizations needing governance; CLIs and “skills” are often enough for solo devs.
  • There is disagreement about MCP’s readiness: some say we’re “too early” due to context and complexity; maintainers reply that client-side improvements already address many complaints.
  • Overall sentiment: avoid one-size-fits-all claims; pick MCP, CLIs, or hybrids based on context, cost, security, and operational needs.