Neat Everything
More
ZHEN
Change the mood
← Opinions

August 22, 2026

Will Code Mode Kill MCP and CLI? I Think the Opposite Is True.

The overseas community has been buzzing about Code Mode for agents: instead of a model picking its way through a pile of tools one by one, it writes JavaScript that calls tools, CLIs, and MCPs. A natural question follows — do users ever need to plug in another MCP, install another CLI, or configure another tool again?

My answer: your instinct is pointing in the right direction, but there’s one crucial correction.

Code Mode doesn’t make MCP, CLI, and Tools disappear. It demotes them from “the Agent’s direct tool interface” to “low-level capabilities the Agent can call through code.”

This isn’t a cosmetic change in interaction style. It’s a fundamental shift in agent architecture.

First, Let’s See What Code Mode Is Actually Doing

The traditional agent looks like this: the LLM stares at dozens or hundreds of tools and calls them one at a time via tool_call.

Traditional Agent:
LLM
 |
 | tool_call()
 |
 MCP Tool A
 MCP Tool B
 MCP Tool C

Code Mode is different: the LLM only faces one thing — a code execution environment. It writes JavaScript and composes capabilities through SDK / API / CLI / MCP.

Code Mode:
LLM
 |
 | write JS
 |
 Sandbox Runtime
 |
 +-- fetch API
 +-- call CLI
 +-- import SDK
 +-- call MCP
 +-- filesystem
 +-- database

Cloudflare’s Code Mode MCP design heads exactly this way: expose a code execution entry point, let the model generate JavaScript, and compose operations inside an isolated sandbox — instead of flattening a huge catalog of tool schemas in front of the model.

The motivation is practical. The more tools you add, the more schemas and parameter docs you’re shoving into context, and the model burns out before it even starts working. Rather than feeding the model an infinite list of tool definitions, you hand it one knife that can slice everything.

Four Judgments: Who Gets Phased Out, Who Actually Rebounds

1. For individuals, the MCP-install era is probably ending

What does configuring Claude Code or OpenClaw look like today?

MCP:
- github
- browser
- notion
- slack
- gmail
- filesystem
- postgres
- calendar
CLI:
- git
- gh
- docker
- kubectl
- aws
Tools:
- custom scripts
- APIs

This feels a lot like early Linux: you had to install drivers, fix the environment, and hand-write shell. The pain is real.

The near future might look like this: you tell the agent “analyze this GitHub project, find the bug, open a PR, and ping Slack,” and it generates the JS itself:

import github from "xxx"
import slack from "xxx"
await github.search()
await github.createPR()
await slack.send()

You never care about the MCP server’s name, how config.json is written, what the tool schema looks like, or what CLI flags exist. That all becomes internals of the agent runtime.

2. But MCP won’t disappear — it’ll become the kernel layer

Here I side with the Harness team’s framing: the agent loop is like a new operating system, and MCP sits at the kernel boundary.

The metaphor is precise. The future structure probably looks like:

 User
 |
 Intent
 |
 AI Agent
 |
 Code Generation
 |
 Sandbox Runtime
 |
 -------------------------
 | | |
 MCP CLI API
 | | |
 GitHub Docker AWS

MCP stops being something humans install and becomes “standardized device drivers” for the agent runtime. An ordinary user doesn’t need to understand Linux kernel drivers — but Linux can’t run without them. MCP migrates from the “user plugin system” to the “agent kernel interface.”

3. CLI may actually make a comeback

Plenty of people assumed MCP would replace CLI. But once Code Mode shows up, I suspect the opposite — CLI becomes the Agent’s favorite primitive again. Three reasons.

First, compression efficiency. git status is a few tokens. The equivalent call github_get_repository_status({ repository: "xxx" }) burns a chunk of schema.

Second, models have been trained on oceans of command-line usage. git, docker, kubectl, aws, terraform are second nature to an LLM.

Third, CLI composes naturally. kubectl get pods | grep error | jq does one trip to get it done; MCP tends to be tool call → LLM → tool call → LLM, eating context round-trip after round-trip.

Harness has discussed this too: CLI wins when the agent already knows the commands and wants to compose operations, while MCP is better for capability discovery, permission control, and structured security boundaries.

4. Then why do we still need MCP? Three cases you can’t get around

  • Case A: discovering unknown capabilities. “Help me optimize AWS costs” — the agent has no idea how many APIs AWS has. MCP can discover the capability map: ec2, lambda, rds, cost explorer.
  • Case B: permission control. Letting an agent hold your token and run aws delete-instance is a huge risk; MCP can precisely declare read_cost=true, delete_instance=false.
  • Case C: enterprise environments. A company won’t let an agent execute arbitrary shell — but it will allow calling audited, sanctioned MCP capabilities.

The Three-Stage Arc I See

Zooming out, I’d chart three phases:

Today (the MCP 1.0 era): human → configure MCP → agent → tools. User pain.

The Code Mode era: human → agent → code → runtime → MCP/CLI/API. Users stop managing tools.

The longer term (around 2030): possibly User Intent → Agent OS → Capability Graph → Execution Runtime → World. By then, MCP, CLI, and API are all just low-level capabilities, and the human talks to the agent at the intent layer.

What This Really Means for a “Personal AI Operating System”

I’ve been pushing toward turning OpenClaw into a personal-level AI operating system, and this trend hands me the answer to what future competitiveness actually looks like.

The point of a personal AI OS isn’t “how many MCPs did I install.” It’s “can my agent runtime dynamically discover, compose, and execute my entire digital capability set.” What will separate the good from the great:

  1. Agent memory — remembering who you are and what you’ve done
  2. Capability discovery — finding and orchestrating new abilities
  3. Sandbox execution — safely running arbitrary code
  4. Permission model — clear, controllable authorization boundaries
  5. Long-running workflow — sustaining long, multi-step autonomous tasks

MCP will gradually evolve from a “user plugin system” into an “agent kernel interface.” The “simple, efficient, stable” qualities I’ve always chased turn out to be the kernel-grade virtues this direction demands — not piling up more tools, but making the runtime itself strong and formidable enough to do the rest.

Editor’s Note

This piece crystallized during an extended conversation with my AI assistant, sparked by the overseas community’s buzz around agent Code Mode. What drove me to write it down was that pointed misreading: the reflexive “Code Mode means no more MCP.” The genuinely deep shift is that tools stop being the user’s configuration burden and become the Agent’s low-level capability graph. If you’re building your own agent setup, I hope this recalibrates your priorities — stop counting MCPs, and start sharpening the runtime that can discover capabilities on its own.