06-reference/research

mcp vs cli agent native interface task class

2026-05-21·research-brief·source: deep-research
mcpcliagent-nativeskill-architecturerdco-toolingcontext-budget

MCP vs Platform-Vendor CLI — Task-Class Split for Agent-Native Interfaces

The question

MCP vs platform-vendor CLI — which agent-native interface wins for which task class? (Source: curiosity, High priority. Founder direct question 2026-04-29; Meta Ads CLI launch 2026-04-29 was the trigger signal.)

What we already know (from the vault)

What the web says

Convergences and contradictions

Convergence: vault and web agree the CLI wins for unattended, deterministic, high-frequency operations (ad ops, payments, deployments, file ops). The Meta Ads CLI launch copy ("works unattended in CI/CD") and the MindStudio 35x token-overhead benchmark both point at the same task class: high-frequency operational tasks where the agent runs without a chat loop.

Convergence: both vault and web frame MCP as winning for governance + live external data access. RDCO's current MCP-heavy posture is correct for the cross-service-discovery surface (Notion, Gmail, Calendar, Discord). The wrong-fight framing is that RDCO shouldn't try to replace MCP — it should complement MCP with CLIs for the operational surface.

Contradiction (sharper than expected): Dan's framework recommends "80% MCP for external tools you don't own." Web benchmarks suggest this is the wrong split — even external tools that have MCP available may be cheaper and more reliable accessed via the vendor's CLI when one exists. The arrival of Stripe Link CLI and Meta Ads CLI (2026 wave) means the "external tools you don't own" category is shifting toward CLI availability. Dan's Nov 2025 framework was correct for the world of Nov 2025; the 2026 platform-vendor-CLI wave inverts it.

Contradiction (mild): vault's "skills are Claude-ecosystem lock-in" framing implies CLIs are the portable answer. Web sources actually frame skills + MCP gateway as the enterprise-portable pattern. The disagreement is what "portable" means: across LLM runtimes (vault's frame) vs across enterprise environments (web's frame). Both true on their own terms; RDCO should care more about the first since it's a single-operator harness, not a multi-tenant enterprise stack.

Synthesis for RDCO

The task-class split clarifies into a four-quadrant decision matrix:

Low frequency (advisory, chat-loop) High frequency (operational, unattended)
External tool, vendor-provided MCP if available, CLI as fallback CLI when available (the 2026 wave); MCP otherwise
Internal tool, RDCO-authored Skill (chat-loop ergonomics) CLI under ~/.claude/scripts/, prime-prompt pattern

Implication 1: RDCO's operational skills should migrate toward CLI-first. The paid-ads skill, squarely-deploy skill, process-newsletter skill, and process-youtube skill all sit in the high-frequency operational quadrant. Their underlying logic is already CLI-driven (yt-dlp, vtt-to-text.py, wrangler, gh). The skill is the chat-loop ergonomics wrapper; the work happens at the CLI layer. This is correct architecture and should be the documented RDCO pattern. The migration cost is mostly documentation, not refactoring.

Implication 2: The Meta Ads CLI (and the coming Shopify, Google Ads, LinkedIn CLI wave) changes the agent-deployer wedge. When platform vendors ship CLIs explicitly named for AI agents, the friction of "agent connects to ad ops" drops to near-zero. RDCO's agent-deployer positioning needs to assume CLI-first surfaces are the default integration path within 12-18 months. Concretely: future RDCO client engagements will see "we already have the Meta Ads CLI, we just need someone to operate it inside our workflow" rather than "we need help wiring an MCP server." The deployer skill set shifts toward CLI orchestration + prompt engineering + workflow design.

Implication 3: The per-MCP context-cost ledger is overdue. Dan's framework names it; vault notes the open follow-up; the founder authorized it Apr 19. With 17+ MCP servers and 2026 Sanity Check content potential ("Your MCP servers are eating your context budget"), this is a 30-minute high-signal task. The blocker is the founder's queue, not analysis — should auto-execute on the next maintenance window.

Implication 4: For RDCO's mid-market clients, the recommended architecture is "MCP gateway for governance, CLI for operations." Per Tyk's enterprise framing, single MCP gateway with centralized auth + audit logging + rate limiting, with CLIs running behind it for the high-frequency operational work. This is the recommendation RDCO should give clients when asked "MCP or CLI?" — the right answer is "both, here's how they compose." It also defends the RDCO consulting wedge: the architecture work is the deliverable, not the tool choice.

Implication 5: The Sanity Check editorial angle is "the agent-native interface war has split, and CLI just won the operational surface." Non-derivative reframe (per the no-derivative-SC memory): not a recap of Meta's launch, but a structural read on what the launch tells us about where the agent-native surface war is heading. Pairs the Meta Ads CLI signal with the IndyDevDan tradeoff framework and the 35x token-overhead benchmark. Reader takeaway: rethink your tool surface, the default is changing.

Recommended skill-architecture rule for the RDCO codebase going forward:

When building a new RDCO tool surface, ask in order: (a) does the platform vendor ship a CLI for this? Use it. (b) Does it ship an MCP server? Use it when the task is chat-loop-anchored, low-frequency, or governance-sensitive. (c) Building it ourselves? Build the CLI first, with a --help that an agent can parse, and only wrap it in a skill when the chat-loop ergonomics earn the lock-in cost.

Open follow-ups

Sources

Vault:

Web: