MCP, a skill, or a CLI?

An MCP server gives an agent reach. A skill gives it know-how. A command-line tool is often already installed. Pick by the question you need answered, not by fashion.

By the end of this lesson you can

list MCP's real downsides without hand-waving;
compare an MCP server, a skill and a CLI on cost, authorization and sharing;
walk a decision from "does it touch a live system?" to a recommendation;
name the situations where MCP clearly wins, including "M plus N".

The honest downsides

Everything in this course so far explains how MCP works. Before choosing it, weigh what it costs.

Context weight: schemas are resent every turn and grow with each server you add (the context bill).
Prompt-level trust: every tool description shares the model's attention with your system prompt, so a careless or hostile server can steer it (threats).
Ambient authority: local servers run with your operating-system permissions, often started automatically from a project's config.
Operational weight: OAuth, hosting, versioning and observability, for something a CLI and a short skill might do.
Churn: the 2026-07-28 revision removed the handshake, sessions and server-initiated requests. Tutorials age quickly, and dual-era support is real work.
Accuracy and UX: the more tools in the list, the more often the model picks the wrong one; and frequent consent prompts teach users to click "allow" without reading.

Server, skill, CLI

The 2026 consensus among practitioners is that these are complements, not rivals. The useful split is the question each one answers: an MCP server answers "how do I reach this system?", a skill answers "how do I do this well?" (know-how), and a CLI is the tool that already exists.

	MCP server	Skill (a SKILL.md folder)	CLI with instructions
Answers	How do I reach this system?	How do I do this well?	Run the tool that already exists
Context cost	Every schema up front, unless deferred	About 100 tokens of metadata; the body loads on use	Near zero; the model reads `--help`
Authorization	OAuth, scopes, per-tool consent	None: it is text and scripts	Whatever credentials sit on the machine
Side effects	Typed reads and writes, structured results	Indirect, through the tools it names	Anything the shell can do
Sharing	Deploy once, every agent and host	Copy a folder or ship a plugin	The binary must be installed
Best for	SaaS and internal APIs, databases, multi-tenant, governed access	Procedures, house style, playbooks, report formats	git, docker, kubectl, jq: mature CLIs
Weak at	Token weight, operational overhead	Reaching live systems on its own	Governance; needs a sandbox

Key idea

They combine. A skill often tells the agent how to use an MCP server well: which tool to call first, which arguments matter, what the house style for a ticket is. The server gives reach; the skill gives judgement.

Common misconception

"Skills replace MCP." A skill cannot hold a user's OAuth token, enforce scopes, or reach a database from a laptop that has no credentials for it. Most comparison sources are vendor-adjacent blogs: read them as direction, not proof.

Decide for your case

Up to five questions, one recommendation. It encodes the reasoning above, not a law.

Where MCP shines

Write once, use everywhere

Without a shared protocol, every host builds its own integration with every system: M times N pieces of glue.
With MCP, each host implements the client side once and each system ships one server: M plus N.
Adding a host or a system costs one more piece, and every existing partner works with it. This is the LSP idea, applied to tools.

Governed access to company systems: per-user OAuth, scopes, audit and revocation in one place.
Write actions that need a typed schema and the user's confirmation, through elicitation.
Write once, use everywhere: one server works in Claude, IDEs and your own agents. M plus N integrations instead of M times N.
Live, dynamic capability: server-side logic and data, with change notifications, rather than static files.
Gateways: policy, rate limits and tracing keyed on Mcp-Method and Mcp-Name headers, without parsing bodies.
Horizontal scale: the stateless 2026-07-28 revision runs on any replica, including serverless.

Sort the jobs

For each job, what would you reach for first?

Write release notes in the team's house style. Pure know-how: a procedure and a format. No live system needed.
Let 300 support agents look up customer orders with their own permissions. Per-user authorization, audit and one shared integration: MCP's home ground.
Rebase a branch and resolve conflicts in a sandboxed dev container. git is mature and installed; the sandbox makes the local credentials acceptable. The skill records the conventions.
Expose your SaaS product to every customer's AI assistant. Write once, use everywhere, with OAuth and central updates.
Inspect pods and logs in a dev Kubernetes cluster from a laptop that already has kubectl. The CLI exists and is understood by the model; a skill adds the namespaces and gotchas.

Quick check

What is the cleanest one-line split between an MCP server and a skill?

Servers are for code, skills are for prompts
A server gives reach into a system; a skill gives know-how about doing a task well
Skills are the newer replacement for servers

They answer different questions, and they combine: a skill often teaches the agent to use a server well.

What does "ambient authority" mean for a local MCP server?

It runs with your operating-system permissions, whatever its tools claim to do
It inherits the OAuth scopes of every other server
It can only read files in the roots you declared

A stdio server is a process you started. Roots are a hint, not a sandbox; your user account's permissions are the real boundary.

Three hosts and four systems. How many integrations without and with MCP?

7 and 12
12 and 7
12 and 12

M × N = 12 bespoke integrations; M + N = 3 clients plus 4 servers = 7.

Recap

Downsides: context weight, prompt-level trust, ambient authority, operational weight, churn, accuracy and UX.
Server = reach, skill = know-how, CLI = the tool that already exists. They complement each other.
MCP shines for governed access, confirmed writes, M plus N reuse, live capability, gateways and horizontal scale.
Most comparison sources are practitioners: direction, not proof.