If your coding agent can run shell commands, give it a CLI for the service you use. Start there before adding another integration.
A command is easy to inspect. You can run it yourself, change its arguments and save it in a script. The agent can use that same command. For GitHub, that might be gh issue list. For Asana, it might be asana task list.
That's the idea behind the Awesome CLI directory: find tools an agent can call from the shell, then learn a useful task with them.
Start with a task you can check
Here's a read-only GitHub example:
gh issue list \
--repo vincentsch/awesome-ai-cli \
--state open \
--limit 3 \
--json number,state
The repository is explicit. The result has at most three issues. The requested fields are numbers and states, without issue bodies or a long terminal table. GitHub documents these options in its issue list reference.
You can run this command in a terminal before giving the task to an agent. You need GitHub CLI installed and authenticated. The GitHub CLI review includes the commands we ran and a short video.
Give the agent the task and its limits:
Use GitHub CLI to read up to 3 open issues in
vincentsch/awesome-ai-cli.
Check gh issue list --help first. Return the issue
numbers and states as JSON. Tell me if the command fails.
Ask before posting comments or changing anything.
That prompt tells the agent which tool to use, what to read and where to stop. The approval instruction still depends on your agent following it. The command itself is a read operation.
Help and JSON make commands easier to use
A CLI with useful help gives the agent a place to look up flags:
gh issue list --help
It doesn't need to guess the service's HTTP endpoints to do this task. The CLI already implements the request and its authentication.
Structured output also helps when the next command needs a field from the result. GitHub CLI supports an inline jq filter:
gh issue list \
--repo vincentsch/awesome-ai-cli \
--limit 3 \
--json number,state \
--jq '.[].number'
That prints issue numbers without a table. GitHub's formatting documentation explains how --json and --jq work together. Check the command's exit status too. An empty result can be valid; a failed request needs different handling.
The command can outlive the chat
When a command does what you need, keep it. Put it in a shell script or a project task. Another developer can run it without recreating the agent's conversation.
The JSON scripting guide shows how to read output, check its shape and use IDs in later commands. These are ordinary shell operations. You can inspect each step when something goes wrong.
The agent and the person can work with the same executable tool.
Where MCP and skills fit
A skill can teach an agent how to use a CLI. It can hold a task's instructions, examples and project conventions. Keep the executable command in the CLI and use the skill to explain the task. Claude Code's skill documentation shows how instructions and supporting files fit together.
MCP connects a client to tools and other resources through a server. It's useful when the client has no shell, or when the service offers a good MCP connection and no maintained CLI. Its architecture documentation describes that connection.
| Option | What it gives the agent | When to start there |
|---|---|---|
| CLI | Commands it can run through a shell | A maintained CLI already covers your task |
| MCP | Tools exposed through a compatible client and server | Your client has no shell or the service's MCP tools fit better |
| Skill | Instructions and supporting files for a task | The agent needs to learn your CLI conventions or project steps |
A CLI doesn't automatically use fewer tokens or run faster than MCP. That depends on the implementation and the task. Our recommendation comes from being able to inspect, rerun and reuse the commands.
Pick a CLI that gives you control
Look for explicit project or account selection, useful output formats and clear failures. Check the commands you expect to change data. Some have previews; others apply the change immediately.
For example, Asana CLI has a preview for supported task updates. GitHub CLI doesn't have a universal --dry-run flag. A CLI also inherits the access of its credentials; it isn't an agent sandbox.
Browse the directory for your service, or start with the tool guides. Find one command that answers a question you actually have. Run it, inspect the result and give the agent that same task.