Skip to content

8.4 CLIs: The Other Kind of Hands

Here's a secret hiding in plain sight since Chapter 3: your agent has been using tools all along. Every git status, every ls — those are CLIs, command-line programs, and they're the other way to give an agent reach. No protocol, no server, no config: install the tool, and an agent that lives in a terminal can just... use it. This lesson is about when the plain path beats the fancy one.

What you will learn

  • Recognize CLIs as first-class agent tools with distinct advantages.
  • Choose between MCP and CLI for a given connection — the real decision criteria.
  • Set up the highest-value CLI for builders: gh, GitHub's command line.

Builder principle

The best tool is the boring one that's already there. Reach for MCP when you need what only MCP gives — not because it's the headline technology.

Why CLIs punch above their weight

A CLI is any program you run by name in the terminal — git, curl, ffmpeg, gh, the AWS CLI. Three properties make them exceptional agent tools:

1. The agent already knows them. Mature CLIs are all over the training data — thousands of tutorials, Stack Overflow answers, man pages. Your agent has deep, native fluency in git that no tool description could teach. (An MCP server's tools are known only by their menu descriptions; git's knowledge came pre-installed in the model itself.)

2. Composability is free. CLIs chain: gh pr list --json title | jq ... — output of one feeding the next, filters and formats on tap. The terminal's fifty-year-old superpower, inherited by your agent at zero cost.

3. Self-documenting. Stuck? The agent runs gh --help and reads. Tools that explain themselves on demand are progressive disclosure (7.2) built into the medium.

The decision: MCP or CLI?

Question Points to CLI Points to MCP
Does a mature CLI exist for this system? Yes → strong CLI lean No CLI, or it's clunky
Is the interaction request/response? Simple calls → CLI Stateful sessions (a browser you drive step-by-step, a persistent DB connection) → MCP
Rich structured data back-and-forth? Text in/out is fine → CLI Schemas, resources, typed results → MCP
Who needs to configure it? Just this machine → CLI Team-standard hands, shipped in repo config → MCP has the edge

Real-world verdicts from the systems you've met: GitHub → CLI (gh is superb; this lesson's main event). Browser automation → MCP (stateful page-driving is exactly what protocols are for; no comparable CLI). Databases → either (psql exists and the agent knows it; a read-only MCP server adds guardrails worth having — 8.5 will tip this one). Cloud providers → CLI first (aws/gcloud/az are deep and the model knows them cold).

The professional default: check for a good CLI first. It's the simpler dependency, and simpler survives.

The main event: gh

If you install one CLI for the rest of this course, it's GitHub's:

$ brew install gh        # Mac; see cli.github.com for others
$ gh auth login          # browser-based, one time

Now watch what your agent can suddenly do — real tasks, this session:

Create a GitHub issue on this repo for the favicon TODO we keep
deferring — title, short body, label it "polish".

What's the status of my repos? Any open issues across them?

And the big one — the professional workflow you've been one tool away from:

Create a branch for the contact-form fix, commit the change we just
made, push it, and open a pull request with a proper description
of what changed and why. Show me the PR URL.

Branch → commit → push → PR, delegated in a sentence, reviewable at every gate. This is how solo builders start working like teams (and how Chapter 10's agent teams will coordinate — PRs are the natural seam between parallel workers; remember this moment when you get there).

gh runs through Bash permission and sandbox controls, while gh auth stores the credential for the CLI. The agent can still invoke whatever that authenticated CLI is allowed to do, so scope the GitHub token/account, keep publishing gates, and review external effects. Credential storage is not capability separation.

A CLI can be a simpler interface than an MCP server when its authentication and commands are already understood. You still need to inspect the proposed command, account scope, target repository, and external effect. Start read-only by asking what issues are visible; do not ask the agent to change one until the task and permission boundary are explicit.

You know gh; the upgrade is letting the agent drive it — most engineers under-delegate here out of habit. Full PR lifecycle (create, check CI with gh run watch, respond to review comments), release chores (gh release create with generated notes from the commit log), repo archaeology (gh search). Add your infra CLIs to the same posture: the agent + aws-cli reading CloudWatch logs during a 6.3 debugging session is the production version of "evidence in context." One rule as delegation deepens: WRITE-y CLI actions (deploys, deletions, anything IAM) deserve the same read-first ritual as MCP servers — 8.5 formalizes it.

Try it now

  1. Install and auth gh.
  2. Run the read-only proof (old ritual, new tool): What can you see about my GitHub account and repos right now?
  3. Do the real thing: have the agent create two issues from your actual TODO pile, then run the full branch → commit → PR flow for one small change. Merge it yourself on GitHub — feel the workflow.
  4. Decision practice: for two systems from your 8.1 gap list, make the MCP-vs-CLI call using the table, and write one line of justification each in your journal.

Check your understanding

  • Name the three properties that make CLIs exceptional agent tools. Which one can MCP never replicate?
  • Make the call and defend it: GitHub? A browser? Your cloud provider?
  • Why is the agent's pre-existing knowledge of git different in kind from its knowledge of an MCP server's tools?
  • What's the professional default when both paths exist, and why?