Editor’s Note: we are hosting our second in person Agentics event (and our first bi-weekly) at The Brass Factory on July 22nd. We’ll have speakers, food, and hopefully some boardgames too. Sign up here: https://luma.com/agentics-qz0j
Agents are increasingly picking up more and more of our workload. We use agents to write and ship code, publish our dev blog, and even write our board decks. To make that all work, we have to give our agents access to more data sources. Slack, email, GitHub, aws, linear, datadog, sentry. For most of these tools, we can just pull an MCP server and call it a day. But MCP is extremely token hungry, and often implemented really poorly. For some critical integrations, we want to own the integration point.
When building out a new integration, we often reach for CLIs over trying to build a custom MCP. CLIs have built-in progressive disclosure (they do not suck up tokens with parameter descriptions for function calls unless your model absolutely needs to know). The models are extremely familiar with using and calling CLIs through bash. And the models are very good at writing efficient CLI tools, because they have tons and tons of examples.
CLIs that are built for agents as their primary user behave differently than those built for humans. We’ve spent a lot of time thinking about what that behavior difference ought to look like. In no particular order, here are a few principles we use when building CLI tools that assume agents are the primary consumer.
- No colored output. No spinners. No animations. These waste tokens and are probably unappreciated by an agent that can’t see the visual media.
- No interactivity at any point. Everything must be accessible through flags and stdout/stderr output.
- Calling the cli with empty,
--help,--list, etc. should list a full description of what the tool can do at a high level and descriptions of individual commands (“use this command for…”). Overlap is fine here, we want to make it easy for the agent to stumble onto instructions. - Help messages should be recursive. Calling
foo --helpshould explain what the CLI does broadly. Callingfoo bar --helpshould explain what the bar command does within foo, including any parameters that bar may need. Aim for 100% docs coverage. - Every error or help message should include a file path for where the relevant code path is stored on disk, and a message encouraging the model to look up the source if needed.
- Related: we generally install the CLI by building from source or bundling source where possible, so that the decompressed source is present for the model to figure out what to do.
- Make it easy for the agent to fix itself. If the agent tries a command that doesn’t work, do a nearest neighbor lookup. “Did you mean…” but for CLI commands.
You can find all of this in skill form here. Just drop it into your agent of choice, or run
npx nori-skillsets install amolto download my personal agent config (which includes the agentic cli skill already in place).
We’ve built a few different CLI tools that follow these principles, including:
- nori-slack-cli, a thin command-line wrapper around the Slack Web API that maps 1:1 to Bolt (
@slack/web-api). Every method Bolt exposes is reachable through a single dynamic command — there is no curated subset, no opinionated abstraction layer, and no business logic. If Bolt can call it, this CLI can call it. - nori-newsletter-cli, a CLI for managing and sending newsletters via AWS SES. Handles subscriber management through SES contact lists, CSV import, and individual email sending with automatic unsubscribe support.[1]
- nori-luma-cli, a wrapper around the Luma event manager API, so the agents can plan your parties for you! 🥳🥳🥳
- nori-discord-cli, which is like the slack cli but for discord.
- nori-shopify-cli, which lets your agent access the admin tools in shopify.
All of these are open source, so feel free to drop them with your agents and see how they use the tools.
- There’s also a corresponding SKILL here.