DEV Community: Abin

Agents Behind Walls: Who Will Push Over the First Brick

Abin — Mon, 30 Mar 2026 08:00:14 +0000

The first two posts covered: CLI vs MCP is a fight over pipes — what's actually missing is the faucet (post one); Agent adoption is blocked by two layers of barriers — platform lock-in and organizational control (post two). This post looks at how different players are actually responding to those two walls.

Three Strategies

Faced with data barriers, three distinct strategies have emerged:

Strategy 3 has plenty of representatives. OpenClaw runs 24/7 on a Mac mini, and the community has built Skills for auto-generating daily standup reports[2] and financial statements. Perplexity launched Personal Computer[5] in March 2026, also running on a Mac mini, connecting to 40+ services including Gmail, Slack, GitHub, Notion, and Salesforce for $200/month. Anthropic's Claude Cowork positions itself as a locally autonomous Agent. The demo videos show data flowing seamlessly across platforms.

These capabilities are real. But they all share one prerequisite: you already have API access to every tool involved. As analyzed in post two, that prerequisite simply doesn't hold in most real work environments — platforms may not expose APIs at all, and even when they do, your company's IT department may not approve access.

There's a telling asymmetry worth noting: the same idea — having AI operate apps on behalf of users — is celebrated on the PC side (OpenClaw) while being actively blocked on mobile (Doubao Phone (ByteDance's AI phone)), where WeChat, Alipay, and other major apps banded together to shut it down[6]. The reason is obvious: every app on mobile is a closed ecosystem, and a system-level AI assistant strikes directly at the heart of their traffic monetization.

Let's focus on the first two strategies.

Strategy 1: Build a Closed Loop Inside the Wall — Alibaba's Two-Front Push

Alibaba's strategy is the clearest: don't break down the walls — build the closed loop inside your own walls first. And they're doing it on both the consumer and enterprise sides simultaneously.

Consumer Side: Qwen App — The Full "Search → Decision → Payment → Fulfillment" Chain

The "Qwen Do It" feature in the Qwen (Alibaba's AI assistant app) App has already integrated the core consumer scenarios across the Alibaba ecosystem[^9]:

This isn't a demo — Alibaba is putting real money behind making this closed loop work. The Qwen App's "First Order of the Day" promotion[10] distributes 15 million coupons daily, covering food delivery, hotels, flights, ride-hailing, and movie tickets, with all payments processed through Alipay AI Pay. A user can say "order 30 cups of bubble tea for me" and Qwen handles the entire flow: understanding the request, selecting items, automatically claiming coupons, and landing directly on the checkout page.

Quantum Bit's assessment: Alibaba has become "the world's first tech company to open the full AI 'search-decision-payment-fulfillment' chain at scale"[9]. Technically, it's built on MCP + A2A protocols with a multi-Agent architecture — a primary Agent breaks down tasks, and multiple sub-Agents execute independently within their respective domains.

Auth within the ecosystem is nearly invisible — on first use, you complete an OAuth-style account binding between Qwen and Amap/Taobao/Fliggy (similar to gh auth login), and every subsequent operation carries the session automatically. The entire Alibaba ecosystem shares the Alipay account system, so users never have to re-authorize.

Enterprise Side: Wukong — Enterprise AI Agent Platform

On March 17, 2026, Alibaba launched "Wukong (Alibaba's enterprise AI agent platform)"[4], an enterprise AI Agent platform embedded inside DingTalk (Alibaba's enterprise chat), which serves over 20 million business organizations. DingTalk CEO Chen Hang was direct about the positioning:

"Unlike every other lobster Agent on the market, Wukong is natively embedded in the enterprise organization."

DingTalk, with its 800 million users, underwent a complete rewrite of its underlying codebase for this — a comprehensive CLI transformation[11]. Wukong natively operates DingTalk's thousands of capabilities rather than simulating human clicks. Notably, this CLI was designed specifically for AI: commands can be long and detailed (AI doesn't need to memorize them), and output is directly in JSON (AI parses structured data far more efficiently than reading formatted text). This validates the efficiency advantage of CLI for Agent tool-calling discussed in post one. Alibaba's enterprise capabilities — Taobao, Tmall, 1688, Alipay, Alibaba Cloud — are being progressively integrated as Skills, with the first batch covering ten industry verticals[4]. AI Agents automatically inherit enterprise permission rules, bypassing the "organizational control" barrier analyzed in post two.

Ecosystem Comparison

Player	Has	Missing
Alibaba (Qwen + Wukong)	E-commerce + payments + mobility + local services + enterprise collaboration + cloud	Social, content
Tencent	Social + content + payments + WeCom	E-commerce loop, mobility
ByteDance	Content + local services + Lark	Payments, supply chain
Google	Search + maps + AI models	Transaction loop, enterprise collaboration

Alibaba's edge: closest to the transaction, and closed loops on both consumer and enterprise sides. The ultimate value of an Agent isn't conversation — it's completing the full chain of decision → execution → payment. Alibaba is currently the only platform that has made this chain work on both the consumer side (Qwen App) and the enterprise side (Wukong).

But There's a Structural Tension Here

The essence of a private-ecosystem Agent: trading the convenience of AI for the user's right to comparison-shop. Qwen can help you automatically claim coupons, bundle orders, and check out on Taobao Flash Buy — but it won't tell you the same order might be cheaper on DoorDash.

Strategy 2: Climb Over the Wall — Scraping in a New Form

Rather than waiting for platforms to open up, some players are forcing their way through:

Several representative products have taken this route, each with different technical approaches but the same underlying logic:

AutoGLM (Zhipu AI's mobile agent)[^7]: Gives AI a "cloud virtual phone." The Agent runs inside a cloud VM, uses a vision model to understand screen content, and simulates human interactions to complete cross-app tasks (ordering food, booking flights, posting on Weibo). No API required — it just "sees" the screen.

Doubao Phone (ByteDance / UI-TARS)[^6]: A mobile GUI Agent, also vision-driven. A single voice command can handle everything from scheduling a dinner to booking the venue and syncing everyone's calendars. After launch, it was blocked by WeChat, Alipay, and several other major apps. A phone that retails for ¥3,499 was being resold on the secondhand market for ¥36,000.

Manus[^8]: Each task gets its own dedicated Firecracker microVM (the same technology behind AWS Lambda). The Agent runs a browser, writes code, and manipulates files inside a full cloud sandbox environment, then delivers results when the task is done.

Different technical forms, same fundamental approach: bypassing the platform's authorization system to access data and execute actions without going through the API front door. From scraping web pages to scraping screens to spinning up virtual machines, the techniques keep evolving — but the fragility and legal gray areas haven't fundamentally improved. A UI redesign breaks everything. A platform ban shuts it down. Legal risk hangs over it indefinitely.

And "climbing the wall" isn't just fragile — it's dangerous. The OpenClaw security incident[1] is a cautionary tale:

10,000+ instances leaked user credentials due to misconfiguration
12% of community Skills were found to be malicious — injecting code, stealing data, establishing persistent backdoors
770,000 Agents were found to be vulnerable to remote hijacking

These aren't code bugs. They're inevitable consequences of the architecture — when you give an Agent shell access without authorization boundaries, security incidents are a matter of when, not if. This is also why MCP's OAuth and permission isolation still have real value in enterprise contexts.

These products are genuinely pushing something important forward, but doing it in a way that's unsustainable — not just technically, but from a security standpoint as well.

Analogy: The Evolution of Video Streaming

The Agent ecosystem today looks like video streaming in 2008 — delivering value to users on the back of "scraped" content (data). Users genuinely benefit, but the model isn't sustainable.

Legitimization requires platforms to proactively open up — just as video streaming eventually moved toward licensing deals. But in the Agent world, that means platforms surrendering control over data, which strikes at the foundation of their business models.

What Forces Will Push Over the First Brick?

Not technology. Three things drive change:

1. The Irreversibility of User Expectations

If Alibaba's closed-loop Agent gets there first, and users experience "say one sentence and get a hotel booked, flights arranged, and a route planned" inside the Alibaba ecosystem — going back to manually searching on other platforms becomes unbearable.

2. Regulatory Pressure from Outside

The EU's Digital Markets Act (DMA) has already produced real enforcement results[^12]:

6 gatekeepers designated: Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft (September 2023)
First fines issued in April 2025: Apple €500 million (restricting App Store openness) + Meta €200 million (forced "pay or consent") = €700 million combined
Maximum penalty: 10% of global annual revenue (20% for repeat violations)
Article 7 mandates interoperability for messaging services (WhatsApp and Messenger must support cross-platform messaging)
Apple and Google have been forced to open cross-platform data portability (iOS 26.3 beta added a "Transfer to Android" feature)

China's Personal Information Protection Law (PIPL), Article 45, also establishes data portability rights — users can request that their personal information be transferred to another processor of their choosing. But current enforcement has focused on privacy protection (cracking down on doxxing, facial recognition abuse, etc.), and there are no cases yet of data portability rights being used to force platforms to open data to third-party Agents.

The gap is stark: the EU is using fines to force openness, while China's data portability provisions remain largely on paper. If China were to introduce enforcement comparable to the DMA, that would be the real turning point.

3. The Prisoner's Dilemma of Competition

Just like UnionPay/NetsUnion (China's payment clearing networks) opening up payments — nobody chose to open up voluntarily. It was driven by regulation, competition, and user expectations working together.

What Alibaba is doing right now looks, in the short term, like reinforcing its own walls. In the long run, it may actually be the first domino that knocks the walls down — because it creates a user experience gap that forces other platforms to follow.

So What Are We Waiting For?

The bottleneck in the AIGC era isn't that AI isn't powerful enough — it's that data holders have no incentive to let AI make choices on behalf of users.

Because the moment an Agent can help users make optimal decisions, platforms lose their ability to manipulate user choices. The value Agents deliver to people's lives and the threat they pose to platform profits are two sides of the same coin.

There's no technical solution to this problem — it requires user expectations, regulatory pressure, and market competition to push it forward together. And those three forces are slowly building.

Where will the first brick fall? My guess: Alibaba's closed-loop Agent creates an experience gap first, then competitive pressure propagates to other platforms, then regulation gives it a final push.

As for how long that takes — probably slower than the tech optimists think, and faster than the pessimists expect.

This is the third post in the "Thinking About the Agent Ecosystem" series. The core thesis of this series comes down to one sentence: **CLI vs MCP is a fight over pipes — what's missing is the faucet.* The technology is all ready. We're waiting for data holders to make their choice.*

References

[1]: OpenClaw security incident data from ScaleKit, "MCP vs CLI: Benchmarking AI Agent Cost & Reliability", Mar 2026. Also cited in Skills vs MCP: The Token Efficiency War.

[2]: OpenClaw community Feishu integration Skills, including feishu-ai-dailyreport (automated team daily reports) and finance-report-analyzer (financial statement generation).

[3]: Microsoft AutoGen framework (55,000+ GitHub stars), unified with Semantic Kernel into Microsoft Agent Framework in Q1 2026. Early enterprise adoption cases include KPMG audit automation and BMW vehicle telemetry analysis. See Microsoft Agent Framework GA: Production Adoption Strategy.

[4]: Alibaba launched enterprise AI Agent platform "Wukong" on March 17, 2026, embedded in DingTalk, with Alibaba enterprise capabilities integrated as Skills. See Sina Finance report and Jinglin Xianghai in-depth analysis.

[5]: Perplexity launched Personal Computer on March 11, 2026 at the Ask 2026 developer conference, running on a Mac mini at $200/month (Perplexity Max subscription), connecting to 40+ services. See The Verge report.

[6]: Doubao Phone (ByteDance UI-TARS technology) launched a technical preview in December 2025, subsequently blocked by WeChat, Alipay, and several other major apps. A phone retailing at ¥3,499 was resold on the secondhand market for ¥36,000. See Sina Finance: "What Manus and Doubao Phone couldn't do — why did a 'lobster' pull it off?".

[7]: AutoGLM (Zhipu AI's mobile agent): the world's first mobile Agent, based on the GLM-4.5V multimodal model, using a "cloud virtual phone" architecture where the Agent runs in a sandbox. Open-sourced in December 2025 (Apache-2.0). See GitHub: Open-AutoGLM.

[8]: Manus: a general-purpose Agent platform where each task gets its own dedicated Firecracker microVM sandbox (2 vCPU, 8GB RAM), with the Agent running autonomously in a full cloud environment. Acquired by Meta in 2026. See Manus Sandbox core mechanism explained.

[9]: Qwen App's "Qwen Do It" feature integrates Taobao Flash Buy, Fliggy, Amap, Damai, Alipay, and other Alibaba ecosystem services, enabling the full "search → decision → payment → fulfillment" chain. Built on MCP + A2A protocols with a multi-Agent architecture. See Quantum Bit, "AI is starting to 'take action' — and Alibaba's Qwen is leading the world".

[10]: Qwen App "First Order of the Day" promotion rules: 15 million coupons distributed daily, covering food delivery, snacks and groceries, hotels, movie tickets, flights, train tickets, and ride-hailing. Services fulfilled by Taobao Flash Buy, Damai, Fliggy, and Amap; payments and coupon redemption handled by Alipay. Data source: Qwen App promotion rules page (effective February 18, 2026).

[11]: DingTalk's comprehensive CLI transformation: DingTalk, with 800 million users, completed a full rewrite of its underlying codebase and shifted entirely to a CLI architecture. Unlike the DOS-era CLI, this one is designed specifically for AI — commands can be long (AI doesn't need to memorize them), and output is in JSON (structured data). See Tencent News, "DingTalk has gone fully CLI"; Chaoji Net, "DingTalk 2.0 major upgrade: full underlying code rewrite, comprehensive CLI command-line interface transformation".

[12]: EU DMA enforcement data: first fines issued April 23, 2025 — Apple €500 million + Meta €200 million = €700 million combined. See 36Kr, "€700 million: EU issues first fines under the Digital Markets Act against Apple and Meta"; Security Insider, "The EU Digital Markets Act compliance exam is over — what did the six gatekeepers submit?", March 2026. China's Personal Information Protection Law Article 45 establishes data portability rights, but enforcement has focused on privacy protection; see the Supreme People's Procuratorate's typical cases of personal information protection procuratorial public interest litigation, January 2026.

Your Agent Can't Help You — And It's Not Because It's Dumb

Abin — Mon, 30 Mar 2026 07:57:56 +0000

In the previous post we argued that the CLI vs. MCP debate is really a debate about pipes — and what's actually missing is the faucet. This post digs one level deeper: even if you open the faucet, you probably still can't connect to it. The reasons agents struggle in the real world are more structural than most people realize.

A Common Promise

"Let an agent automatically write your weekly status report — it reads your Git commits, Slack channel history, Jira ticket updates, and Google Calendar meetings, then generates a report your manager can actually read."

This is the story agent products love to tell. It sounds reasonable — the data is all yours, you're already using all the tools, you're just automating what you'd otherwise do by hand.

But if you actually try it, you'll find that only 1 out of 5 data sources works:

It's not that the agent isn't smart enough. It's not that the CLI isn't efficient enough. The data simply isn't reachable.

There are, of course, some "workaround" approaches that try to bypass this limitation: browser extensions that piggyback on your login session to scrape Slack messages, RPA tools that simulate clicks to export Jira data, reverse-engineered wrappers around corporate email APIs. These can make a demo work. But they're fundamentally web scrapers — a UI redesign breaks them, a security policy update kills them, and the legal exposure never goes away. Building a workflow on top of these approaches is building on quicksand.

We'll take a detailed look at these "workaround" approaches and their limitations in the third post. For now, let's focus on a more fundamental question: why don't the legitimate paths work?

An Agent's Real Capability Depends on Three Variables

The entire industry is racing to improve LLM capability and tool protocols. But the real bottleneck is data access. It's like having a top-of-the-line race car and a perfect track — with an empty fuel tank.

Two Walls: Why the Data Is Out of Reach

"Data is inaccessible" isn't a vague problem. It has two distinct walls, each with a fundamentally different character:

Wall 1 gets the most attention, but in practice, Wall 2 is the one most people actually hit.

Wall 1: Platform Lockdown

WhatsApp won't ship a CLI. Amazon won't open a price-comparison API. TikTok won't give you access to its recommendation data. The previous post argued from a technical standpoint that CLI is perfectly capable of implementing OAuth (gh auth login is proof), so this isn't a technical barrier[1].

So why don't they do it? Because data enclosure is the foundation of these platforms' business models.

Once an agent can make optimal decisions on a user's behalf — comparing prices, comparing ratings, searching across platforms — the platform loses its ability to steer user behavior through recommendation algorithms. That directly threatens the core revenue from advertising and traffic monetization.

A simple heuristic: whether a platform will open up to agents depends entirely on whether opening up serves its commercial interests.

Platform type	Examples	Open to agents?	Logic
Sells subscriptions / services	GitHub, Notion, Vercel	✅ Actively open	More agent integrations → users more dependent → more paid conversions
Sells traffic / advertising	WhatsApp, Amazon, TikTok	❌ Locked down	Agents help users skip recommendations → ad value drops
Sells enterprise software	Slack, Microsoft Teams	⚠️ Partially open	Rich bot ecosystem → enterprises more dependent on the platform

Wall 2: Organizational Control — Visible Doesn't Mean Accessible

Here's a concrete example. You open Slack in your browser at work and can see all your channel history and shared files. Now you want to write a script so an agent can read the same messages. You'll discover you need to create a Slack App on the Slack API dashboard, request channels:history and channels:read scopes, and then submit it to your workspace admin for approval. The admin might ask what you need the permission for — and then deny you.

Data you can see in a browser is not necessarily data your program can read. The two paths use completely different authentication chains:

Every day you open Slack to read messages, check Jira tickets, and read email — that's visual access. Your browser holds the session, cookies are sent automatically, everything is seamless.

But an agent takes a completely different authentication path:

Having the former doesn't mean you have the latter. Agents can only take the latter path.

From the perspective of an ordinary developer (non-admin), here's the actual API accessibility of common tools:

Tool	Visible in browser	Callable via API	Where it gets stuck
Git (local)	✅	✅	SSH key is local — no approval needed
Slack	✅	❌	Creating a Slack App requires workspace admin approval for sensitive scopes[2]
Microsoft Teams	✅	❌	Custom apps require IT admin sideloading approval
Jira Cloud	✅	⚠️	Depends on whether the company has disabled Personal Access Tokens
Corporate email	✅	❌	IMAP/SMTP typically blocked by security policy
Google Workspace	✅	❌	OAuth apps require admin to whitelist them
Notion (personal)	✅	✅	Personal Integrations don't require workspace admin involvement[3]

The conclusion is clear: the only things you can freely access via API are local files, personal Git repositories, and personal Notion workspaces. Everything else is blocked at the organizational admin approval step.

This also explains a pattern: why is coding assistance currently the most successful agent use case? Because code lives in your local filesystem — no one's permission required.

A Note: What Happens After You Get the Data?

Someone might ask: even if you break through both walls, the data is scattered across Git, Slack, Jira, email, and other systems in different formats — doesn't that count as a third wall?

Honestly, with 2026-era LLMs, this isn't a real barrier. Git log is plain text, Jira's API returns JSON, Slack messages are structured data — as long as data can be converted to text, current models can read and synthesize it. Identity mapping (Git email ≠ Slack user_id) just needs to be told to the model once. Time alignment, semantic extraction, deduplication and categorization — these are exactly what LLMs are best at.

Inconsistent data formats are engineering friction, not an architectural barrier. They're not in the same league as the first two walls (platform lockdown and organizational denial of access).

The only two things that actually block agents are: platforms that won't open up, and organizations that won't allow it. Once the data is in hand, the model can handle the rest.

The Real Boundaries of Agent Capability

Taking both walls into account, here are the true capability boundaries for agents in 2026:

Use case	Technically feasible	Actually usable	Blocked by
Coding assistance (writing code, debugging)	✅	✅	No wall — code is local
Search public information and summarize	✅	✅	No wall — public internet data
Auto-write weekly status report	✅	❌	Wall 2: Slack / Jira API permissions
Cross-platform price comparison (flights, hotels)	✅	❌	Wall 1: Booking.com / airline sites not open
Customer relationship management	✅	❌	Wall 2: CRM API requires IT approval
Auto-process email	✅	❌	Wall 2: IMAP is blocked
Cross-platform content publishing	✅	❌	Wall 1: platforms don't interoperate
Personal health data analysis	✅	❌	Wall 1: health apps don't open up

Technically feasible across the board. Actually doable for almost none of them.

Conclusion

Your agent can't help you — not because it isn't smart enough. It's because of two walls:

Platform lockdown: Business models are built on data enclosures. They won't voluntarily open their APIs. This is a commercial negotiation problem.
Organizational control: Even when a platform has an API, your company's IT security policy may not allow you to use it. This is an organizational management problem.

As for inconsistent data formats and the need to integrate information across systems — with current LLM capability, that's just engineering friction, not a real obstacle. Once the data is in hand, the model can handle it. The problem is that the data never gets there.

And most agent product marketing never mentions any of this. It simply assumes "you have API access."

Next time someone pitches you on "automating your workflow with agents," ask two questions first:

Does the platform provide an API for this data?

Does my organization allow individuals to use that API?

Both need to be Yes for anything to actually work. In the reality of 2026, scenarios where both are Yes are still rare.

This is the second post in the "Thinking About the Agent Ecosystem" series. Next up: since the data is out of reach, who is working around it and how? Alibaba's closed-loop ecosystem, Doubao's screen-scraping phone agent, and what forces might eventually push things toward openness.

References

[1]: On the relationship between platform data lockdown and business models, see MCP vs. CLI for AI Agents: The Answer Is Both and The MCP vs CLI Debate Is Missing the Point. The first post in this series argued from a technical standpoint that CLI is fully capable of implementing OAuth — so the reason platforms don't open up is a business choice, not a technical limitation.

[2]: Creating a Slack App with sensitive OAuth scopes (such as channels:history, chat:write) requires workspace admin approval. See the Slack API documentation on scopes. Enterprise Grid workspaces enforce even stricter approval workflows for custom integrations.

[3]: Notion's Internal Integration allows individual users to create integrations directly, without involving a workspace administrator; see the Notion API documentation. This makes it one of the few collaboration tools that supports personal-level OAuth.

CLI vs MCP vs Skills: The Whole Debate Is Asking the Wrong Question

Abin — Fri, 27 Mar 2026 04:48:36 +0000

What They're Fighting About

In March 2026, the hottest topic in the AI Agent world isn't which model is smarter — it's a deceptively boring architecture question:

How should an Agent call external tools?

Three camps, three answers:

The MCP Camp (Model Context Protocol): An open standard Anthropic launched in late 2024¹. It wraps service interfaces in a unified JSON-RPC protocol so an Agent can call multiple tools across platforms after a single integration. OpenAI, Google, Microsoft, and AWS have all followed suit². Sounds great on paper.

The CLI Camp: Just let the Agent run shell commands — git log, gh pr list, curl, kubectl. No protocol layer, no extra servers. The grep and awk from 50 years ago are having a second life in the AI era.

The Skills Camp: A Markdown file acts as a "cheat sheet," teaching the Agent which tool to use in which situation. It sits idle at ~30 tokens and only loads the full instructions when triggered. Flask creator Armin Ronacher has fully switched to this approach³.

March 2026: Where Things Stand

Pressure on the MCP camp:

Perplexity published a blog post announcing they're dropping MCP entirely in favor of CLI⁴
Eric Holmes's "MCP is dead. Long live the CLI" hit the top of Hacker News⁵
ScaleKit benchmarks: MCP had a 28% failure rate (timeouts), CLI was 100% reliable⁶
Worth noting: Anthropic, the very company that created MCP, built their own product Claude Code on an architecture that looks much more like CLI than MCP

Momentum behind the CLI camp:

Andrej Karpathy said in February 2026 on X that CLIs are "super exciting precisely because they are legacy"⁷
Smithery published 756 benchmark runs systematically comparing CLI vs MCP on Codex and Claude Code⁸
Google open-sourced command-line tools specifically designed for AI use⁹

The rise of the Skills camp:

Simon Willison (prominent Python community developer) called Claude Skills "maybe a bigger deal than MCP" when it launched¹⁰
Armin Ronacher fully migrated from MCP to Skills and explained why³:

"Skills are essentially just a short summary that tells the Agent what capabilities exist and where to find more details. The key thing is — Skills don't inject any tool definitions into the context. The tools are still the same tools: bash and whatever the Agent already has."

The community is starting to see "delete all your MCPs, replace with Skills + CLI" posts gaining traction¹¹

Where CLI Wins: A Technical Breakdown

1. MCP's Context Pollution Problem

MCP's biggest issue: the moment an Agent starts up, it has to stuff every tool's schema into the context.

GitHub's Copilot MCP Server exposes 43 tools. Connecting to it injects roughly 55,000 tokens of tool definitions into your context¹¹. You haven't done anything yet and you've already burned through a huge chunk of your token budget. Hook up 10 MCP Servers with 100 tools? Context explodes.

CLI is completely different — progressive discovery. The Agent runs gh --help to see what commands exist, then gh pr --help when it needs subcommand details. Information loads on demand, not all at once at startup.

2. LLMs Already Know CLI

LLM training data contains decades of Unix documentation, Stack Overflow answers, and shell scripts from GitHub. Models natively understand git, curl, grep, docker.

MCP? Lots of JSON schema that's harder for models to process, plus the overhead of generating formatted JSON tokens. Your custom MCP tools don't appear in training data — the model has no prior knowledge of how to call them.

3. Pipes

If an MCP tool's output needs post-processing (filtering, searching, slicing), you need to write extra code. With CLI, you just pipe:

gh pr list --json number,title | jq '.[] | select(.title | contains("fix"))'

The Agent outputs a few commands connected with | and post-processing is done. Simpler, more flexible, lower maintenance cost.

4. CLI and Skills Are a Natural Pair

Teaching an Agent to use CLI inside a Skill file is clean and readable:

## Check PR Status
gh pr list --state open --json number,title,author

Try doing that with MCP? The Skill file fills up with function calls and JSON schema. The whole document becomes a mess.

The Numbers

ScaleKit ran 75 benchmark tests⁶ on the same GitHub task (Claude Sonnet 4, same prompt):

Approach	Monthly Cost (10k calls)	Reliability
CLI	~$3.20	100%
CLI + Skills	~$4.50	100%
MCP	~$55.20	72% (28% timeouts)

CLI is 17x cheaper, with 100% reliability vs 72%. Costs calculated at Claude Sonnet 4 pricing ($3/M input, $15/M output)¹². The gap is significant.

At This Point, CLI Looks Like a Clear Winner

Fewer tokens, more familiar to models, supports pipes, pairs naturally with Skills. On every efficiency metric, MCP is at a disadvantage.

To Be Fair: MCP Is Adapting

MCP isn't standing still. In January 2026, Anthropic introduced progressive discovery¹³ — essentially borrowing the on-demand loading idea from Skills:

Initially load only tool names and short descriptions (20–50 tokens per tool)
Full schema only loads when the Agent decides to actually use that tool

Results:

Token overhead reduced by 85% (77,000 → 8,700 tokens in a 50+ tool scenario)
Tool call accuracy improved: Claude Opus 4 went from 49% to 74%

The gap is narrowing. But Skills still wins on pure efficiency — because it doesn't inject schema at all, only knowledge.

But even if MCP's efficiency problems were completely solved, there's a more fundamental question nobody is asking:

Every benchmark runs in the same scenario — one developer, using their own credentials, automating their own workflow.

A lot of articles at this point would say: "But MCP has OAuth — it's irreplaceable for multi-tenant scenarios! CLI can't handle authentication!"

Can it though?

Something I Experienced Today

I deployed this blog today using OpenCode (an AI Agent that works via CLI). The Agent called the Vercel CLI:

$ vercel login
→ Browser OAuth page opens automatically
→ Click to authorize
→ CLI grabs the token, saves it locally
→ All subsequent commands work seamlessly

Ten seconds. One CLI tool. A complete OAuth browser authorization flow.

Then I thought about gh auth login — GitHub CLI does exactly the same thing. Browser pops up, OAuth authorization, scoped token, local persistence.

So:

CLI doesn't "architecturally lack OAuth support." gh and vercel have already proven that.

If WhatsApp wanted to build a whatsapp auth login, the flow would be identical to gh:

$ whatsapp auth login
→ Browser opens WhatsApp authorization page
→ Confirm on your phone
→ Token saved locally
→ whatsapp send alice "hello"
→ whatsapp groups list

Zero technical barriers. But it will never exist.

Not because it can't be done — because doing it would mean voluntarily dismantling the walled garden and anti-scraping infrastructure that Meta has spent years building.

So What Is MCP Actually Good For?

MCP's value isn't "doing things CLI can't do" — gh has already proven CLI can handle OAuth.

MCP's value is standardization:

For one platform, gh is enough. But when you need to integrate 50 platforms, the maintenance cost of each having its own CLI auth flow becomes unacceptable. MCP offers the possibility of "all platforms opening up via the same protocol."

But standardization has a prerequisite: platforms have to be willing to implement it.

So the Whole Debate Is Asking the Wrong Question

GitHub built gh — CLI dominates within the GitHub ecosystem.
Vercel built vercel login — the deployment experience is seamless.
WhatsApp never built a CLI — your only options are scraping, or waiting.

Amazon, DoorDash, TikTok — they're all in the same boat. The data exists, the technical capability exists, the willingness doesn't.

What determines the boundaries of what an Agent can do isn't whether you chose CLI or MCP. It's whether the platform is willing to give you a pipe — in whatever form.

CLI vs MCP is a debate about what the pipe is made of. The real problem is that there's no faucet.

Token cost is an engineering problem. Protocol choice is an architecture problem. Data openness is a political problem. The first two are being solved. The third is the actual bottleneck choking the entire Agent ecosystem. And the whole community is using a technical framework to avoid the genuinely hard political question.

This is the first post in the "Thinking About the Agent Ecosystem" series. Next up: even when a platform has an API, you probably still can't use it — the two layers of friction blocking Agent adoption are thicker than you think.

References

Anthropic, "Introducing the Model Context Protocol", Nov 2024. MCP was released in November 2024 and donated to the Linux Foundation's Agentic AI Foundation (AAIF) in December 2025. ↩
OpenAI announced MCP support in March 2025, Google DeepMind in April 2025, Microsoft Copilot Studio and AWS in July 2025. See CLI-Based Agents vs MCP: The 2026 Showdown. ↩
Armin Ronacher (Flask creator), "Skills vs Dynamic MCP Loadouts," explaining why he fully switched from MCP to Skills. See the quote in Skills vs MCP: The Token Efficiency War. ↩
Perplexity CTO Denis Yarats announced at the Ask 2026 developer conference (March 11, 2026) that they were deprecating MCP internally in favor of REST APIs and CLI. See Awesome Agents coverage and Agent Engineering deep dive. ↩
Eric Holmes, "MCP is dead. Long live the CLI", Feb 28, 2026. Hit the top of Hacker News with 400+ upvotes and nearly 300 comments. ↩
ScaleKit, "MCP vs CLI: Benchmarking AI Agent Cost and Reliability", Mar 2026. Full data and methodology from 75 benchmark runs. Benchmark code open-sourced on GitHub. ↩
Andrej Karpathy posted on X (Twitter) in February 2026 calling CLIs for Agent workflows "super exciting precisely because they are a legacy." See Why CLIs Beat MCP for AI Agents. ↩
Smithery (Henry Mao), "MCP vs CLI is the wrong fight", Mar 2026. 756 benchmark runs across 3 APIs covering Codex and Claude Code, with analysis across skills, code mode, and pretraining bias dimensions. ↩
Google's open-source AI CLI tools: gws (Google Workspace CLI, 21.8k stars, 100+ Agent Skills) and Gemini CLI (Apache-2.0). ↩
Simon Willison, "Claude's Skills", Oct 2025. Called it "maybe a bigger deal than MCP" at launch. ↩
Agent Native, "Delete your MCPs: Skills + CLI outperform at ~20x lower cost", Mar 2026. Notes that GitHub Copilot MCP Server exposes 43 tools and injects approximately 55,000 tokens on initialization. ↩
Anthropic Claude pricing page: Claude Sonnet 4 — $3/M input tokens, $15/M output tokens. Monthly cost estimates based on median token data from ScaleKit benchmarks. ↩
Anthropic MCP progressive discovery. See "MCP Tool Search: Claude Code Context Pollution Guide". The 85% token reduction and accuracy improvement figures come from Skills vs MCP: The Token Efficiency War. ↩