Skip to content
Tech News
← Back to articles

Show HN: Aclif – Agent CLI framework: one grammar, canonical names across SaaS

read original more articles
Why This Matters

Aclif addresses a real friction point in building AI agents that interact with multiple SaaS platforms: the tradeoff between context-window cost and API coverage in tools like MCP servers. By offering a unified CLI grammar and canonical naming across providers, it lets agents access broad functionality without bloating their context with tool definitions, which could meaningfully simplify multi-platform agent development.

Key Takeaways

The Agent CLI Framework

aclif builds command-line tools for AI agents. An agent gets a single tool that provides a unified abstraction across every SaaS provider: one grammar, and canonical names that reach the same record by the same name on any platform.

Try it now Install the binary, list the providers, and read a command's schema, examples, and safety metadata. npm install -g @aclif/core aclif discover --json aclif learn salesforce --json aclif learn servicenow --json aclif salesforce data query --schema aclif salesforce data query --examples aclif salesforce data query --query "SELECT Id FROM Account LIMIT 3" --dry-run aclif servicenow data query --table incident --query "active=true^priority=1" --dry-run Getting started GitHub

Why agents need their own CLI

An MCP server publishes a fixed list of tools, and every tool on the list occupies the agent's context on every turn. The server's author trades coverage for cost when the server is built. Publishing every operation (a typical API has hundreds of definitions) keeps the whole API reachable and consumes tokens for all of it on every turn. Publishing a handful of broad operations keeps the token count small, and any operation the author left off the list is out of the agent's reach. An agent that spans several platforms needs a server, a login, a grammar, an error format, and a set of names for each.

aclif loads a command's definition only when the agent asks for it, so the whole API of every provider is reachable at no standing cost in context. One grammar, one envelope, and one error vocabulary cover every provider, so the agent's context stays about the same size whether it reaches one platform or five.

An agent that runs a defined workflow can leave the model out of the call altogether. A person or an authoring tool works out the exact command at design time and embeds it in the workflow as a string. At run time the agent executes that string as ordinary code, with no tool definition loaded and no inference. The command is chosen at design time, and the authority to run it, the credential, the acting identity, and the policy, is supplied at run time by whatever runs it. Neither side ever holds both.

What every command gives you

One grammar One command structure, one JSON envelope, and one error vocabulary across every provider. An agent learns the tool once, and a new platform adds commands without adding grammar. A JSON manifest adds a command over one HTTP endpoint in the same grammar, with no code. Canonical names Alias sets map customer to Account in one Salesforce instance and core_company in ServiceNow. A tenant catalog, captured from each instance at deploy time, teaches the CLI each instance's custom objects and fields with no change to the provider. Errors an agent can act on An agent recovers in one turn. Every error names the failure, the command that fixes it, and, where the provider's classifier has a rewrite rule for the mistake, the corrected input ready to resend. The classifier is plain code with no model behind it. A command validated in a shell at design time returns the same error at run time under any host, because the same command classes run in both. Introspection without execution --schema , --examples , --shape , and four more flags return before the command runs, need no credentials, and count against no API quota. An agent can discover, learn, introspect, and preview against a rate-limited instance and spend nothing. An embeddable runtime The same command classes run in-process inside a host that supplies credentials, identity, and policy per request, keeps connections warm, and caches expensive logins per instance. A gateway built on it works with the enterprise's own identity provider and secrets vault. Declared safety Mutability, blast radius, reversibility, and idempotency are declared on every command. A policy check can refuse it before its code loads. Every mutation accepts --dry-run , demands --confirm where its metadata says so, and writes an audit line after every run.

The introspection-first workflow

... continue reading