Article Complete
    AIM

    The Fall and Rise of MCP

    The Fall and Rise of MCP

    “No translation layer, no schema, no overhead. MCPs are genuinely a solution looking for a problem that CLIs solved 40 years ago.”

    The Fall and Rise of MCP
    Image by Nalini Nirad
    Mohit Pandey··Updated OCTOBER 18, 2026, 7:03 AM
    5 min

    A year ago, the Model Context Protocol was the cool new pipe everyone wanted to plug into. Introduced by Anthropic as a standard way for LLMs to interact with tools, it quickly gained pace. IDEs rushed to integrate it. Startups built servers around it. Developers shipped dozens of small tool wrappers that exposed APIs directly into chat.

    Then, somewhere between marathon Claude Code sessions and agents swarming computers, the mood has shifted. 

    “MCPs are dead—Command-Line Interface (CLI) won,” read a comment on a Hacker News thread that quickly turned into a referendum on how agents should actually operate.

    The argument pointed to comments from Peter Steinberger, creator of OpenClaw, who made a similar case on Lex Fridman’s podcast.

    “When half a year ago, everyone was talking about MCPs, I was like ‘Screw MCPs’. Every MCP would be better as a CLI,” he had said.

    The whole premise behind MCP was that agents needed a new standardised protocol to interact with tools. But CLIs already do this and they have been doing so for decades. 

    They are backwards compatible with almost everything. LLMs already operate natively in text-in, text-out mode. “No translation layer, no schema, no overhead. MCPs are genuinely a solution looking for a problem that CLIs solved 40 years ago,” another contributor wrote.

    To prove the point, Steinberger ran OpenClaw with Claude Opus 4.6 against a 20,000-member subreddit using nothing but terminal access. “No MCPs, no special integrations, just a model with a computer,” another participant noted. 

    Within one week, he claims, the system produced two all-time top posts, accumulated more than 3,000 karma on a week-old account, drove over 70 waitlist signups autonomously, attracted 300 inbox messages, and even received Reddit gold.

    “No protocol made that happen. A CLI and a capable model did,” a separate comment read.

    The OpenClaw Effect

    Some insist that MCP is dead. Others argue that the comparison misses the point entirely. The reality is more nuanced. Powerful agents can be built with either approach—or both.

    Chrys Bader, Co-Founder and CEO of Rosebud, declared that “MCP is dead in the water”, crediting OpenClaw with changing his thinking. In his view, API and CLI will ultimately prevail.

    One of the main criticisms centres on context bloat. Every MCP server one connects to injects its tool definitions straight into the model’s context window. Names, descriptions, the full parameter schema. Connect 10 servers with five tools each, and you have 50 tool definitions consuming tokens before the first substantial prompt is even asked.

    Bader argues that this kind of context bloat is never good. It hurts performance and increases cost. It may also explain why someone deliberately chose to leave MCP out of OpenClaw altogether.

    Instead, the combination of an ‘exec’ tool and on-demand skills appears sufficient.

    Back to the Terminal

    An agent can execute any command created since the early days of computing: curl, sed, awk, grep. The old command line utilities once mastered by specialists, later got buried under layers of abstraction.

    Now, however, they are resurfacing, driven by the most capable models available. Every founder effectively commands a digital crew of seasoned operators. The friction required to make MCP universal can feel heavier than the momentum OpenClaw has injected into APIs, CLIs, and skills.

    Bader explains that when agents were primarily chat interfaces, MCP provided an easy way to inject structured capabilities. As agents gained the ability to run long lived sessions, execute shell commands, inspect files, and iterate autonomously, the default interface shifted. The terminal became the interface. The model became the runtime.

    In that environment, the CLI feels natural. It is text-in, text-out. It carries decades of conventions. It composes. It pipes. It fails explicitly with exit codes. LLMs were trained on decades of such interactions.

    By contrast, MCP can feel like an extra layer. 

    Governance and permissions still matter. Multi-tenant SaaS deployments with strict networking constraints are easier to manage with a well-defined protocol than with raw shell access. Multi-agent coordination may also require more structure than a collection of bash commands.

    Even the strongest anti-MCP voices are not claiming that structured protocols are worthless. Their argument is that for many local, agentic, developer-centric workflows, the terminal is sufficient.

    This also makes MCPs more expensive. Prerit Khandelwal, Director, Product Analytics at Razorpay, agrees. He says MCPs consume a lot of tokens. Razorpay was one of the first companies to introduce MCPs in payments.

    Security, Scale and Standardisation

    Others were less impressed because OpenClaw is a security nightmare. Pro-MCP advocates are not disputing the CLI’s power. They argue that standardisation, authentication, and discoverability at scale cannot be reliably handled through ad hoc wrappers.

    “Dead” may be hyperbolic. The original Hacker News poster later admitted the phrasing was “provocative on purpose”. In practice, he found CLI-based agents offered him more control and reliability; not that MCP had no value.

    On LinkedIn, Lee Crossley, Director, San Digital, wrote, “MCP isn’t dead because it was bad—it’s dead because something simpler outpaced it. The model became the runtime. The protocol became overhead.”

    The Nx team took a similar stance. In a recent post titled ‘Why we deleted (most of) our MCP tools’, they explained that as Claude Code shifted developers from “ask and answer” towards “plan and execute,” the practice of dumping structured JSON into context began to feel inefficient. 

    If an agent can run Nx show project myapp in the terminal and read the output itself, why rely on an MCP tool to do the same?

    Token cost became a decisive factor. Early MCP implementations often loaded large JSON payloads whether or not the agent needed the full dataset. Although Anthropic later demonstrated ways to reduce token usage through programmatic processing of MCP results, Nx argues that in many cases this was still overengineered. Modern agents can just use the CLI and pipe results through jq to extract exactly what it needed.

    Instead of MCP tools, Nx stresses the importance of “skills.” Instructions that teach the agent how to use generators, navigate project graphs, fix CI failures. Their internal benchmarks reportedly showed higher accuracy with skills than with MCP alone, especially when using smaller models.

    Yet, the obituary for MCP remains contested. And in technology, contested obituaries rarely mean extinction. More often, they signal repositioning. MCP may not be dead. It just may no longer be the default layer.

    Your reaction

    Discussion

    What's your take on this story?

    0/1000

    No comments yet — be the first to share your view.

    Explore our newsletters

    Build your routine with some of our top newsletters or view them all here.

    Wake up informed

    Make sense of the day's AI news and breakthroughs with our morning briefing.

    Belamy
    WeeklyBelamySee the latest

    Industry intelligence

    Receive a roundup of AI adoption stories by industry vertical, curated for professionals.

    3x WeeklySector6See the latest

    By signing up, you agree to our Privacy Policy.

    Membership

    Stay ahead with AI insights.

    Unlimited access to premium articles, exclusive analysis, and the stories shaping India's AI economy.

    Subscribe now

    AIM Americas

    1190 Miraloma Way Suite P, Sunnyvale, CA 94085

    AIM India

    1st Floor, Sakti Statesman, Bellandur, Bengaluru – 560103

    © 2026 AIM. All rights reserved.