CLI 대 MCP: AI 에이전트가 현재 실제로 사용하는 것

In late 2024, Anthropic shipped the Model Context Protocol and the industry treated it like USB-C for AI agents. Every product team scrambled to announce an MCP server. By March 2025, even OpenAI was on board. Sam Altman posted on X:

Google, Microsoft, AWS, and Cloudflare followed. MCP landed in the Linux Foundation's Agentic AI Foundation. For a while, if you did not have an MCP server, you looked behind.

Then the mood flipped.

The backlash, in the builders' own words

The cleanest early obituary came from Eric Holmes on February 28, 2026, in "MCP is dead. Long live the CLI.". His thesis 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 just running the same command yourself.

Two weeks later the argument went mainstream.

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. It also hits close to home for us. Garry was VideoGen's YC partner. When the person who sat in our batch meetings says the abstraction is eating the context window, we pay attention. Not because hot takes on X are strategy, but because the complaint matches what we see in production agent loops.

Pieter Levels was even less polite, replying in the same wave:

None of these people are fringe. Holmes is an infrastructure engineer writing from day-to-day agent use. Yarats is shipping at Perplexity. Tan runs Y Combinator. Levels is the indie-hacker default voice. When that set agrees that the shiny protocol is often the wrong default, something real has shifted.

Why the CLI came back

The CLI argument is not nostalgia. It is token economics and training data.

Simon Willison has been blunt about this for a while. 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 famous for exposing ~90 tools and chewing a huge slice of a 200K window. Stack a few servers and the model is reasoning inside a menu, not solving your task.

A CLI sidesteps that. 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 giant JSON blobs never have to live in the prompt. Independent benchmarks (including ScaleKit's CLI-vs-MCP runs covered in Kaxil's writeup) have shown order-of-magnitude token savings and higher success rates for terminal workflows.

Coding agents themselves voted with their architecture. Claude Code, Codex, Cursor, and similar tools are built around a shell. That is not an accident. Frontier models have seen billions of bash examples. They have seen almost zero MCP schema dumps in pretraining. When Anthropic later pushed code execution with MCP and tool search / deferred loading, the direction of the fix was revealing. It made MCP behave more like "discover on demand," which is closer to how a CLI already works.

Even Willison, who had mostly abandoned MCP for coding agents, celebrated tool search when Claude Code shipped it:

That is the tell. The protocol only got interesting again once clients stopped stuffing every tool definition into every turn.

MCP is not dead. It stopped being the default.

Those posts went too far. 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 cleanly 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 lands in the same place. Governance investment kept compounding even while developer sentiment swung.

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

And in a follow-up that same thread, he argued you should design the CLI first for what agents actually want to do, then convert that to MCP. That is the mature version of the story. The hype said "MCP for everything." The correction says use a CLI when you have a terminal, curated MCP when you need a protocol, and never auto-convert your entire REST surface into 80 tools.

What we ship at VideoGen

We took that correction seriously because we live in both worlds.

Developers generating and editing video from agents need a path that coding agents already understand. That means 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 friends) without asking every user to install a binary.

So VideoGen supports both, on purpose:

• 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. Pick the one that matches how your agent actually 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. Do not treat the protocol as a strategy by itself.

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