CLI-First vs MCP: Choosing Your AI Agent Architecture

The MCP Victory

Model Context Protocol won. The numbers are unambiguous:

97M+ monthly downloads
10,000+ available servers
Linux Foundation AAIF governance
AWS, Google, Microsoft, OpenAI as platinum members

When your competitors join your standards body, you’ve won the standards war. MCP is now infrastructure—the “HTTP of agentic AI.”

So why are some teams moving away from it?

The Case Against MCP

1. Abstraction Has Costs

MCP adds a layer between your agent and its tools:

Without MCP:
Agent → Shell Command → Result

With MCP:
Agent → MCP Protocol → MCP Server → Tool → Result → MCP Server → Agent

Each layer adds:

Latency (server startup, protocol overhead)
Failure modes (server crashes, connection issues)
Debugging complexity (where did it fail?)

For simple operations, the overhead exceeds the benefit.

2. Transparency Loss

A shell command is readable:

curl -s "https://api.example.com/data" \
  -H "Authorization: Bearer $TOKEN"

You can see exactly what it does. Copy it. Run it manually. Debug it.

An MCP tool invocation is opaque:

{"tool": "fetch_data", "params": {"endpoint": "data"}}

What HTTP call does this make? What headers? What error handling? The server is a black box.

3. Server Management Burden

MCP servers are processes that need:

Starting and stopping
Health monitoring
Credential management
Version updates
Security audits

For teams already managing infrastructure, this is friction. For teams without ops capacity, it’s a blocker.

4. Context Overhead

MCP tool descriptions consume context:

{
  "name": "example_tool",
  "description": "Long description explaining what this tool does, its parameters, constraints, and usage patterns...",
  "inputSchema": { ... }
}

Multiply across dozens of tools, and you’re burning thousands of tokens on tool descriptions before any actual work happens.

The CLI-First Alternative

CLI-first architecture uses shell commands directly:

# Instead of MCP server for database
supabase db execute --project-ref "$PROJECT" "$QUERY"

# Instead of MCP server for web scraping
curl -s "$URL" | jq '.data'

# Instead of MCP server for browser automation
playwright screenshot "$URL" --output screenshot.png

Advantages

1. Transparency Every command is readable, copyable, runnable outside the agent. No black boxes.

2. Auditability Shell history provides a complete audit trail. history | grep curl shows every API call.

3. No servers Tools invoke on demand. No processes to manage, no connections to maintain.

4. Familiar tooling Developers already know bash, curl, jq. No new abstractions to learn.

5. Context efficiency A bash command takes fewer tokens than MCP tool registration + invocation.

Implementation Pattern

Instead of MCP servers, create simple wrapper scripts:

#!/bin/bash
# .agents/tools/api-query.sh
# Direct API call - no MCP server needed

API_KEY="${API_KEY:?API_KEY required}"
API_HOST="${API_HOST:-https://api.example.com}"

curl -s -X GET "${API_HOST}/$1" \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json"

The agent calls:

./.agents/tools/api-query.sh "users/123"

Readable. Auditable. No server required.

When MCP Wins

MCP isn’t wrong—it’s sometimes unnecessary. Use MCP when:

1. Complex State Management

Some tools require persistent connections:

WebSocket subscriptions for real-time data
OAuth flows with token refresh
Long-running transactions

MCP servers handle state that shell commands can’t.

2. Cross-Platform Compatibility

MCP abstracts platform differences. A single MCP server works across:

Claude Code
Cursor
Cline
VS Code extensions

CLI scripts may need platform-specific variants.

3. Ecosystem Tools

The MCP ecosystem has 10,000+ servers. If someone built it, you don’t have to.

For common integrations (Slack, GitHub, databases), existing MCP servers may be faster than writing scripts.

4. Enterprise Requirements

Some organizations require:

Centralized tool governance
Rate limiting and quotas
Usage analytics

MCP servers can implement these controls. Bare CLI tools cannot.

The Hybrid Approach

Most teams end up with a hybrid:

Critical path tools → CLI scripts (maximum transparency)
Complex integrations → MCP servers (when abstraction helps)
Ecosystem tools → MCP marketplace (don't reinvent)

Decision Matrix

Factor	CLI-First	MCP
Simple API calls	YES	Overhead not worth it
Database queries	YES (with CLI client)	Adds unnecessary layer
Browser automation	YES (playwright CLI)	MCP works too
OAuth integrations	Consider MCP	State management helps
Real-time subscriptions	MCP	Requires persistent connection
Off-the-shelf tools	—	Use ecosystem
Audit requirements	YES	Server is black box
Context efficiency	YES	Tool descriptions cost tokens

Migration Path

If you’re moving from MCP to CLI-first:

Phase 1: Identify Candidates

List your MCP servers. For each, ask:

Does it need persistent state?
Is there a CLI alternative?
How often is it used?

Low-frequency, stateless tools are migration candidates.

Phase 2: Create CLI Wrappers

For each candidate, write a shell script that does the same thing:

# Before: MCP server
mcp_invoke("database", "query", {"sql": "SELECT * FROM users"})

# After: CLI wrapper
supabase db execute "$SQL"

Test for parity. The output should match.

Phase 3: Update Agent Configuration

Remove MCP server registrations. Add CLI tools to the agent’s available commands.

Phase 4: Monitor

Track:

Latency changes
Error rates
Developer experience

CLI should be faster for simple operations. If not, investigate.

The Philosophy

The choice reflects a deeper architectural philosophy:

MCP assumes: Abstraction enables reuse. Standardize the interface, swap implementations.

CLI-first assumes: Transparency enables trust. See exactly what happens, debug without layers.

Neither is universally correct. The right choice depends on:

Team capabilities (ops-heavy vs ops-light)
Tool complexity (simple calls vs stateful integrations)
Audit requirements (regulated vs move-fast)
Ecosystem leverage (build vs buy)

Our Position

We’ve moved toward CLI-first for most tooling. Our reasoning:

Trust through transparency: We can read every command the agent runs
Debugging simplicity: Failures are shell errors, not protocol mysteries
No server management: Our infrastructure budget goes to agents, not tool servers
Context efficiency: Fewer tokens on tool descriptions, more on actual work

We still use MCP for complex integrations where the abstraction genuinely helps. But our default is CLI.

Summary

Approach	Best For	Avoid When
CLI-First	Simple tools, audit requirements, context efficiency, transparency	Complex state, real-time needs, ecosystem leverage
MCP	Cross-platform, stateful integrations, ecosystem tools, enterprise governance	Simple operations, audit sensitivity, minimal infrastructure
Hybrid	Most production systems	—

MCP won the standards war. That doesn’t mean every tool needs to be an MCP server.

Use the right abstraction for the right job.

Note: This represents one team’s architectural choices. MCP is excellent infrastructure. The question isn’t whether MCP is good—it’s whether you need it for a specific tool.