aclif
An open-source CLI framework that builds self-describing command-line tools for AI agents, providing a unified grammar and JSON envelope across SaaS providers like Salesforce, ServiceNow, and DocuSign.
At a Glance
Fully free and open-source under the MIT license. Install via npm, use all built-in providers, build custom CLIs, and embed the runtime.
Engagement
Available On
Alternatives
Listed Sep 2026
About aclif
aclif (Agent CLI Framework) is an MIT-licensed, open-source TypeScript project by Prompt One, Inc. that builds command-line tools purpose-built for AI agents. Published on npm as @aclif/core and built on top of oclif (the framework behind the Salesforce and Heroku CLIs), it gives agents a single binary that covers every provider it ships with, using one grammar, one JSON envelope, and one error vocabulary across all of them.
What It Is
aclif is a CLI framework designed to solve a specific problem in agentic workflows: the cost and complexity of connecting AI agents to multiple SaaS platforms. Rather than requiring a separate MCP server, login, grammar, and error format per platform, aclif provides a single command surface where a command's schema, examples, and safety metadata load only when the agent asks for them — so nothing sits in context by default. The framework is installable via npm install -g @aclif/core and requires Node.js 22 or later.
Why It Differs from MCP
The project's documentation draws a direct contrast with the Model Context Protocol (MCP) server approach. With an MCP server, every tool on the published list occupies the agent's context on every turn, forcing the server author to trade coverage for token cost at build time. aclif inverts this: one tool describes the grammar for all providers, and a command's definition loads only when the agent requests it with --schema or --examples. This means the full API surface of every provider is reachable at no standing cost in context. Additionally, for defined workflows, the exact command can be determined once at design time and embedded as a string — at runtime the agent executes it as ordinary code with no model in the loop and zero inference cost.
Core Capabilities
- One grammar: A single command structure, JSON envelope, and error vocabulary across every provider. Adding a new platform adds commands without adding grammar.
- Canonical names: Alias sets map logical names like
customertoAccountin Salesforce orcore_companyin ServiceNow;--canonicalresolves them at runtime. - Actionable errors: Every error names the failure, the command that fixes it, and where possible a
correctedValueandworkingExampleready to resend — enabling single-turn recovery. - Introspection without execution: Seven flags (
--schema,--examples,--shape,--changelog,--discover,--flags-for,--estimate) return before the command runs, require no credentials, and consume no API quota. - Declared safety metadata: Mutability, blast radius, reversibility, and idempotency are declared on every command. Every mutation accepts
--dry-runand demands--confirmwhere metadata requires it. - Embeddable runtime: The same command classes run in-process inside a host application or gateway, keeping connection pools warm and caching logins per instance.
Three Deployment Models
aclif supports three distinct runtime topologies:
- Run by the agent — the agent spawns the binary directly; credentials come from flags, environment variables, or a config profile. Best when one agent, one operator, and one credential set share a trust boundary.
- Run by a host application — an application sits between the model and aclif, holds credentials, and calls
runtime.run(...)in-process. Best when the model must never hold credentials and tool definitions must stay out of its context. - Run by a gateway — a single long-lived process serves many agents, resolving credentials from an enterprise vault per request, enforcing policy via a
capabilityGatehook, and recording every call. Best when many agents share providers and one place must hold policy and audit.
Providers and Extensibility
Five providers ship with the current release: Salesforce (native), ServiceNow (native), DocuSign (native), Agentforce (native), and Google Workspace/Gmail/Calendar (contributed). Native providers are maintained by the project with live smoke tests against real instances; contributed providers are maintained by their authors. A private tier allows forks to keep proprietary providers without upstream conflicts. New providers can be added via a JSON manifest for a single endpoint or a full TypeScript provider generated from an OpenAPI document — the project includes a sample generation prompt and an add-provider skill for Claude Code.
Update: v1.3.1
The latest release is v1.3.1, published on September 16, 2026. The repository was created on September 12, 2026, and CI runs on Linux and Windows under Node 22 and 24. The test suite covers six layers: unit, conformance, provider fixture, end-to-end binary, contract goldens, and an opt-in live smoke test. The project is actively maintained by Prompt One, Inc. under the MIT license.
Community Discussions
Be the first to start a conversation about aclif
Share your experience with aclif, ask questions, or help others learn from your insights.
Pricing
Open Source
Fully free and open-source under the MIT license. Install via npm, use all built-in providers, build custom CLIs, and embed the runtime.
- All built-in providers (Salesforce, ServiceNow, DocuSign, Agentforce, Google Workspace)
- Full CLI binary via npm
- Scaffold command to build custom-named CLIs
- Embeddable runtime for host and gateway deployments
- MIT license — free to use, modify, and distribute
Capabilities
Key Features
- Unified CLI grammar across all SaaS providers
- Introspection-first workflow with --schema, --examples, --shape flags
- Canonical name resolution via alias sets
- Declared safety metadata on every command (mutability, blast radius, reversibility, idempotency)
- Dry-run and confirm support for all mutations
- Actionable structured errors with correctedValue and workingExample
- Embeddable runtime for in-process host and gateway deployments
- Tenant catalog via introspect --bootstrap for custom objects and fields
- JSON manifest support for single-endpoint providers
- Scaffold command to build a custom-named CLI
- Three deployment models: agent-spawned, host-embedded, gateway
- Credential resolver interface for vault integration
- capabilityGate hook for pre-execution policy enforcement
- Connection pool with per-instance and per-identity caching
- Exit codes 0/1/2/3 for agent branching without prose parsing
- Pagination via _context.pagination.nextCommand in every envelope
- Private provider tier for fork-safe proprietary extensions
- Live smoke tests against real provider instances
