There’s a habit in AI tooling circles where every problem somehow ends at MCP.
Need tool use? MCP. Need integrations? MCP. Need agents to touch real systems? Obviously MCP.
I think that instinct is backwards.
For a lot of real-world agent work, Skills are the better pattern. Not more elegant on a whiteboard. Better when you actually have to build, run, debug, and live with the thing.
The reason is simple: we already have a pattern for this, and it has been working for decades.
Linux was built on small tools that do one thing well. That pattern survived because it works. It’s composable, inspectable, debuggable, and cheap to extend. Skills fit that shape naturally. MCPs usually don’t.
The CLI Pattern Already Works
I don’t need a new protocol to believe in tools. I already have one. It’s called the command line.
A clean CLI gives me almost everything I want for agent work:
- a stable interface
- obvious inputs and outputs
- scriptability
- composability
- versioning
- easy local testing
- easy remote execution
- natural logging and debugging
If a tool has a sane command structure, useful --help, and a --json mode, an LLM can usually drive it just fine.
People keep underrating that.
Modern models are already very good at bash. Coding agents are especially good at it. Give them a clean tool surface and a few examples and they get to work fast.
So the winning pattern is often not “invent a protocol layer.” It’s:
- build a small tool
- make the output clean
- write a short Skill explaining best use
- ship it
That’s boring. Good. Boring wins.
Skills Are Lightweight in Exactly the Right Way
A Skill is not magic. It’s not trying to be.
A good Skill is just a compact operator manual for the model:
- use this tool for these jobs
- here are the commands that matter
- prefer these flags
- request JSON
- here are the gotchas
- don’t do the dumb thing
That is a very efficient way to teach an agent how to work.
It also matches how humans already use software. We do not need every tool wrapped in a universal capability bus before it becomes usable. Sometimes you just need a solid binary and a page of instructions.
Unix figured this out a long time ago.
MCPs Add More Machinery Than Most Jobs Need
This is my real issue with MCP.
It turns a lot of otherwise simple integrations into infrastructure projects.
Now the tool has to live somewhere. You need to run a server locally, in Docker, through npx, or host it remotely. You’ve got another process, another lifecycle, another auth path, another thing to break.
Meanwhile a CLI can just use the API directly.
That’s a huge difference.
If I want an agent to interact with a service, I can usually build a focused CLI wrapper in Go or Python much faster than I can design, expose, and maintain a polished MCP server. The CLI is also easier to test, easier to log, and easier to reason about.
That matters when you’re trying to ship instead of admire architecture diagrams.
Context Is a Budget, and MCP Spends It Fast
Another thing people gloss over: tool definitions are not free.
MCPs tend to come with a bunch of schema, descriptions, argument surfaces, and capability metadata that have to be exposed to the model. Add enough of them and you start burning a meaningful amount of context just on tool plumbing.
That is stupidly expensive if the model only needs a small slice of those tools.
Skills are usually much lighter.
Ten Skills can have almost no impact if you load them selectively. Ten chunky MCP integrations can start eating context fast, especially when the tool definitions get verbose.
And context is working memory. Burn enough of it on plumbing and you make the model worse at the actual job.
Coding Agents Changed the Equation
This point matters more now than it did even a few months ago.
Today, coding agents can create small purpose-built CLIs ridiculously fast.
Need to wrap one API? Need a tool that normalizes auth, emits JSON, and exposes three subcommands? Need it in Go so it compiles to one static binary and ships everywhere?
That’s not a giant project anymore. That’s often an afternoon.
And once you have that CLI, you have a tool that is:
- easier for humans to inspect
- easier for agents to drive
- easier to run in CI
- easier to test locally
- easier to compose with other tools
That’s a better artifact than an MCP server in a surprising number of cases.
Not because protocols are secretly evil, but because narrow tools are often better than broad abstractions.
Skills Encode Judgment, Not Just Capability
This is the part I think protocol people consistently underrate.
Access is not the hard part. Judgment is.
The problem is rarely “can the model technically call a function?” The problem is “does the model know which tool to use, when to use it, how to use it safely, and which weird edge cases matter?”
That is exactly what Skills are good at.
A Skill can encode things like:
- always use
--json - batch writes instead of spamming one-item updates
- don’t trust the default date parser
- use the read command before the write command
- this tool is safe for reads but not for destructive actions
- this API lies unless you pass the verbose flag
That kind of guidance is where real reliability comes from.
MCP exposes capability. Skills teach judgment.
And if you’ve spent any time around automation, you know judgment is carrying a lot of the system.
CLI Workflows Fail in More Honest Ways
Another point in favor of Skills plus CLIs: when things break, they usually break in ways you can actually understand.
- command not found
- bad flag
- auth failed
- API returned an error
- output malformed
- process exited nonzero
That’s fine. I can work with that.
The more layers you add between the agent and the actual system, the more you create weird failure modes that have nothing to do with the job itself. That’s how you lose half a day debugging plumbing instead of getting useful work done.
I like systems that fail loudly and plainly.
The shell is very good at that.
This Also Fits How Teams Already Work
This is the least sexy argument, which probably means it’s one of the strongest.
Most teams already know how to work with CLIs.
They know how to:
- install them
- version them
- wrap them
- pin them
- run them in CI
- capture stdout
- parse JSON
- debug failures
- wire them into scripts and workflows
That existing muscle matters.
Skills fit into that world cleanly. They don’t ask you to stop using the patterns that already made software manageable. They give the model the same kind of sharp, explicit guidance you’d give a human operator.
My Default Pattern Now
If I’m building tooling for an agent today, my default instinct is:
- make a small CLI
- keep it narrow
- support
--help - support
--json - make errors obvious
- write a short Skill for best practices
That stack is fast, cheap, legible, and durable.
It’s also friendly to both humans and agents, which matters more than people think. The best tools are usually the ones both can use without needing a priesthood.
Stop Reaching for MCP First
This is really the whole argument.
MCP is not the default answer. It’s an extra layer, and extra layers should justify themselves.
A lot of the time they don’t.
A good CLI plus a good Skill is often the more practical design:
- less infrastructure
- less context bloat
- faster to build
- easier to test
- easier to debug
- easier to replace
- better aligned with how LLMs already operate
That is a hell of a lot of wins for a pattern people keep treating like it’s second-class.
It isn’t second-class. It’s just less fashionable.
And I trust the boring pattern that already built half of modern computing more than the shiny one that keeps turning every simple integration into a protocol debate.
If you’re building agent systems right now, I’d start here:
What is the smallest useful tool I can give the model, and what short set of instructions will make it use that tool well?
Most of the time, the answer is not an MCP server. It’s a Skill and a clean CLI.