"MCP is just a CLI wrapper. It's unnecessary."
This extreme take has been making the rounds on X (formerly Twitter), with some developers going as far as declaring "MCP should die." They cite CLI's ease of human debugging and flexibility, arguing that MCP is nothing more than over-engineering.
Let's be direct: this argument ignores the fundamental difference between MCP and CLI.
MCP is not a CLI wrapper. CLI follows a stateless execution model — call once, get a response, done. MCP is a stateful protocol that maintains connections and orchestrates multiple operations over time. These are architecturally different by design. The right question isn't "which is better" but "which is appropriate for the task at hand."
When CLI Makes Sense
CLI and API wrappers are well-suited for single request/response operations:
- File conversion and formatting
- Single API calls and their responses
- Idempotent operations (same input always produces the same output)
These tasks require no state persistence. One command execution completes the entire input-to-output cycle. The overhead is minimal, and debugging is straightforward for humans. CLI's strength in this space is undeniable.
Where MCP Shines
MCP excels where state persistence is the key requirement:
- Persistent connection management: Maintaining database sessions, SSH connections, or other costly-to-establish connections across multiple operations
- Multi-step workflows with context: Sequential operations where each step depends on the results of the previous one
- Real-time bidirectional updates: Scenarios requiring notifications or streaming updates from the tool side
For simple request/response, CLI wins. But MCP's value lies in being a stateful orchestration layer.
Real-World CLI Limitation: Database Connection Latency
sqlew is an MCP tool for AI coding assistance that stores design decisions and constraints in a database, enabling AI agents to retrieve them just-in-time.
During early development, we experimented with a CLI implementation. However, with CLI, a new process spins up and terminates with every tool call — meaning a fresh database connection is established each time. This connection overhead alone added approximately 1 second of latency per call.
AI agents invoke sqlew tools dozens of times per session. With 50 tool calls, the connection overhead alone would total roughly 50 seconds — a noticeable drag on user experience.
With MCP, the server process stays resident and maintains the database connection across multiple tool calls. The connection cost is paid only once, at startup.
| Approach | Connection Timing | Overhead for 50 Calls |
|---|---|---|
| CLI | Connect/disconnect every call | ~50 seconds (1s × 50) |
| MCP | Connect once at startup | ~1 second (initial only) |
Not "MCP or CLI" — But "When to Use Which"
Whether MCP is necessary depends on the nature of the task.
For stateless operations, CLI is the rational choice. But where database connection persistence, cross-session context management, or multi-step sequential processing are involved, MCP holds a structural advantage.
It's not a binary choice between MCP and CLI — it's about matching the tool to the task. sqlew adopts MCP because the nature of accumulating and retrieving design intent demands a stateful connection.
