MCP vs CLI vs Skills — Let’s get a better understanding

Photo by yousef samuil on Unsplash

MCP is a universal adapter. Instead of writing a custom connector for every AI-to-tool combination, MCP gives every service a standardised socket and every AI a standardised plug. The downside: the server loads its full menu of tools into the AI’s memory upfront, whether needed or not — which may get expensive.

CLI is a direct line to the terminal. The AI already knows tools like gh, aws, and kubectl from its training data — the same way a senior developer does. So it just types the command, the shell runs it locally, and structured output comes back. No server, no schema dump, no network timeout. Roughly 200 tokens of work versus 40,000+ for MCP.

Skills are markdown recipe cards for your AI agent. A Skill file (SKILL.md) sits quietly in the background costing ~30 tokens while idle. When the AI recognizes a matching task, it loads the full recipe (~800 tokens) which tells it exactly what to do — which tool, which flags, how to handle errors, what "done" looks like — and then routes the job to either CLI or MCP depending on what fits. Skills don't replace CLI or MCP; they sit above both and make them smarter and more consistent.

One-line version of each

Is CLI a replacement for MCP?

To answer your first question directly: no, CLI is not “taking over” from MCP. But it is winning on specific metrics badly enough that the community is loudly questioning MCP’s dominance. Here’s the full picture.

Why CLI Suddenly Has Everyone’s Attention

The debate kicked off in earnest around February 2026. A typical MCP server doesn’t just expose the tools you need — it dumps an entire schema into your agent’s context window: tool definitions, parameter descriptions, authentication flows, state management, the whole package. Stack multiple MCP servers and a typical enterprise agent might need GitHub, a database connector, Microsoft Graph, and Jira. You’re easily looking at 150,000+ tokens of tool definitions alone.

By contrast, the model already knows gh. Zero schema tokens consumed. The entire interaction — command plus output — might cost 200 tokens.

The benchmarks are stark. For the simplest task — “what language is this repo?” — the CLI agent needs 1,365 tokens. The MCP agent needs 44,026. The difference is almost entirely schema: 43 tool definitions injected into every conversation, of which the agent uses one or two. Scalekit

In cost terms: monthly cost at 10,000 operations: CLI costs about $3.20 vs MCP about $55.20. Firecrawl

There’s also a reliability angle. Every failure in MCP was a TCP-level timeout — the connection to GitHub’s Copilot MCP server never completed. CLI agents don’t have this problem. gh runs locally. There's no remote server to time out. Scalekit

And a composability argument: MCP currently has no native chaining mechanism. The efforts to add composability are designing in 2025–2026 what Unix figured out in the 1970s and spent fifty years debugging. LLMs have been trained on millions of examples of Unix pipe chains. The model doesn’t just know the tools exist — it knows the patterns. MCP composition patterns have zero training data. Substack

But MCP Isn’t Dead — The Security Argument Is Real

An AI agent with unrestricted CLI access to enterprise systems is not a productivity tool. It is a security incident waiting to be documented. MCP exists, in large part, to solve exactly this problem.

MCP provides authentication, audit logging, and permission scoping that raw CLI execution doesn’t. A customer support agent handling sensitive data needs those guardrails. MCP also solves a real discovery problem — an agent connecting to an MCP server learns what tools are available and how to use them automatically. With CLI tools, someone has to pre-configure which commands the agent can run. AI:PRODUCTIVITY

The adoption numbers also show MCP isn’t going anywhere. From roughly 100 public MCP servers at launch in November 2024, the ecosystem grew to over 10,000 published servers by December 2025, with 97 million monthly SDK downloads. In December 2025, Anthropic donated MCP to the Linux Foundation’s newly formed Agentic AI Foundation, co-founded with Block and OpenAI, cementing it as a neutral open standard. Medium

The emerging consensus: use CLI for developer workflows where token efficiency matters; use MCP for customer-facing and compliance-sensitive features. The smartest architectures in 2026 are doing both, not picking sides.

Now the Bigger Story: Why Skills Beat Both

This is where it gets genuinely interesting. Skills are Markdown files that act as lightweight “cheat sheets” for agents — and they’re quietly making both CLI-vs-MCP arguments look like the wrong question.

The Skills Camp: A Markdown file acts as a “cheat sheet,” teaching the Agent which tool to use in which situation. It sits idle at around 30 tokens and only loads the full instructions when triggered.

Simon Willison, a prominent developer in the Python community, called Skills “maybe a bigger deal than MCP” when it launched.

The benchmark evidence is compelling. An 800-token skills file with gh tips actually outperformed 28,000 tokens of MCP schemas. The agent using the skills file made fewer tool calls and finished faster. The 800-token skills file reduced CLI latency by 33%.

What makes this powerful is that Skills are transport-agnostic. Tools, MCP, and Skills form a layered architecture: Skills define the workflow and quality bar, MCP provides standardized access to external services, and Tools execute individual actions. A typical flow: a Skill triggers, loads its instructions, connects via MCP to external data, executes Tools for each step, then validates the output.

In other words, a Skill can sit on top of either CLI or MCP.

Armin Ronacher (creator of Flask) fully migrated from MCP to Skills and explained: “Skills are essentially just a short summary that tells the Agent what capabilities exist and where to find more details. The key thing is — Skills don’t inject any tool definitions into the context. The tools are still the same tools: bash and whatever the Agent already has.”

A concrete example of Skills in production: a venture capitalist is running his entire company on twelve Markdown files. No web application. No workflow engine. No orchestration runtime. Just structured documents in a git repo that teach Claude Code how to draft emails, triage support tickets, prepare board metrics, and manage product launches.

Skills are now an emerging open standard. skill.md is a markdown file that lives alongside your documentation, describing how best agents should use your product. Skill files can be installed into 20+ major coding agents. Mintlify The ecosystem is substantial: the awesome-agent-skills repository includes official skills from Google, Figma, Notion, OpenAI, and Anthropic, compatible with Claude Code, Gemini CLI, Cursor, and more. GitHub

You can see this architecture in production today. Claude Code and Cowork use both CLI and MCP as transport layers, unified behind a higher-level abstraction called Skills. Claude Code runs shell commands, pipes data through grep and jq, and chains Unix tools for local work. It also connects to MCP servers for SaaS integrations. In both cases, the agent calls a Skill, and the Skill routes to the appropriate transport — these products resolved the debate internally that the community is still having publicly.

The short version: CLI didn’t kill MCP. Skills are making the fight between them less important than people think.

Clear side by Side on each of these work

The core difference is what hits the context window before any real work happens. MCP injects a full schema upfront — every tool definition whether you need it or not, totalling 32k–82k tokens for a typical server with 40+ tools. CLI generates a shell command from training data the model already knows, costing ~200 tokens total. Skills sit idle at ~30 tokens and only load their full SKILL.md (~800 tokens) when a matching task is detected — and they never inject tool schemas at all.

Enterprise perspective

The cleanest mental model is three layers:

The CLI zone owns developer and internal tooling — git, gh, aws, kubectl, terraform, jq. These tools have mature CLIs, the model already knows them from training, they run locally with no network timeouts, and they compose via Unix pipes. At 10k operations a month, CLI costs $3.20 versus MCP’s $55.20 for equivalent GitHub tasks.

The MCP zone owns customer-facing and compliance-sensitive integrations — Salesforce, Stripe, Slack, Figma, Supabase. These are cases where there’s no CLI, where you need per-user OAuth 2.1, revocable credentials, and a proper audit trail. An enterprise CISO will not allow unrestricted shell access to production CRM data — MCP exists precisely to solve that.

Skills sit above both and route between them. They encode the “how” of a task — which flags to use, what error handling to apply, when to ask for confirmation — while delegating the actual execution to whichever transport fits. A skill wrapping a GitHub workflow uses CLI; a skill wrapping a Salesforce workflow uses MCP. The agent never has to decide — the skill decides. This is exactly how Claude Code, Cowork, and OpenClaw are built in production, and it’s why the CLI-versus-MCP framing is ultimately the wrong fight.

Now that we have a decent understanding of these capabilities let’s take a use case and see how we’ll approach it with all 3 capabilities

Problem Statement: Check every S3 bucket in our AWS account. If any bucket is over 50 GB, send an alert

Approach1 — MCP

With MCP, the first thing that happens before any actual S3 work is the AWS MCP server dumps its entire tool catalogue into the AI’s context — every S3, CloudWatch, and IAM operation, whether you need it or not. That’s ~40,000 tokens consumed upfront just to say “here’s what I can do.” After that, the AI makes structured tool calls — list_buckets, then get_bucket_size once per bucket — and the MCP server handles the actual AWS API calls on its behalf. You get per-user OAuth and an audit trail, but it costs significantly more tokens and needs a running MCP server with proper credentials configured.

Approach2 — CLI

With CLI, the AI doesn’t need to be told what tools exist — it already knows aws s3api, aws cloudwatch, awk, xargs, and aws sns from training data, the same way a senior DevOps engineer would. So instead of loading a schema, it just composes a shell pipeline directly. One command lists all buckets, pipes into CloudWatch to get sizes, filters with awk for anything over 50 GB, and pipes the result into aws sns publish to fire the alert. The whole thing runs locally in a single pass, costs ~200 tokens, and needs no running server — just AWS CLI configured with the right credentials. The downside: if you're running this on behalf of other users in a multi-tenant product, you'd be using shared credentials, which doesn't scale safely to enterprise.

Approach 3 — Skills

With Skills, a tiny index (~30 tokens) sits idle and pattern-matches the incoming prompt against known skill names. When “S3” and “alert” match, it loads the full s3-alert/SKILL.md recipe (~800 tokens). That recipe is where the real value lives — it tells the AI the exact CloudWatch metric name to use (BucketSizeBytes), the correct byte conversion for 50 GB, which SNS command to fire, what to do if the command fails, and how to confirm the alert was delivered. It then routes to CLI to execute, because AWS has a mature CLI and doesn't need MCP. The result is the same ~200-token CLI execution as the pure CLI approach — but now it runs identically every single time, regardless of which AI agent runs it or how the user phrases the prompt. No guessing at flags, no inconsistency between runs.

Three approaches compare on this one task side by side:

The Skills approach essentially captures the expertise of a good CLI implementation and packages it so any agent — or any team member — gets the same result every time without having to know CloudWatch’s metric naming conventions by heart.

Mistake 1 — Using MCP when CLI would work fine

The moment you connect an AWS MCP server for a simple S3 task, it dumps 40,000–80,000 tokens of schema into the AI’s context before any actual work begins — every S3, CloudWatch, IAM, and EC2 tool definition, whether you need them or not. On a multi-step task this starves the AI of reasoning room. Benchmarks show agents losing track of earlier steps after just 3–4 tool calls once the context fills up. On top of that, MCP servers are remote processes — TCP timeouts and cold starts fail silently mid-task. And at scale, the cost difference is stark: MCP costs roughly $55/month at 10,000 operations versus CLI’s $3 for the equivalent GitHub tasks.

Indicators: Sense it early

• Token spike: if a simple list-filter-alert task consumes more than 10,000 input tokens, something is over-loaded. Set a monitoring alert at 5× your task’s expected baseline.
• Step amnesia: the agent references a previous tool call incorrectly or repeats a step it already completed. This is the classic sign the context window is too full for reliable attention.
• Latency creep: compare agent task time against a human typing the CLI equivalent. If the agent takes 3× longer for something grep handles in one second, the approach is wrong.

Course correction

For any tool with a mature vendor CLI — aws, gh, kubectl, terraform, docker — replace MCP with CLI + a Skill file. Start with your highest-token tasks first. Tools like MCPorter can auto-convert an MCP server into a CLI wrapper if you want to migrate gradually rather than rewriting all at once.

Mistake 2 — Using CLI when MCP is needed

CLI uses pre-configured shared credentials. In a multi-tenant product, every user’s agent acts as the same AWS identity — User A can inadvertently trigger actions affecting User B’s data. There is also no per-user audit trail: HIPAA, PCI-DSS, and SOC 2 require “who did what and when,” and raw CLI simply cannot answer that question. Then there’s the SaaS wall: roughly 60% of enterprise SaaS tools — Salesforce, Figma, Notion, Stripe — have no CLI at all. The agent will either hallucinate a command, use an undocumented curl endpoint that breaks on the next API version, or stall in a retry loop.

Indicators: Sense it early

• Cross-account data visibility: a user reports seeing resources that aren’t theirs. With shared credentials this is not a bug — it is the expected behaviour. Treat the first occurrence as a P1 signal requiring immediate architecture review.
• Compliance flags: “How do you isolate per-user agent actions?” If the answer is “we can’t — it’s all one IAM role,” your next PII/PCI/HIPAA/SOC 2/ISO audit will fail. Catch this before the auditor does.

Course correction

Introduce MCP specifically for customer-facing workflows, compliance-sensitive integrations, or any SaaS with no CLI. Keep CLI for internal infra automation. The hybrid pattern — CLI for dev and infra tooling, MCP for SaaS and multi-tenant scenarios — is exactly what Claude Code and Cowork use in production. You do not need to choose one universally; you need to choose correctly per integration.

Mistake 3 — Skipping Skills entirely (raw CLI or MCP with no Skill layer)

Without a Skill anchoring the workflow, the AI improvises on every run. The same S3 alert task phrased slightly differently — “find large buckets” versus “alert me if any bucket exceeds 50 GB” — may produce a different output format, different flag choices, or omit the alert step entirely. Worse, tacit knowledge lives in people’s heads, not in the system: the engineer who knew to convert 50 GB into bytes (53,687,091,200) before passing it to awk leaves the team, and the next agent run silently uses the wrong threshold and misses over-limit buckets. There is no code review, no PR, no test to catch this.

Sense it early

• Outputs vary run to run: run the same task twice and get different column names or different units in the output. If results are not deterministic, the AI is improvising. Regression-test your agents the same way you test code — if you wouldn’t ship code without a test, don’t ship an agent workflow without a Skill.
• New team member cannot replicate: if onboarding requires asking the original author “which flags do we actually use?”, the knowledge is not in the system. That gap is exactly what a SKILL.md fills.
• Prompt variation test: write five different phrasings of the same task and compare outputs. Meaningful differences mean prompt brittleness. A Skill anchors the workflow against this by defining “done” clearly, independent of how the user words the request.

Course correction

Write a SKILL.md for every workflow you run more than once. It takes about 30 minutes, lives in git, costs ~800 tokens when loaded, and provides the same guidance that 44,000 tokens of MCP schema would — at 1/55th the cost. Start with your highest-frequency and highest-risk automations. A useful prioritisation: any task where a wrong flag would cause a silent failure (wrong byte conversion, wrong metric name, missing alert confirmation) is exactly where a Skill pays for itself immediately.

The unifying pattern across all three mistakes

Each failure shares the same root cause: the choice of transport or abstraction layer was made once, globally, and never revisited as the use case evolved. The practical rule is:

• Monitor token consumption per task — spikes reveal MCP overload
• Monitor data isolation per user — gaps reveal CLI’s limits
• Regression-test agent outputs across prompt variants — drift reveals missing Skills

The earlier you instrument these three signals, the cheaper the course correction. Caught at development time, any of these fixes costs an afternoon. Caught in a compliance audit or a customer data incident, the cost is orders of magnitude higher.

We’ll take a more concrete enterprise example and implement it with variations for MCP, CLI and Skills.

Until then keep reading…..Peace