Skip to main content

Give agents CLI tools

An agent in Saggar is a program running in a shell, so it can run anything you can. When a service has a command-line tool, install and log into that tool, and tell the agent to use it. Reserve MCP servers for services that have no shell to reach, or that you can only reach remotely.

Why a CLI beats a server for most tools​

A CLI is one install and one login that serves you and every agent on the Mac. An MCP server is one more thing per agent: another install, another authorization, and a permanent slice of the agent's context window holding tool definitions it may never call. A CLI costs nothing until the agent runs --help, and the details leave the context when the command finishes.

The command line is also the surface you can watch. The command, its output, and its exit code are right there in the terminal, so you can rerun what the agent ran, reproduce a failure, and put the working version in a script. Claude Code's own guidance says the same: CLI tools are the most context-efficient way to interact with external services.

The longer argument is in CLI > MCP.

Log in once, in any Saggar terminal​

Authentication belongs to the tool, not to the agent. Run gh auth login, vercel login, wrangler login, or stripe login once in a plain shell, and every session in every project can use the result, whichever agent is running. No separate setup for Claude Code, then again for Codex.

If a tool needs an environment variable rather than a stored login, set it in your shell profile. Every terminal Saggar starts is a normal login shell, so new sessions inherit it. Don't paste secrets into a chat: the agent doesn't need to see a key to run a command that reads it.

Tell the agent which tool to use​

Name the tool in the task, and let the agent learn it from its own help text:

Use the gh CLI for everything GitHub. Read issue #412 with gh issue view, then
open a pull request with gh pr create when the change is ready.

For a tool the agent hasn't met, one line is enough:

Run 'stripe --help' to learn the Stripe CLI, then list the last ten failed
payments and summarize the decline reasons.

Put the tools a repository relies on in its agent instructions file, such as CLAUDE.md or AGENTS.md, so you stop repeating yourself. One line per tool, saying when to reach for it, is plenty.

Prefer a tool's structured output when it has one. gh --json, aws --output json, and --format json flags give the agent something it can parse rather than prose it has to guess at, and they keep a long listing from flooding the context. Ask for a bounded page, too: gh issue list --limit 20 rather than everything.

Let Saggar keep the output in view​

A long-running command is better in a monitor than in the agent's chat. Have the agent start it with saggar monitor, and the output stays docked and visible, turning amber when it reports errors, while the session gets on with the work. saggar quick does the same for a one-shot command you want to see finish.

The saggar command is itself an example of the approach. It's a CLI the Saggar skill teaches to every provider, with no MCP server to install or authorize. See the saggar CLI reference.

Supervision reads shell commands​

Saggar's automatic approval answers routine prompts by reading the command text, so a destructive gh repo delete or wrangler delete is held for you like any other shell command. A call through an MCP server arrives as a tool invocation Saggar can't read the same way, and is left to the agent's own prompt. Reaching a service through its CLI keeps it inside the safeguards you already have.

When MCP still fits​

Use an MCP server when there is no local shell, when the tool lives behind a remote service with nothing to install, or when the host needs tighter control over what the agent can discover and call. A standard protocol beats every vendor inventing its own plugin system. It just shouldn't be the default wrapper around a service that already has a good command-line interface.