Why We Chose CLI Over MCP for Production AI Agents

The Contrarian Take

MCP (Model Context Protocol) won the standards war. 97 million downloads. AWS, Google, Microsoft backing. Linux Foundation governance.

We still don’t use it for most of our agents.

This isn’t about MCP being bad—it’s excellent for certain use cases. But after building dozens of production AI agents, we’ve found that CLI-first architectures are simpler, faster, and more debuggable for 80% of real-world scenarios.

What’s CLI-First?

Instead of building MCP servers to expose tools, you give your AI agent direct access to shell commands:

# MCP approach
Agent → MCP Client → MCP Server → Database Driver → Database

# CLI-first approach
Agent → psql command → Database

The AI writes and executes shell commands directly. No protocol layer. No server management.

Why This Works Better (For Us)

1. Zero Infrastructure

MCP servers need to:

• Start up (latency)
• Stay running (reliability)
• Be monitored (operations)
• Be updated (maintenance)

CLI tools are already installed. git, psql, curl, jq—they just work.

# This already exists everywhere
git log --oneline -10

# vs building an MCP server for git operations

Result: Our agents deploy with zero additional infrastructure.

2. Instant Debuggability

When something fails with MCP:

• Is it the client? The protocol? The server? The tool?
• Where are the logs?
• How do I reproduce this?

When a CLI command fails:

# Copy the exact command
psql -h localhost -d mydb -c "SELECT * FROM users"
# Run it yourself
# See the exact error

Result: Debug time dropped 70% after switching to CLI-first.

3. Composability

Shell commands compose naturally:

# Find large files modified today
find . -mtime 0 -size +1M | xargs ls -la

# Get API response, extract field, format as table
curl -s api.example.com/users | jq '.data[]' | column -t

MCP tools are isolated. Composing them requires custom orchestration.

Result: Complex workflows need less code.

4. Universal Compatibility

CLI tools work everywhere:

• macOS, Linux, Windows (WSL)
• Docker containers
• CI/CD pipelines
• Any shell

MCP servers need specific runtimes, dependencies, and configurations per environment.

Result: Same agent runs everywhere without modification.

5. Transparency

Your agent’s actions are auditable commands:

Agent executed: git diff HEAD~1
Agent executed: npm test
Agent executed: git commit -m "fix: resolve auth bug"

Anyone can read this. Anyone can reproduce it. Anyone can understand what happened.

Result: Non-technical stakeholders can audit agent behavior.

When MCP Makes Sense

CLI-first isn’t always right. Use MCP when:

Complex State Management

If your tool needs to maintain connections, sessions, or caches, MCP servers handle this well.

# MCP server can maintain database connection pool
# CLI would reconnect on every query

Rich Type Systems

MCP provides structured inputs/outputs. If you need complex parameter validation, MCP’s schema definitions help.

Third-Party Integrations

Some services only offer MCP servers. Using the existing server beats building CLI wrappers.

Team Standardization

Large organizations benefit from MCP’s standardization. Everyone builds servers the same way.

Our Architecture

Here’s how we structure CLI-first agents:

# Agent Definition (agents/code-reviewer.md)

## Role
Review code changes and suggest improvements.

## Tools Available
- git (version control operations)
- gh (GitHub CLI)
- rg (ripgrep for code search)
- jq (JSON processing)

## Workflow
1. Run `git diff` to see changes
2. Use `rg` to find related code
3. Analyze patterns and suggest improvements
4. Use `gh pr comment` to post review

## Constraints
- Read-only operations unless explicitly approved
- No force pushes
- No credential access

The agent is just a prompt file. The tools are standard CLI utilities. No servers, no protocols.

Real Performance Comparison

We benchmarked identical tasks with both approaches:

Task	CLI-First	MCP Server
Query database	45ms	180ms
Git operations	30ms	150ms
File search	20ms	90ms
API call	100ms	200ms

Why the difference?

• No server startup overhead
• No protocol serialization
• Direct execution path

For agents that run hundreds of tool calls, this adds up.

The Hybrid Approach

We’re not MCP-free. Our actual setup:

Tool Type	Approach
Shell utilities	CLI direct
Databases	CLI (psql, mysql)
Git/GitHub	CLI (git, gh)
Complex APIs	MCP server
Stateful services	MCP server

Rule of thumb: If a good CLI exists, use it. Build MCP servers only for what CLIs can’t do.

Migration Path

If you’re using MCP and want to simplify:

Step 1: Audit Your Tools

List every MCP server you’re running. For each one, ask:

• Is there a CLI equivalent?
• Does this need persistent state?
• How often is it called?

Step 2: Replace Low-Hanging Fruit

Start with stateless tools that have CLI equivalents:

• Git MCP → git CLI
• GitHub MCP → gh CLI
• Filesystem MCP → ls, cat, find

Step 3: Measure

Compare:

• Latency per operation
• Debug time when things fail
• Operational overhead

Step 4: Decide What Stays

Some MCP servers earn their keep. Keep those. Remove the rest.

Common Objections

”But MCP is the standard!”

Standards matter for interoperability. If you’re building tools for others to consume, MCP makes sense. If you’re building agents for your own use, simplicity wins.

”CLI isn’t secure!”

Neither is MCP by default. Both need sandboxing and permission controls. We use the same security model regardless of approach.

”What about complex operations?”

Write shell scripts. They’re version-controlled, testable, and your AI can read and understand them.

#!/bin/bash
# deploy.sh - Deploy to production
set -e
npm test
npm run build
aws s3 sync dist/ s3://my-bucket
aws cloudfront create-invalidation --distribution-id XXX

”My AI can’t write good shell commands”

Modern LLMs are excellent at shell commands. Claude, GPT-4, and others have seen millions of examples. They often write better shell than junior developers.

The Bottom Line

MCP is good technology solving real problems. But it’s not always the right choice.

For most AI agent use cases:

• CLI-first is simpler
• CLI-first is faster
• CLI-first is more debuggable
• CLI-first is more portable

Start simple. Add complexity only when you’ve proven you need it.

---

Building AI agents? Check our CLI architecture guide or contact us to discuss your approach.