home / why

Why CLIs matter in the age of agents

A practical interface for agents to take action.

Why CLIs fit agents so well

Agents need an interface for action. CLIs already expose actions as commands, flags, arguments, stdout, stderr, and exit codes. That's a very natural contract for a model.

They're lightweight and discoverable. An agent can try a command, get it wrong, run --help, inspect the output, and try again. It only loads what it needs, when it needs it.

They're also composable and debuggable. Humans can run the same command, inspect the same output, pipe tools together, and verify what actually happened.

Where skills come in

A CLI like doctl knows how to talk to DigitalOcean. But it doesn't know about your project. Your droplet IDs, your DNS zones, your deployment workflow.

A skill gives the agent extra capability or context. One of the most useful patterns is using skills to teach the agent how to use a CLI in the context of your project.

The CLI stays generic. The skill captures how your team actually uses it.

How the learning loop works

You tell the agent what you want done. It tries the CLI, gets it wrong, runs --help, learns the command, and tries again. Once it works, you say "remember this" and it writes a skill for next time.

That's progressive disclosure. The agent loads only what it needs, when it needs it. The first time is messy. Then the workflow gets written down. After that, the agent can reuse it.

One practical difference is how much context gets loaded up front. MCP front-loads more tool definition and context. CLIs let the agent learn by doing — and build its own documentation as it goes.

Case study: how CLIs power OpenClaw

Peter Steinberger built OpenClaw, a personal AI agent that can chat through WhatsApp, Telegram, Discord, and perform actions across services.

Before building OpenClaw, Peter had already built a large set of dedicated CLIs for the services he wanted to interact with.

When he later built OpenClaw, those CLIs gave the agent real capabilities. Peter then wrapped them in skills so the agent could use them in the context of his own workflows.

OpenClaw has no native MCP support by design.

On the Lex Fridman Podcast (#491), Peter explained why:

"If you want to extend the model with more features, you just build a CLI, and the model can call the CLI. It probably gets it wrong, calls the help menu, and then on demand loads into the context what it needs to use the CLI."

— Peter Steinberger, Lex Fridman Podcast #491 at 2:39:24

What about MCP?

MCP has real use cases. Enterprise auth with OAuth and audit trails. Multi-tenant SaaS with fine-grained access control. Clients without shell access. Those are all valid cases.

But for most developer workflows, MCP has a fundamental problem: it dumps every tool definition into your context window the moment you connect.

GitHub's own blog confirmed their MCP server was using ~46,000 tokens before a January 2026 consolidation cut it in half. One developer reported MCP servers consuming 41.6% of Claude's context window before asking a single question.

People are even building tools to convert MCP servers into CLIs — mcporter and mcp-cli.

Build your toolkit

Three steps:

1.

Find CLIs for the services you use

GitHub, Kubernetes, Google Workspace, Cloudflare, your database — there's probably a CLI for it already. Browse 320+ CLIs organized by service.

2.

Guide your agent through the CLI

Have a conversation. Tell your agent what you want done. Let it try the CLI, fail, run --help, and figure it out. You're teaching by doing — not by writing documentation.

3.

Capture it in a custom skill

Once the agent knows how to do it, tell it to remember. It writes a skill with your project IDs, your configs, your workflows. Next time, the agent has a reusable runbook.

Browse 320+ CLIs