MCP vs CLI Tools: Why Security Changes the Answer

In late February 2026, a post titled “MCP is dead. Long live the CLI” hit the Hacker News front page and generated significant traction. The argument was blunt: LLMs are now smart enough that you can hand them a shell and CLI documentation, skip the MCP abstraction layer entirely, and get better token efficiency with simpler debugging. Perplexity’s CTO said the company was deprioritizing MCP internally. YC’s Garry Tan said he built a CLI replacement in 30 minutes. The narrative positioned MCP as over-engineered, CLI is simpler, and Skills as killing the whole thing.

The token efficiency argument has real data behind it. Benchmarks have shown that CLI tools consume fewer tokens than unfiltered MCP server use; but, the MCP-is-dead conclusion misses the most important variable in the comparison: what happens to credentials.

When a developer gives an agent CLI access, the agent inherits that developer’s credentials. Those credentials are present in environment variables, in configuration files, in the shell’s process environment, on the machine where inference happens, or proxied to wherever inference runs. The agent uses them and the model processes requests that include them. In a solo developer workflow where you are the only person at risk, this is an acceptable tradeoff. In an enterprise environment where agents act on behalf of other people it is a fundamentally different threat model.

MCP solves this problem. The right comparison is not CLI vs. MCP on token efficiency. It is CLI vs. MCP on the full production trade-off: token cost, credential surface, real-time context, auditability, and multi-user governance. Security changes the answer.

---

The Three-Way Comparison: CLI, Agent Skills, and MCP

Before evaluating trade-offs, it helps to be precise about what each approach actually is. The debate conflates three distinct architectural choices that solve different problems at different layers.

CLI tools give agents direct access to command-line interfaces such as git, docker, gh, kubectl, aws, and so on. The agent generates shell commands, executes them, and reads stdout. The advantage: most major CLIs are represented extensively in model training data, so the agent can invoke them without loading schema definitions into context. A git --help call costs ~80 tokens. The equivalent MCP tool definitions cost thousands. CLI credentials are whatever the invoking user’s session has access to.

Agent Skills (introduced by Anthropic in November 2025 and adopted with variations across frameworks) are structured Markdown files defining standard operating procedures (i.e. what to do first, what to check, how to handle failures, when to escalate). Skills load minimal metadata at session start (a name and one-line trigger condition) and expand to full content only when the agent determines the Skill is relevant. This is progressive disclosure at the knowledge layer, not the tool layer. Skills teach an agent how to do something; they do not themselves provide access to systems.

MCP servers provide structured, schema-typed access to tools and data sources through a standardized protocol. Every tool invocation is a typed JSON-RPC call with validated parameters. The MCP server, not the agent’s host environment, holds the credentials for the downstream systems it connects to. This is the architectural property that changes the security calculation.

These three approaches are not mutually exclusive. The most common production architecture combines all three: Skills for workflow knowledge, CLI for local developer tools where credential sharing is acceptable, and MCP for remote services and multi-user scenarios where credential abstraction is required.

---

Where CLI Genuinely Wins: Token Efficiency and Developer Workflows

The token efficiency advantage of CLI over naive MCP is real and well-documented. Understanding where it applies and where it does not is the starting point for making a correct architectural decision.

CLI wins on token cost for local, familiar tools. A Scalekit benchmark found that CLI costs approximately $3.20 per 10,000 operations for GitHub tasks, versus $55.20 for MCP, which is a 17x cost difference. The root cause is schema injection: MCP loads all tool definitions at session start regardless of whether those tools will be used. Five MCP servers with 20 tools each injects approximately 80,000 tokens of schema before any task begins.

CLI wins on simplicity for single-developer workflows. When one developer is the only user, the agent acts as that developer, inheriting their credentials, their access, their permissions. There is no multi-user access control problem to solve. The blast radius of a mistake is bounded by that developer’s own access. In this context, the MCP abstraction layer adds complexity without commensurate benefit.

CLI wins on debugging transparency. Shell commands are observable. git clone git@github.com:org/repo.git is a complete, reproducible, human-readable invocation. An MCP tool call to clone_repository with a JSON parameter object is not. For development workflows where rapid iteration and manual verification matter, CLI’s transparency is a real advantage.

All of these CLI advantages assume the agent is acting on behalf of a single user whose credentials it legitimately inherits. When that assumption breaks, the entire CLI security model breaks with it.

---

Where MCP Wins: The Credential Surface Problem

The security argument for MCP is not complicated, but it is almost universally underdiscussed in the CLI-vs-MCP debate. Here it is stated precisely:

When an agent uses CLI tools, the credentials for downstream systems are present in the environment where the agent executes. In a pure CLI architecture, the agent inherits whatever credentials the invoking user or service account holds, including AWS keys, GitHub tokens, database passwords, API credentials , and in the environment where the shell runs. If the agent runs locally on a developer’s machine, those are the developer’s credentials. If the agent runs in a CI/CD pipeline or a cloud function, those are the pipeline’s credentials. In either case, the credentials are present in the execution environment, accessible to any code that runs there.

This matters because of where inference happens. In a managed AI service (e.g. Claude via the API, GPT via the OpenAI API, Gemini via Google’s API) the model processes requests on vendor infrastructure. In a CLI-based agent architecture, the agent’s tool execution and credential access happen on your infrastructure, but the model’s reasoning about what commands to run involves sending context (which may include tool outputs containing sensitive data) to the inference endpoint. The credentials themselves may not transit the inference endpoint, but the outputs of credential-authorized operations (file contents, database query results, API responses) do.

MCP inverts this model. The MCP server runs on your infrastructure, holds the credentials for downstream systems, and exposes typed tool interfaces to the agent. The agent calls list_repositories via the MCP protocol. The MCP server authenticates to GitHub with its stored credential, retrieves the list, and returns the result. The GitHub credential never appears in the agent’s context window, never transits the inference endpoint, and is not present in the agent’s execution environment. It lives in the MCP server’s credential store, behind an authentication layer, with audit logging on every use.

This is not a theoretical distinction. Consider the difference in these two architectures for an agent accessing a production database:

CLI approach: The agent executes psql -h db.prod.example.com -U app_user -d production -c "SELECT * FROM users WHERE id = 123". The database password is in PGPASSWORD environment variable or a .pgpass file on the host. The connection string including host, user, and database appears in the process environment and potentially in the shell history and logs.

MCP approach: The agent calls the query_user MCP tool with {"user_id": 123}. The MCP server holds the database credentials, validates the query against a schema, executes it with a least-privilege service account, and returns the result. The connection string and password are in the MCP server’s secrets store. The agent never sees them.

The security gap between these two architectures is not a matter of degree. It is architectural. MCP server-side credential management is what enables enterprises to use agents in production without placing credentials in agent execution environments.

---

The Enterprise Multi-User Boundary

The single clearest signal for which architecture is appropriate is whether the agent acts on behalf of one person or many.

A solo developer using Claude Code to interact with their own GitHub repositories, their own Kubernetes context, their own local files: CLI is appropriate. The agent inherits the developer’s credentials, acts with the developer’s permissions, and the developer is the only person at risk.

An enterprise deploying an agent that acts on behalf of customers, or on behalf of employees accessing shared systems, or on behalf of any identity other than the single person who built the agent: the CLI credential model fails at the first user boundary it crosses.

The failure mode is specific. In a multi-user CLI-based agent deployment, either all users share a single set of credentials (a service account with over-broad permissions, no per-user attribution, no revocability at the individual level), or the credential management problem devolves into a custom per-user credential injection system that is operationally more complex than MCP and less secure because it lacks the protocol-level authentication and audit trail that MCP provides.

MCP’s OAuth 2.1 requirement for remote servers, which is mandatory in the March 2025 specification update, is designed precisely for this boundary. Per-user OAuth means each user grants scoped access independently. Each user’s access is revocable without affecting other users. Each tool invocation is attributable to the individual who authorized it. The audit trail records not “the agent called the Jira tool” but “Alice’s agent, acting on her behalf, called the create_issue tool with these parameters.”

This is not an edge case for enterprise deployments. It is the baseline governance requirement that compliance frameworks, audit functions, and data residency policies impose. An agent that cannot produce a per-user attributable audit trail for its tool invocations is not deployable in regulated environments.

---

Token Efficiency: MCP’s Real Answer to Schema Bloat

The token efficiency objection to MCP is legitimate, but the gap is closing rapidly and has already closed significantly for platforms that implement progressive disclosure.

The root cause of MCP’s token cost is eager loading: the protocol’s original design loads all tool definitions at session start, regardless of which tools the current task requires. For example, GitHub’s MCP server with 43 tools injects 17,600 tokens of schema before the agent begins.

Several converging approaches address this:

On-demand tool discovery serves tool definitions only when a tool is invoked, not at session start. Stacklok’s MCP Optimizer, embedded in its offering as of March 2026, implements hybrid semantic and keyword search to surface the most relevant tools on demand. In testing, this approach reduces per-request token consumption by 60–85% compared to eager loading. The agent sees only the tools relevant to its current task.

Anthropic’s Tool Search (shipped late 2025) achieves up to 85% token reduction compared to standard MCP loading, according to Anthropic’s own benchmarks, by deferring schema injection to the moment of tool selection.

Progressive disclosure at the MCP server level, loading only metadata (name, one-line description) at initialization and expanding to full schema only on demand, closes most of the raw token cost gap between CLI and MCP for typical task distributions.

The token efficiency objection to MCP is a valid objection to eagerly-loaded MCP without progressive disclosure. It is not a valid objection to MCP as a protocol. An MCP server with on-demand tool discovery and a gateway-level optimizer is not multiples more expensive than CLI on token cost. The gap narrows considerably and the credential security architecture remains intact regardless of which token optimization approach is used.

---

Agent Skills: The Third Axis

Agent Skills are not a replacement for either CLI or MCP. They operate on a different axis entirely: they encode procedural knowledge.

A Skill might define the standard operating procedure for creating a pull request: check branch name, verify CI has passed, review the diff for credentials before submitting, notify the team lead. The Skill does not itself provide access to GitHub. It tells the agent what steps to take, in what order, and how to handle common failure modes. The actual system access comes from whichever tool layer sits beneath the Skill: CLI, MCP, or a combination.

The most common misreading of the CLI vs MCP debate is treating Skills as a third competitor in the same category. Skills and MCP are complementary. A Skill that encodes the PR creation procedure can invoke an MCP server for GitHub access with per-user OAuth credentials, or it can invoke CLI gh commands that inherit the developer’s session. Which tool layer is appropriate depends on the credential surface analysis above.

Adopting Agent Skills does not resolve the credential architecture question. A Skills-based workflow that calls CLI tools under the hood still places credentials in the execution environment. A Skills-based workflow that calls MCP tools inherits MCP’s credential abstraction. The architectural choice matters at the tool layer, not the knowledge layer.

---

Decision Matrix: Which Architecture Fits Your Use Case

Scenario	Recommended Architecture	Primary Reason
Solo developer automating their own workflow with local tools (git, docker, kubectl)	CLI + Skills	Credential inheritance is acceptable; token efficiency advantage is real; no multi-user boundary
Small team sharing a coding agent for internal development tasks, all members trust each other’s credential access	CLI + Skills	Acceptable credential model; low governance overhead justified by team size
Internal enterprise agent serving multiple employees accessing shared systems (Jira, Confluence, internal APIs)	MCP	Per-user OAuth required; audit attribution required; credential abstraction required
SaaS product embedding an agent that acts on behalf of customers	MCP	Per-customer OAuth mandatory; credential isolation between customers is non-negotiable
Agent accessing regulated data (financial records, health data, PII) on behalf of any user	MCP	Compliance frameworks require per-user attributable audit trails; CLI credential model cannot satisfy this
High-volume pipeline processing homogeneous tasks with a single service identity, no per-user attribution required	CLI or MCP with service credentials	No multi-user boundary; token cost matters more than per-user attribution
Agent accessing cloud APIs (AWS, GCP, Azure) without user-specific permission scoping	CLI with workload identity	Cloud workload identity (IRSA, GKE Workload Identity) provides acceptable credential management without MCP overhead
Enterprise coding agent governance (Cursor, Claude Code) across developer teams	MCP with gateway	Centralized policy enforcement, per-developer identity, audit logging require MCP architecture

---

What Stacklok Adds to the MCP Side of This Comparison

The legitimate objections to MCP in the CLI debate are objections to naive MCP deployments without a governance layer. Stacklok’s Kubernetes Operator addresses each of them specifically.

Token cost: The MCP Optimizer embedded in Stacklok’s vMCP (as of March 2026) reduces per-request token consumption by 60–85% through on-demand tool discovery. Platform teams deploy it once; every agent connected through vMCP benefits without per-agent configuration.

Authentication complexity: Stacklok’s embedded authorization server handles the full OAuth 2.1 flow in-process against Okta, Entra ID, or Google without requiring each MCP server to implement its own auth layer. A governance layer that handles auth centrally eliminates that per-server burden.

Credential surface management: Stacklok runs every MCP server in an isolated container with configurable network access and filesystem permissions. Credentials for downstream systems live in the MCP server’s secrets store, not in agent execution environments or shell process environments.

Audit attribution: Stacklok’s embedded authorization server issues per-user tokens for every tool invocation. That includes OTel, which produces audit traces that record the authenticated principal, the tool invoked, and the parameters in formats compatible with Grafana, Datadog, Splunk, and New Relic without a custom integration layer.

The Stacklok approach does not eliminate the cases where CLI is the correct answer. For a solo developer running local tools, CLI with Skills is still simpler and cheaper. Stacklok is the correct answer when the credential architecture, multi-user governance, and audit requirements that MCP is designed to satisfy are the requirements that actually apply.

---

Frequently Asked Questions

Q: What exactly is the credential surface problem with CLI-based agents?

In a CLI-based agent architecture, the agent executes shell commands using credentials present in its execution environment. Those credentials — AWS keys, GitHub tokens, database passwords — are accessible to any code running in that environment and may appear in tool outputs that transit the inference endpoint. An MCP server inverts this: credentials live server-side in a secrets store, the agent authenticates via OAuth and receives scoped tokens, and downstream system credentials never appear in the agent’s context. For solo developers, this distinction is often acceptable. For multi-user enterprise deployments acting on behalf of others, it is not.

Q: What are Agent Skills and do they replace MCP?

Agent Skills are structured Markdown files encoding standard operating procedures — what to do first, what to check, how to handle failures. They operate at the knowledge layer: teaching an agent how to do something. They do not provide access to systems. Skills are complementary to both CLI and MCP, not a replacement for either. A Skills-based workflow still requires a tool layer beneath it, and the choice between CLI and MCP at that layer depends on the credential surface and multi-user governance analysis described in this post.

Q: How does ToolHive’s MCP Optimizer address the token cost objection?

ToolHive’s MCP Optimizer, embedded in vMCP as of March 2026, implements on-demand tool discovery using hybrid semantic and keyword search. Instead of loading all tool definitions at session start, the optimizer surfaces the most relevant tools at request time — returning up to 8 tools by default. This reduces per-request token consumption by 60–85% compared to eager loading, closing most of the raw token cost gap between CLI and MCP. The optimizer deploys once at the platform level; every agent connected through vMCP benefits without per-server configuration.

Q: When should I use CLI instead of MCP, even in an enterprise environment?

CLI is appropriate in enterprise environments for local developer tools where credential inheritance from the developer’s session is acceptable and auditable — git for code operations, kubectl for Kubernetes interactions where the developer’s kubeconfig is the intended credential, docker for local container operations. The test is whether the agent is acting as the developer (CLI acceptable) or on behalf of other people (MCP required). For coding agent governance at enterprise scale — managing Cursor and Claude Code across teams with centralized policy enforcement — MCP with a governance layer is required regardless of the individual tool efficiency argument.

---