The Evolution of Agent Tools: From CLI to MCP to Agent Skills
The Tool Problem
Working with AI agents, especially in programming contexts, has taught me one fundamental truth: tools are everything. An agent without tools is just a chatbot—no matter how smart the model is. It’s like having a brilliant engineer with no screwdriver, no keyboard, no terminal. Just thoughts with no way to act on them.
The First Wave: Self-Made Tools
The initial approach was straightforward: build your own tools. You’d create custom commands, scripts, or functions specifically for your agent. Maybe a command to repair code, execute tests, or search documentation. These worked, but they were isolated. Each agent had its own private protocol, its own way of doing things.
This was the wild west era of agent tooling—functional but fragmented.
MCP: The Unification Moment
Then came MCP (Model Context Protocol). The idea was brilliant in its simplicity: why not create a unified interface for agent tools? Instead of every agent having its own proprietary protocol, tools could be wrapped in a standard format that any agent could understand.
MCP provides:
- Tool descriptions
- Parameter schemas
- Input/output specifications
- Invocation conditions
This metadata gets injected into the conversation context, allowing agents to understand what tools are available and how to use them. The dream was interoperability—any agent could use any MCP-compliant tool.
The Context Window Crisis
But MCP revealed an unexpected problem: context bloat.
When you have many tools—or an MCP server with dozens of functions—all those descriptions flood the context window. Every tool’s name, description, parameters, and examples get loaded into every conversation. It’s like printing out the entire manual every time you ask a simple question.
The result? Context overflow. The agent drowns in tool descriptions before it can even start working.
Agent Skills: The Metadata Revolution
The industry responded with a new standard: Agent Skills. The key insight was counterintuitive—we don’t need to expose everything upfront.
Instead of loading full tool descriptions into context, Agent Skills uses minimal metadata. Think of it as a card catalog instead of the entire library:
MCP approach: “Here’s the GitHub tool. It has 47 functions. Here’s each function’s description, parameters, return types, examples…”
Agent Skills approach: “If the user asks about GitHub operations, invoke the GitHub skill.”
The full documentation loads only when the agent decides it needs that skill. It’s lazy loading for agent context.
The Flexibility of Skills
What makes Agent Skills particularly elegant is their flexibility:
- Wrap an MCP server as a skill
- Wrap a single CLI command as a skill
- Wrap an HTTP endpoint as a skill
- Wrap multiple tools together as a skill
The skill itself isn’t about the implementation—it’s about how and when to expose tool descriptions. It’s a meta-layer that solves the context problem while maintaining compatibility with everything we’ve built.
My Thesis: CLI as Universal Interface
This evolution has me thinking about the future. What if we wrapped everything—MCP servers, HTTP calls, custom scripts—as CLI commands, then wrapped those with Agent Skills?
The advantages would be significant:
- Token efficiency: Only load what you need
- Context conservation: Keep the window clean for actual work
- Increased success rate: Agents can focus on relevant tools
- Universal compatibility: Everything becomes a command
CLI commands are the universal language of automation. By making them the foundation of agent skills, we create a system that’s both powerful and efficient.
The Remaining Challenge: Prompt Engineering
But here’s the catch I’ve discovered: prompt engineering still matters.
Even with the smartest agents and the best tool architecture, how you describe a skill—its metadata, its invocation triggers, its purpose—determines whether an agent will use it correctly.
A poorly written skill description means the agent might:
- Not realize the skill is relevant
- Invoke it at the wrong time
- Use it with incorrect parameters
- Ignore it entirely
The future of agent development isn’t just about building smarter models or better tool wrappers. It’s about crafting the metadata that bridges them. Prompt engineering isn’t going away—it’s becoming more critical than ever.
Looking Forward
I believe the trajectory is clear:
- Standardization: Tools converge on universal interfaces (CLI + skills)
- Efficiency: Context management becomes a first-class concern
- Craftsmanship: Writing good skill metadata becomes a core competency
We’re moving toward a world where agents have access to vast tool ecosystems, but interact with them through carefully curated, context-efficient interfaces. The agents that succeed won’t be the ones with the most tools—they’ll be the ones that know exactly which tools to load, and when.
The revolution isn’t in the tools themselves. It’s in how we teach agents to discover and use them.
This reflection comes from hands-on experimentation with various agent architectures and tool systems. The evolution from ad-hoc tools to MCP to Agent Skills represents a real shift in how we think about agent capabilities.