Give Your Agent a CLI (Not Just MCP or an API)

Source & credit

Distilled from Tom Crawshaw (@tomcrawshaw01) covering nine rules from Matt Van Horn (@mvanhorn) — x.com/i/status/2082450077709381777 / X Article (“He hit number one on GitHub Trending without ever learning to read code…”).

Rule six (the clip you pulled): give your agent a CLI, not an MCP server or an API. Related posts on this site treat MCP and APIs as real tools in the stack — this page is the analysis of when a CLI should sit in front of them.

The baseball-score problem

Ask an agent for a baseball score with no purpose-built tool and you watch it thrash: Google → team site → ESPN → hunt for the right button — burning tokens the whole way. Browsing the open web is a last resort, not a product surface.

Matt’s line (as Tom frames it):

A CLI is Google Maps for agents.

Maps doesn’t make you invent roads. A good CLI doesn’t make the agent invent navigation through your product’s HTML, docs, or 40 REST endpoints. It exposes jobs the agent actually runs: one command, clear flags, predictable stdout, exit codes that mean something.

What “CLI Printing Press” is pointing at

Matt built CLI Printing Press with Trevin to produce agent-oriented CLIs at scale. Example path: ESPN has no official API → an agent sniffed the site, found undocumented endpoints, mapped patterns → shipped a CLI agents can call. They launched around ~50 CLIs; the catalog grew past 350.

Important caveat in the same rule:

Having a CLI does not mean having a good one. Most companies wrap their API endpoints and call it finished, and that is not the same as designing for an agent.

So the debate is not “binary file on disk vs HTTP.” It’s whether the interface is agent-native: task-shaped, documented for models, sticky memory, low token waste.

CLI vs API vs MCP (honest comparison)

Practical take for our team: don’t throw away APIs or MCP. Treat them as layers:

Agent → CLI (task verbs) → optional MCP (expose CLI/tools to host) → API / DB / CDN

Matt’s rule is aimed at teams that stop at “we have an API” or “we shipped an MCP” and never build the map layer agents actually drive.

What a good agent CLI requires

If you already have an API

1. Keep the API as the source of truth (billing, data, CDN, CRM).
2. Don’t hand the OpenAPI dump to the agent as the product. List the 5–15 jobs agents actually run (list files, create draft, score lead, post standup).
3. Wrap those jobs in a CLI with task names, --json, env auth.
4. Document with examples in --help and a short SKILL.md / AGENTS note: “for X always run Y.”
5. Add self-notes where discovery is expensive (endpoint maps, id caches).

Example already on this site: Bunny Storage is an API; agents shouldn’t invent curl every time. We shipped list-bunny-storage.cjs — env auth, flags, markdown out. That’s a small agent CLI over an API.

If you already have MCP

MCP is not “wrong.” It’s a host protocol (Claude Code, Cursor, Codex, OpenClaw MCP). The failure mode is exposing raw CRUD as 50 tools with vague descriptions.

1. Inventory tools. Delete or hide anything the agent never uses cleanly.
2. Prefer “CLI behind MCP” when possible: MCP tool = “run this command with args” or a thin adapter that calls the same code path as the CLI. One brain, two doors.
3. Task-shaped tools. One tool “get_baseball_score(team)” beats “http_request(url, method, body)”.
4. Keep schemas short. Long parameter trees recreate the OpenAPI problem inside MCP.
5. Use MCP where the host needs it (IDE sidebar, multiplayer room tools); use CLI where the agent has a shell and you want pipes, cron, and portability.

Our RankingSolution / DataForSEO path via MCP is still valid as a brain connection — but if agents keep misfiring, the fix is often a seo gaps --domain x --json CLI (or fewer sharper MCP tools), not more endpoints.

Migration playbook (API + MCP → agent CLI)

Week 1 — Observe
  Log which API routes / MCP tools agents actually call (and fail).
  Rank by frequency × pain.

Week 2 — Carve 3–5 verbs
  e.g. list, get, create-draft, publish-dry-run, status
  Implement as CLI only; tests: --help, --json, exit codes.

Week 3 — Point agents at CLI
  AGENTS.md / skills: “use `gfa files list` not raw Bunny API”
  Optional: MCP tool that shells to the same binary.

Week 4 — Memory
  Cache expensive discovery (IDs, path maps, “where World Cup lives”).
  Rulings: wrong flags → one line in playbooks (knowledge base).

Ongoing
  New endpoint? Only ship CLI surface if a verb needs it.
  Review tool/CLI count monthly; delete dead weight.

Examples in our world

Related rules (same interview, short)

• Rule 7: let the tool leave notes for itself (cache discoveries).
• Rule 8: ask a research agent which tool to use before committing (official CLI vs agent-first community CLI).
• Rule 4 / loops: goals are loops — a CLI should support unattended goal runs, not only interactive demos. See Loops.

Full nine-rule arc is in Tom’s article; this page deep-dives rule six for teams living on APIs and MCP.

Bottom line for Mike’s stack

• Yes, prioritize agent CLIs for high-frequency jobs (files, SEO, deploy, content package, member lookup).
• Keep APIs as the backend; stop treating OpenAPI as the agent UX.
• Keep MCP where hosts need it — but make tools task-shaped or wrap the CLI.
• Thin API→CLI wrappers are not enough; design verbs, JSON, help, memory, and gates.
• Ship one CLI this week for the noisiest agent failure you already see in logs.

Related on this site

References

• Tom Crawshaw — nine rules from Matt Van Horn · X Article
• Matt Van Horn — @mvanhorn · Last 30 Days / CLI Printing Press (as discussed in the interview)
• Clip / discussion entry — x.com/i/status/2082598237807288344