The Model Context Protocol, published by Anthropic as an open standard in November 2024, solved a real problem: before MCP, every AI agent that needed to talk to every external tool required its own custom integration - an MxN problem that scaled badly as both the number of agents and the number of tools grew. MCP collapsed that into a single interface. Any MCP-compatible agent connects to any MCP-compatible server, and the agent gets a structured way to discover and invoke tools without needing to know in advance how each one works.

What MCP didn't solve - and was never designed to solve - is execution. And a specific, practical pattern has emerged across 2026 as teams have built real production agent integrations: the most robust ones build a command-line interface first, and treat MCP as a thin dispatch layer wrapped around it, not as a replacement for it. This post covers why that pattern won out, what each layer is actually good for, and how to decide which one your own agent integration needs.

What MCP Actually Solves

MCP sits above the API layer. When an agent invokes a tool through MCP, the MCP server translates that call into requests against the underlying REST or GraphQL API, handling authentication, input validation, and response shaping before the result ever reaches the model. The value is standardization: instead of a model needing bespoke training or prompt engineering for every individual tool's quirks, MCP gives it one consistent pattern for discovering what's available and invoking it with structured, typed input and output.

This matters most in exactly the situation MCP was designed for: connecting a general-purpose agent to a heterogeneous set of tools it wasn't specifically trained on, in an environment where governance, multi-tenant access control, and OAuth-based delegated authentication genuinely matter - the kind of enterprise, cloud-connected deployment where a model needs to reliably discover capabilities at runtime rather than have them hardcoded.

Where MCP Alone Falls Short

The operational reality of running MCP at scale has surfaced real friction. Different AI systems support different versions of the protocol, creating fragmentation an integration has to account for. MCP servers frequently need to maintain state between calls, manage authentication tokens, and handle sessions - meaningful operational complexity layered on top of whatever the underlying API already required. And every MCP server is, in practice, a new piece of infrastructure someone has to build, deploy, monitor, and keep current as the underlying API evolves.

Command-line interfaces, by contrast, already exist for virtually every service developers use, and they're maintained by the service providers themselves - which means they stay current with API changes without a separate integration team keeping a custom MCP server in sync. When an agent needs to interact with GitHub, it doesn't strictly need a custom-built MCP server; the gh CLI already does the job, is already maintained, and is already documented.

The CLI-First Pattern: Build the CLI, Wrap It in MCP

The most practically useful framing to emerge from this debate treats a CLI as the more foundational surface to build first when planning agent integrations. A CLI wraps API endpoints into named terminal commands, handling argument parsing, authentication, request construction, and output formatting so both human developers and, later, agents can invoke operations without writing raw HTTP client code. Once that CLI exists, an MCP server can be built on top of it, exposing the same commands as tools an agent can invoke at runtime - the CLI handles execution, and the MCP layer adds the structured, discoverable dispatch interface the agent reads to decide what to call and in what order.

This sequencing matters for a reason beyond convenience: a CLI is inherently human-legible in a way a raw MCP tool schema isn't. Engineers can run the same commands an agent runs, read the same output, and debug the same failures - which makes the CLI the natural place to validate that an integration actually works correctly before wrapping it in a layer designed for a model to consume autonomously.

What CLIs Give Agents That MCP Alone Doesn't

What MCP Gives That a Bare CLI Doesn't

None of this makes MCP redundant - it makes MCP's actual value proposition clearer once it's not being asked to do a CLI's job too. A raw CLI's output is designed for human eyes: formatted text, meant to be read, not strictly typed data meant to be passed programmatically between systems. The shift from CLI to MCP is fundamentally a shift from parsing raw strings to passing strictly typed, structured state - which matters enormously once an agent needs to compose the output of one tool call directly into the input of another without a fragile string-parsing step in between.

The Dual-Interface Pattern Emerging in 2026

The clearest signal of where this settles is what vendors have actually been shipping. Major platforms have moved on both fronts simultaneously rather than picking one: GitHub launched a fully hosted remote MCP server for agent access to repositories, issues, and pull requests, while the gh CLI it's built alongside remains actively maintained for the same operations. Google's Workspace CLI describes itself explicitly as built for both humans and AI agents, shipping with dedicated agent-facing skills documentation. A database vendor's "agent-ready" CLI made the case directly that a database CLI, not a bolted-on MCP wrapper, is what actually enables reliable AI-driven cluster operations. And at least one major platform has taken this further still, having agents write code against a sandboxed, discoverable interface rather than loading either a CLI or a full MCP tool schema - a signal that the underlying idea (self-documenting, progressively discoverable capability surfaces) matters more than which specific transport delivers it.

CLI vs MCP vs Both: A Practical Decision Table

Numlytics' AI and machine learning consulting practice integrates LLMs and AI agents into existing enterprise applications and workflows - including designing the CLI and MCP layers that make those integrations reliable, governed, and auditable in production, not just in a prototype. Speak with a certified consultant about the tooling architecture your agent integration actually needs.