Drive all of it from the SDK, CLI, and MCP
Every console action is available through the SDK, an AI-native CLI, and an MCP server that agents drive, under the same permissions and controls as a human.
DALP 3.0 adds a CLI for Platform API operations and exposes its commands through MCP. Scripts and agents use the authenticated account's permissions and the same API validation as other clients.
The CLI and MCP tools call the Platform API under the same permissions
You can script the operations exposed by the CLI. 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 makes those commands available as tools. The same permissions govern both.
- Surfaces
- Console, API, CLI, MCP
- Discovery
- Installed command tree
- Errors
- Typed
- Agent-native
- Yes
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. The API enforces the same authorization checks.
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, same audit trail. If an operation is permitted for a role, it is permitted however you invoke it.
The CLI generates commands from the API contract bundled with its release. Browser sign-in, authenticator ceremonies, and other interactive routes have separate flows or are excluded. Run dalp --help to inspect your installed version. CLI commands explains the exclusions.
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, the same audit trail.
- 1Console
The Operations Console: a human reviews, approves, configures. Every action here is backed by the same call the CLI and API make.
- 2Platform API
The typed v2 REST API. Every console action maps to an endpoint; the SDK wraps it with generated types.
- 3CLI
Operator commands at the terminal, scriptable, composable, and automatable. Flags match the API contract exactly.
- 4MCP
The CLI serves as an MCP server. An AI agent connects, discovers available tools, and calls them with the same permissions your role carries.
Connect an agent through MCP
The Model Context Protocol lets an agent discover and call CLI tools. The Platform API checks authorization when a tool runs. Tool discovery is not proof that the account can perform the operation.
dalp mcp add
dalp mcp doctor
dalp --llms
dalp skills addCLI for AI agents explains session scoping and operator review of privileged commands.
Why it matters
- The console handled approvals and configuration. Humans only.
- The API handled integration. Developers only, with a different mental model.
- Automation meant screen-scraping or bespoke scripts maintained out of band.
- An AI agent had no safe, typed surface to call. No tool discovery, no permissions.
- Console, API, CLI, and MCP tool are the same action. One permission model governs all.
- An agent can discover what it is allowed to do, call it, and handle a typed response.
- Scripts and agent plans share the same commands a human types; nothing to reconcile.
- Error envelopes carry structured metadata, so a retry or escalation path is machine-readable.
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.
Platform API failures include a structured error envelope with a stable error id, category, and retryability. The why and fix fields explain the failure and the next action. When present, retryAfterSeconds names the requested delay.
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.
The error guide documents the envelope and retry rules.
The TypeScript SDK surfaces the same envelope as a typed DalpApiError. 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
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.
The command tree includes token, identity, compliance, and operational routes. New commands require a CLI version that includes those operations.
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.
Self-managed upgrades
System updates compares your deployed components against the on-chain directory and upgrades every out-of-date implementation in one guided run.
v2 API
The v2 REST API at /api/v2 adds JSON:API filtering and sorting, offset pagination, idempotency keys, and headers for identity, wallet routing, and timing.