Right now, a lot of people are talking about MCP.
And I get why.
It’s a clean idea: connect an AI agent to tools, data, and actions through a standard interface, and suddenly the model can actually do things.
That matters.
But I think a lot of people are still confusing the plumbing with the product.
MCP is useful. MCP is not the product.
The product is what happens after the connection exists.
The product is a reusable skill.
Tools are not enough
Giving an agent access to tools sounds powerful.
But in practice, raw tool access is messy.
If you just hand an agent ten tools, you usually get one of these outcomes:
- it uses the wrong one
- it uses the right one in the wrong order
- it calls the same thing three times with weak assumptions
- it produces output that technically worked, but isn’t reusable
That’s because tools are still too low-level.
A tool is a capability.
A skill is a workflow.
That difference is everything.
A simple example
I’ve seen this in boring, practical work more than once.
An agent with raw shell access and FFmpeg access can absolutely process a video.
But “can process a video” is not the same as “can reliably produce the same short-form output every time.”
The raw-tool version tends to drift:
- wrong trim point
- audio forgotten
- watermark missing
- output naming inconsistent
- thumbnail skipped
The skill version is much narrower, but much more useful.
It knows the sequence.
It knows the defaults.
It knows what “done” looks like.
That’s the part people actually want in production.
Not possibility.
Reliability.
What a skill actually is
A skill is not just “the agent can run a command.”
A useful skill packages:
- the goal
- the right sequence of actions
- defaults
- constraints
- output expectations
- failure handling
- context about when to use it
Compare these two ideas:
Tool: FFmpeg is available
Skill: Turn a raw clip into a 1080x1920 short with trimmed intro, normalized audio, watermark, and thumbnail
The second one is what people actually want.
No one wakes up thinking:
“I hope my agent has access to a media binary.”
They want the result.
Why this matters for AI agents
The current wave of agent demos still over-indexes on tool access.
You see a lot of:
- database access
- filesystem access
- browser access
- shell access
- API access
That’s all necessary.
But it’s still not enough.
Because once the novelty wears off, teams ask a more practical question:
Can this do the same useful task reliably more than once?
That’s where most agents still fall apart.
They can improvise.
They can explore.
They can sometimes solve a task.
But reliable repeated execution comes from skills.
Skills are what turn “the agent figured it out once” into “the agent can do this whenever I need it.”
MCP helps. Skills deliver.
This is why I think the framing matters.
MCP is important because it standardizes access.
That’s good.
But once access is standardized, the real differentiation shifts somewhere else:
- which workflows are packaged well
- which tasks are reusable
- which skills are trustworthy
- which outputs are predictable
- which agent behaviors are actually worth repeating
In other words:
MCP gives agents hands. Skills give them habits.
And habits are what make a system valuable.
The more useful pattern
The better pattern is:
- use MCP to expose capabilities
- use skills to package outcomes
That way the agent is not just connected.
It is directed.
And that is a much more practical way to build.
Why I care about this
This is exactly why I’m bullish on skill-based systems.
Because once you start packaging repeatable terminal workflows into reusable skills, a lot of noisy AI hype suddenly becomes much simpler.
You stop asking:
- what tools can this model access?
And start asking:
- what useful work can this system repeat reliably?
That is a better question.
And in my experience, it leads to much better products.
Tools unlock possibility. Skills unlock reliability.
And reliability is what people actually pay for.
If you want to see how we think about packaging repeatable terminal workflows into reusable skills, that’s exactly what we’re building at Terminal Skills.
Top comments (1)
reusable skills as the actual product layer makes sense but curious how you handle versioning when a skill's underlying MCP tool changes its schema, bc that's where reusability breaks down fast in practice