# Drive all of it from an AI-native CLI
Source: https://docs.settlemint.com/docs/changelog/dalp-3-0/cli-api
Every console action is available through the API and an AI-native CLI that agents drive over MCP. Same permissions, same controls, whether a human or an agent is behind the wheel.
**Every console operation is now a CLI command, a typed API call, and an MCP tool. A human operator and an AI agent drive the same controlled surface, under the same permissions.**
Anything you can do in the console, you can now script. So can an AI coding assistant or an automated pipeline. MCP (the Model Context Protocol) is the open standard that lets software discover and call tools safely. Exposing DALP through it means every operator operation becomes callable, not just a screen a human has to click. The same permissions govern both.
Operator workflows used to live in two worlds: a console a human navigates, and an API an integration calls. In DALP 3.0 we closed that gap. The CLI runs natively in both. It executes operator commands directly, exposes DALP as an MCP server an agent can explore and drive, and generates skill files an agent loads to discover the full command surface. A task that once required clicking through a workflow is now a single typed command, a scheduled script, or a step in an agent's plan.
The deeper shift is what this enables for agent-driven automation. Until now, building an AI agent around a regulated platform meant maintaining a parallel integration layer: a custom wrapper that translated the platform's API into something a language model could call safely. MCP removes that layer. An agent connects to the CLI as an MCP server, discovers the full set of operator tools available for its role, and calls them directly. The same validation, error envelopes, and compliance controls apply. No custom glue, no privileged back-channel.
The platform has no separate "agent API" or "automation mode." The CLI is the same surface as the Operations Console and the Platform API: same permission model, same validation, same error envelopes. If an operation is permitted for a role, it is permitted however you invoke it.
That parity is a hard design constraint, not a stated aspiration. The CLI tracks 100% of the v2 API surface. Every new route ships with a CLI command in the same change that introduces it; the TypeScript build enforces this. A route without a CLI command fails compilation. When the Platform API gains a capability, the CLI, SDK, and MCP tool surface all gain it in the same change. No lag, no "CLI support coming soon," no class of operation that requires a human at the console.
For integrators, this means you write against one contract. The script you build today works as an agent step tomorrow without modification. A compliance workflow you automate via CLI runs the same code path as the console approval it replaces: same field validations, same authorization checks, same audit trail.
## What MCP means for agent-driven platforms [#what-mcp-means-for-agent-driven-platforms]
The Model Context Protocol is an open standard for connecting AI agents to external systems. It defines a wire protocol for tool discovery and invocation: an agent connects to a server, asks what tools are available, and calls them by name with typed inputs. The server handles execution and returns a typed response. The mechanism is simple. The significance is what it removes.
Before MCP, wiring an AI agent to a regulated platform meant building a bespoke integration layer. You wrote a wrapper that translated the platform's API into something a language model could call: normalizing inputs, handling authentication, surfacing errors in a form the model could reason about. Each workflow required a hand-authored function. A permission change meant auditing two systems. A platform update risked breaking the wrapper.
With the CLI acting as an MCP server, that layer disappears. An agent running inside a developer's coding environment, a CI pipeline, or an automated back-office workflow connects to the CLI as an MCP server and discovers the full operator tool set. The tools it sees are exactly the tools its role permits. No more, no less. When it calls one, the request flows through the same authentication, validation, and compliance enforcement as a console operation. No privileged back-channel, no special agent mode, no second permission model to audit. The same access log that records what a human operator did records what the agent did.
One command registers the CLI as an MCP server with your coding environment:
```sh
# Auto-register with Claude Code, Codex Desktop, Cursor, or OpenClaw
dalp mcp add
# Or start the MCP server directly
dalp --mcp
```
Agent tool discovery works through the same index the MCP server exposes. You can inspect it or hand it to any agent that reads a markdown or JSON Schema tool list:
```sh
dalp --llms # Markdown tool index for agent discovery
dalp --schema # JSON Schema representation of the full command surface
dalp skills add # Install skill files into your agent's skill directory
```
This matters specifically in regulated contexts because it collapses the audit surface. When an agent manages a compliance workflow, adding a trusted issuer, configuring a compliance provider, or triggering identity recovery, you want those operations on the same audit trail as every other step a human takes. Not in a separate log from a custom integration. MCP makes that the default, not an exception.
## Why it matters [#why-it-matters]
## Typed errors your integration can act on [#typed-errors-your-integration-can-act-on]
Parity across entry points only matters if the API is worth automating against. The weak point in most platform APIs is failure reporting: a status code and a prose message string that calling code must parse, pattern-match against, and probably log before giving up. When an agent hits an ambiguous response, there is no safe next step.
Every response from the Platform API, CLI, or SDK carries a structured error envelope. It includes a stable ID in `DALP-NNNN` format, a `category` classifying the error class, a `retryable` boolean, a `message` for display, a `why` field explaining what caused the failure, and a `fix` field describing what to do next. When the platform knows how long to wait before a retry would succeed, for example during an indexer reindexing cycle, it includes a `retryAfterSeconds` value. Calling code never needs to parse prose.
The `category` field carries enough information to determine the correct programmatic response. A validation failure points to a `details` object with the specific failing field. An authorization boundary indicates the calling role lacks permission. A prerequisite signal means something else must be configured first. A chain failure means on-chain state needs resolving before a retry will succeed. An agent can reason over categories and pick the right next step, whether that is a retry, an escalation, or a dependency resolution, without a lookup table for every possible code.
```sh
# Create a compliance template via CLI (its modules are configured through the API)
dalp compliance-templates create --name "Qualified Investor"
# Structured error envelope when a prerequisite is missing
# {
# "id": "DALP-0312",
# "category": "prerequisite.missing",
# "retryable": false,
# "message": "No compliance provider configured for instrument.",
# "why": "Transfer compliance requires an active provider before templates can be applied.",
# "fix": "Configure a compliance provider for the instrument and retry."
# }
```
The TypeScript SDK surfaces the same envelope as a typed `DalpSdkError`. Catching it gives you structured fields to branch on rather than message-string matching. An agent running through the CLI gets identical information in the command's JSON output. The error surface is the same regardless of which entry point triggered it.
## CLI and API coverage [#cli-and-api-coverage]
Coverage is the other thing that matters. An automation surface is only useful for the operations it can reach. A partial API that covers token creation but not compliance configuration sends you back to the console the moment a workflow gets interesting. We built the DALP 3.0 CLI to close that gap: every area that previously required the console now has a command and a typed endpoint.
That completeness is structural. The CLI is designed so a new API route cannot ship without an accompanying CLI command; the build rejects the gap. When an area of the platform gains new capabilities, the CLI gains them in the same change. A script or automation built against the CLI today will continue to have full access as the platform grows. It will not silently fall behind the console. Coverage spans the full operator surface:
Create, update, and apply rule templates, including allowlists, blocklists, and jurisdiction policies, across instruments without opening the console.
Manage the set of credential issuers the platform accepts for a given claim type; readable and writable through the API and CLI.
Configure and list the external compliance integrations that gate transfer approval for each instrument.
Query who held what at any past block. The same point-in-time data the Ledger Index surfaces, now reachable from a script or an agent.
Read and manage treasury yield schedules: consumed interest, closed accruals, payout sequences, and claim history.
Fetch and configure the rate sources an instrument uses for fee calculations and valuation.
Initiate and track on-chain identity recovery operations without manual console steps.
Attach, update, and list the legal and disclosure documents registered against an instrument.
Configure account-abstraction gas sponsorship policies, including which addresses are covered, for how long, and under what conditions.
[Start CLI →](/docs/developers/cli/overview) · [Drive DALP AI agent →](/docs/developers/cli/ai-agents)