CLI vs MCP: wat AI-agents nu daadwerkelijk gebruiken

In late 2024, Anthropic shipped the Model Context Protocol. Teams quickly adopted it as a standard way to expose tools to AI agents. By March 2025, OpenAI had joined as well. Sam Altman posted on X:

Google, Microsoft, AWS, and Cloudflare followed. MCP later joined the Linux Foundation's Agentic AI Foundation. Shipping an MCP server became a common expectation for developer products.

As teams ran agents in production, critiques of MCP as a default integration path grew louder.

The backlash, in the builders' own words

One of the clearer early critiques came from Eric Holmes on February 28, 2026, in "MCP is dead. Long live the CLI.". His point was not that tool use is optional. It was that for most agent work, a good CLI already is the interface. Models have been trained on man pages, Stack Overflow answers, and shell scripts for years. Give them gh, aws, or kubectl, and they figure it out. MCP, he argued, adds flaky server processes, awkward auth, and a debugging experience that is worse than running the same command yourself.

Two weeks later the argument reached a wider audience.

On March 11, reporting circulated that Perplexity's CTO, Denis Yarats, was moving internal workflows off MCP toward APIs and CLIs, citing context cost and auth friction:

The next day, Garry Tan quoted that thread:

That post crossed a million views. Garry was our YC partner, and the core claim matched what we see in production: MCP abstractions can consume a large share of the context window before the agent starts doing useful work.

Pieter Levels made a similar point in the same discussion:

Holmes is writing from day-to-day agent infrastructure work. Yarats is shipping at Perplexity. Tan runs Y Combinator. Levels has built and operated products end to end. The shared complaint is concrete: protocol overhead often costs more tokens than it saves.

Why the CLI came back

The CLI case is about token cost and training data, not preference for older tooling.

Simon Willison has covered this clearly. Popular MCP servers can dump tens of thousands of tokens of tool schemas into context before the agent does any work. GitHub's MCP alone was known for exposing ~90 tools and using a large portion of a 200K window. Stack a few servers and the model spends capacity on tool menus instead of the task.

A CLI avoids much of that overhead. The model already knows gh issue list. It can run --help when it does not. Intermediate filtering happens in the shell with jq and grep, so large JSON responses do not need to live in the prompt. Independent benchmarks (including ScaleKit's CLI-vs-MCP runs covered in Kaxil's writeup) have shown large token savings and higher success rates for terminal workflows.

Coding agents reflect the same preference in their design. Claude Code, Codex, Cursor, and similar tools are built around a shell. Frontier models have seen large volumes of bash examples in pretraining, and almost no MCP schema dumps. When Anthropic later pushed code execution with MCP and tool search / deferred loading, the fix moved MCP closer to on-demand discovery, which is closer to how a CLI already works.

Even Willison, who had mostly stopped using MCP for coding agents, noted the improvement when Claude Code shipped tool search:

The useful takeaway: MCP became more practical once clients stopped loading every tool definition into every turn.

MCP is not dead. It stopped being the default.

The stronger critiques overstated the case. MCP still solves problems a local CLI cannot:

• Agents without a shell (desktop apps, mobile, hosted chatbots, multi-tenant backends)
• One-click distribution into Claude Desktop, Cursor, ChatGPT, and other MCP hosts
• Centralized auth, scoped tools, and audit logs for enterprise

Allen Hutchison (Google DeepMind) made the counterpoint clearly in "MCP isn't dead. You just aren't the target audience.". If your agent runs inside Obsidian on iOS, "just use the CLI" is not an option. Micheal Lanham's March 2026 roundup reaches a similar conclusion. Governance investment kept growing even while developer sentiment cooled.

Garry updated his own view a few weeks after the viral critique. On April 4 he posted:

In a follow-up in the same thread, he argued you should design the CLI first for what agents need to do, then convert that to MCP. That is the more accurate framing. Use a CLI when you have a terminal. Use curated MCP when you need a protocol. Do not auto-convert an entire REST surface into dozens of tools.

What we ship at VideoGen

We support both because our users operate in both environments.

Developers generating and editing video from agents need a path that coding agents already understand: a real CLI with --help, JSON-friendly output, and the same operations as the API. They also need a path for clients that speak MCP natively (Cursor, Claude Desktop, ChatGPT, and similar hosts) without requiring every user to install a binary.

So VideoGen ships both:

• CLI: install @videogen/cli and drive workflows, tools, projects, and exports from the terminal or CI.
• MCP: connect to the hosted server at https://mcp.videogen.io/mcp (or run @videogen/mcp locally) and get the same API surface as tools inside your agent client.

Same API underneath. Two transports. Choose the one that matches how your agent runs.

If you are building agent workflows around video, start with the CLI when you have a shell. Use MCP when your host expects it. Treat the protocol as an integration option, not a strategy by itself.

Install the VideoGen CLI · Connect the VideoGen MCP server · Get an API key