MCP or CLI for AI Agents? What the Evidence Actually Supports

A paper comparing command-line access with the Model Context Protocol (MCP) reports that CLI is more efficient for single-user, local-only workflows, while MCP addresses governance needs and is part of the paper’s recommended hybrid architecture for production systems ¹. The source excerpt available here is the paper’s abstract; it does not show the underlying procedures, datasets, or modeling assumptions. Treat its conclusions as a starting point for architecture decisions, not as a reproducible benchmark ¹.

The distinction isn't cosmetic. CLI and MCP are different control surfaces: one lets an agent execute shell commands, while the other provides structured, typed tool access through JSON-RPC ¹. That choice can affect how a team approaches permissions, credentials, audit trails, and integration work.

MCP vs CLI for AI agents: what the paper compares

The paper compares direct shell-command execution with MCP, which it describes as a structured JSON-RPC protocol for governed, typed tool access ¹. Its abstract says agents may use interfaces to interact with files, APIs, databases, and cloud services ¹.

As an illustration, not an example from the paper, the CLI approach centers on commands an agent constructs and runs, while the MCP approach centers on declared tools and their parameters. That distinction alone does not establish which design is safer. In practice, the relevant questions include what the tool can reach, what checks apply before execution, and which identity is used. These are architectural considerations, not findings reported in the abstract.

The paper says its analysis covers 14 evaluation dimensions and includes worked examples, a security assessment against established compliance frameworks, and economic modeling ¹. The abstract does not provide the test procedures, datasets, or modeling assumptions, which limits what can be verified from this excerpt ¹. The useful question isn't simply which interface wins; it's which control surface fits a workflow, and what evidence supports that choice.

When an agent command line interface is the simpler choice

The paper’s reported finding is that CLI is more efficient for single-user, local-only workflows ¹. One possible explanation, not a reported result, is that a shell can expose an existing local toolchain without first requiring a team to define a catalog of typed tools.

That may fit a developer agent working with local files on a bounded task that a human can review. A team could start with a narrow set of actions, such as listing files or running a local formatter, and limit what the agent can reach through its execution environment. Those are suggested design choices, not results from the paper.

Giving an agent shell access also raises policy questions: which commands are allowed, how arguments are validated, which files and network destinations are reachable, and how credentials are kept out of agent-visible input. These are design implications, not measured results in the abstract.

Don't extend the paper's efficiency finding to shared production systems. The abstract reports a finding for single-user, local-only workflows; it does not report CLI performance across multiple users, remote services, or workflows requiring centralized governance ¹. If your use case differs, evaluate it directly.

MCP tool security: what it adds for permissions and audit

The abstract credits MCP with fine-grained access control, credential isolation, structured audit, and multi-tenant governance, and says CLI fundamentally cannot satisfy those requirements ¹. Those claims make useful questions for an implementation review:

• Can the platform restrict individual tools or specific parameters?
• Can credentials stay outside the agent's context?
• Can operators see which tool was called, and under which identity?
• Can separate tenants receive separate access policies?

These are evaluation questions, not guaranteed features of every MCP implementation. A structured interface may make operations and parameters easier to define and review, but the protocol alone does not settle authorization, credential handling, or audit quality. Those depend on the implementation around it. Teams that also centralize model access behind an enterprise AI gateway will want to decide which layer enforces which control, so that tool-level and model-level policies don't overlap or leave gaps.

The paper's claim that CLI cannot satisfy these governance requirements deserves scrutiny before it shapes a security design. The abstract does not explain which CLI configurations were assessed or how it defines that limitation ¹. Review the paper's definitions of CLI and its governance claims. A restricted command runner and an unrestricted shell are different designs; the abstract does not say which was evaluated.

What to measure before you commit to an AI agent tool integration

CLI may have a low integration cost when a useful command-line tool already exists. But a team still needs to decide how to constrain commands, validate arguments, isolate credentials, capture actions worth auditing, and keep wrappers aligned with the underlying tools. Connecting quickly does not necessarily mean hardening quickly; that is an operational consideration, not a finding reported in the abstract.

MCP shifts the work toward defining tools and input schemas, implementing policy checks, and assigning ownership for the tool server's lifecycle. That is a practical implication of structured tool access, not a quantified setup or maintenance result in the abstract ¹.

The paper mentions economic modeling, but its abstract provides no inputs, assumptions, or results that would support a cost comparison for a particular stack ¹. Teams can measure their own:

• Time to add a tool and change its interface.
• Effort to review and update access policies.
• Rate of invalid arguments or failed calls.
• Whether audit records let an operator reconstruct what happened.
• Work required to update integrations when an underlying tool changes.

These measures won't produce a universal ranking. They can help show where each approach places work for the team responsible for operating it.

Does MCP cost more tokens than CLI?

The paper identifies context-window overhead as a historical weakness of structured tool descriptions and says progressive disclosure can bring MCP token efficiency to a level comparable to CLI while preserving its architectural benefits ¹. The abstract does not provide measurements or assumptions for that comparison, so treat it as a claim to investigate rather than a result to assume for your own workload.

If you test it, also look at related approaches to keeping context lean, such as retrieving skills instead of loading a whole library, and measure token use on your own tasks.

A practical takeaway

The paper’s abstract supports a limited conclusion: CLI is reported as more efficient for single-user, local-only workflows, while MCP is presented as addressing governance requirements and as part of a hybrid recommendation for production systems ¹. It does not provide enough detail to independently validate the evaluation or apply its economic conclusions to a particular deployment. Use the findings to frame your evaluation, then test the security, operating effort, and token use of the setup you intend to run.