Help your coding agent find the CLI tools you already installed
By Flavio
Use CLI Tools Cabinet and clitools to discover installed commands, read capabilities, and check flags before an agent changes your project.
An agent needs to export a sound. It could write a script, search for a package, or guess that you already have a command named sounds.
There’s a better starting point: ask what this Mac can do.
CLI Tools Cabinet catalogs installed command-line tools. Its clitools command lets an agent search that catalog and read the tasks a tool supports. We’ll use sound export as the example, but the same workflow works for slideshows, releases, notes, and other jobs.
What you need
CLI Tools Cabinet runs on macOS 14 or later. After purchasing it, connect your GitHub account in Polar, accept the private repository invitation, and download the app from Releases.
Download or clone the source from that same private repository. Install the companion command from the source checkout with ./Scripts/install-cli.sh. The installer builds the CLI and links it into ~/.local/bin, so this route requires Xcode 26 or Swift 6.2. The README also explains how to choose another installation directory.
Check the command before continuing:
clitools --help
clitools capabilities --json
The second command describes clitools itself. It doesn’t list every installed tool.
Build the catalog
Run a scan:
clitools scan
The scan finds explicitly installed Homebrew, npm and Cargo packages, along with commands installed by hand in locations such as ~/bin, ~/.local/bin, and your shell’s PATH.
You should get a summary of what it found. You don’t need the same tools or counts as anyone else.
A scan discovers tools. Inspection is a separate step that runs a tool’s help and version commands and gathers more details. Keeping those operations separate lets you choose which tool to investigate.
List the catalog in a format an agent can read:
clitools list --json
For a large catalog, search the task first instead of pasting the whole result into a conversation.
Find a tool by what you want to do
Suppose your app needs a short sound when a save finishes:
clitools search sound --json
Search matches names, commands, package information, descriptions and saved capabilities. The results can include archived tools too, so check availability before choosing one.
If you have Chip Pops and its CLI installed, the command you’re looking for is blips. Learn what the catalog already knows:
clitools show blips --json
If it needs more information, inspect the tool:
clitools inspect blips --json
Inspection runs the tool’s --version and --help, and can fetch metadata and examples. This is more work than reading the cached entry. Use it when the cached information is missing or old.
Here is the decision path:
Ask the tool which tasks it supports
A capabilities manifest describes tasks with example commands. Ask for one:
clitools capabilities blips --json
clitools only asks tools whose help lists a capabilities command. This matters because passing an unfamiliar positional argument to a random program can start an unrelated operation.
Once a tool has answered, it joins the combined manifest:
clitools capabilities --all --json
That command refreshes tools that answered before. A new tool joins the combined manifest after you ask it with clitools capabilities or inspect it.
A third-party tool can still be useful without a manifest. Its help, cached details, and examples remain available.
Confirm the flags before doing the work
A manifest helps you choose a tool. The installed command’s help explains its accepted arguments:
blips help export
For the sound example, that help confirms the destination and filename options. After choosing a sound, the agent can export it with:
blips export success-003 --to public/sounds --name saved.wav
This writes a file and replaces an existing file at the same destination. Discovering a command doesn’t authorize every action it supports. Have the agent check the destination and perform the work you asked for.
For a complete sound-selection example, see how to export a button sound.
Give the agent a reusable instruction
Put this in your project’s agent instructions:
Before writing a script or installing a new tool, search the installed tools
with clitools. Read a candidate's capabilities, then its command help.
Use the supported command and flags for the requested task. If no suitable
tool exists, explain what is missing before choosing another approach.
That makes discovery part of the workflow. It also gives the agent a way to resolve uncertainty without inventing an option such as --output-dir when the command accepts --to.
When discovery falls short
If a command was installed after the last scan, run clitools scan again. If the shell can’t find clitools, check the directory where you installed it and your PATH.
If capabilities --all misses a tool, ask for it by name. If its help doesn’t list capabilities, use show, inspect, and its normal help instead.
If a search comes back empty, try the command name or a simpler keyword. A capability describes only what its author wrote down; it can’t prove that a tool supports an unlisted task.
Avoid uploading your full catalog or shell history just to discover one command. A narrow search and the relevant help usually supply the context the agent needs.
Get CLI Tools Cabinet
Catalog tools from Homebrew, npm, Cargo, and your PATH, with examples, shell history, and a JSON CLI for coding agents.
See CLI Tools Cabinet → · $20 including tax, with full source code.
Want me to talk about your product? You can sponsor this site.