Run the DALP CLI safely from an AI agent

An AI agent can drive the DALP CLI the same way a person does, from a shell. The CLI has two more integrations for agents: an MCP server, which serves dalp commands as tools over the Model Context Protocol, and a skill file, an instruction file an agent reads to learn the command tree without shelling out first. Both modes read from the same generated command tree covered in CLI commands.

The agent does not get a separate authority model. Every command it runs uses the authenticated account, the active organisation, the assigned roles, and the same API validation that applies when you run a command yourself. Unlike the hosted MCP server, the CLI has no draft step: a write the agent sends runs as soon as it passes those checks.

The operator signs the CLI in, and the agent then works inside that session with the same account, organisation and roles.

dalp login, dalp logout, dalp config, dalp completions and the two agent-integration commands below do not need stored credentials, and neither do global flags such as --help and --llms. dalp whoami, dalp org and every generated command do.

This page covers the MCP server that dalp --mcp runs on your own machine. To let a member connect Claude, ChatGPT or another app to DALP without the CLI, see Hosted MCP server.

Shell mode

An agent that already has a shell tool can call dalp directly, exactly as a person would from a terminal.

Set --format json to get structured output instead of the human-oriented toon default. A run with a --format flag, or with output that is not a terminal, is in agent mode. Its output lists each progress event and then the command's response body. When the response links to resources the CLI can read, the output is an object with numbered keys and a cta key with suggested commands. Otherwise it is a JSON array. An agent reads the last numbered entry for the result.

dalp get tokens index --format json

Registering an MCP server

Run dalp mcp add to register the CLI as an MCP server with a compatible agent:

dalp mcp add

This registers dalp --mcp as an MCP server, so the agent reaches every command as a tool through the four tools that MCP tools describes. It installs for your user, or into the current project with --no-global. --agent targets one agent, such as claude-code or cursor, and --command overrides the command the agent runs.

dalp mcp doctor starts the server in the same process, asks it to initialise and to list its tools, and prints ok, toolCount and the tool list. It exits with status 1 when either step fails. It does not read an agent's configuration, so a passing check does not prove that an agent registered the server.

MCP tools

Every get command is marked read-only, so an agent finds a read with search_tools and runs it through call_read_tool.

The MCP server offers four tools: search_tools, get_tool_details, call_read_tool and call_write_tool. call_read_tool runs only tools marked read-only, and call_write_tool refuses them. The CLI sets the mark from the HTTP method of the route behind each command:

Method	MCP mark	Runs through
`GET`	read-only	`call_read_tool`
`DELETE`	destructive write	`call_write_tool`
`POST`, `PUT`, `PATCH`	write	`call_write_tool`

A get command sent through call_write_tool gets the error Tool is read-only: <tool name>, and any other command sent through call_read_tool gets Tool is not read-only: <tool name>. Neither call reaches the API. Tool names are the command words joined with underscores, such as get_tokens_holders.

The hand-written commands whoami, org, config, login and logout are tools too, named whoami, org_list, config_set and so on. They carry no read-only mark, so call_read_tool refuses them and call_write_tool runs them. Through call_write_tool an agent can therefore run logout, which revokes the stored key, and config_set. Register the server only for an agent whose session you supervise. If an agent runs logout, the key is revoked and you sign in again with dalp login.

A tool result is a list of progress events that ends with the route's response body. A failed call ends with an event whose phase is error and whose message is the route's own message, such as the refusal a route sends when the API key lacks the role the read needs. After a blank line the message gives the cause, after Why:, the suggested fix, after Fix:, and the dalp commands that may help. When the route gives no message, the event says Request failed. Without stored credentials, a call answers Not logged in. Run 'dalp login' to authenticate. and sends nothing to the API.

The Console assistant reads the same routes. The two surfaces differ in what a call takes and returns:

	Console assistant	`dalp --mcp`
Credentials	The session of the person asking	The API key from `dalp login`
Route authorisation	The live API router	The same router
Tool inputs	Handles from the conversation	The route's own parameters, such as the asset identifier
Tool results	Handles and figure references in place of the names and numbers a read returns	The route's own response body

The difference in results is deliberate. The assistant replaces names and numbers in a read result before its model sees them. dalp --mcp returns the route's own response body, so names, wallet addresses, balances and identity data in a read reach the MCP client and the model provider it sends tool results to. The organisation's assistant data settings do not apply to it. An MCP client is the key holder's own agent, and the operator who registered it chose it, as operating an organisation with an assistant describes.

search_tools ranks by tool name first and description second, so name the capability in the query, for example holders.

The Console assistant and the CLI

The CLI has no command that asks the Console assistant a question. The assistant's routes serve the Console only and are not part of the published API that the CLI is built from, so neither dalp nor dalp --mcp can reach them. An agent that answers questions from a terminal uses the read commands from MCP tools, under the API key's own roles.

On the latest answer in a Console conversation, the line that names what the assistant read, such as “Read holders and transfers”, opens a list of each read in order. A read the CLI offers shows the dalp command that repeats it, with the asset identifier and the query filled in, and a copy button. A read the CLI does not offer shows its request line, such as GET /api/v2/..., with no copy button. The list comes from the reads the assistant made while it wrote the answer, so opening it sends no request.

A copied command runs under the CLI's API key, not the session of the person who asked, and it returns the route's own response body without the masking the assistant applies. What the assistant sends covers the model, the masking and the limits on the Console side.

Registering a skill

Run skills add to install skill files that teach an agent the command tree directly, without a round trip through --help:

dalp skills add

dalp skills add writes one skill per top-level command group, such as dalp-get and dalp-create. It installs for your user, or into the current project with --no-global, and --depth changes the grouping. dalp skills list lists those skills and marks each as installed or not. Both mcp add and skills add finish by suggesting example prompts scoped to what the CLI does, for example asking the agent to log in, list tokens, switch the active organisation, or check whoami.

Safe patterns for agent-driven commands

Run dalp whoami and dalp org current before letting an agent run a mutation, so both you and the agent confirm which account and organisation a command acts against.
A mutating command (create, patch, replace, delete) asks the platform to hold the response for up to 15 seconds while the write settles, and --no-wait asks it to answer at once. Neither makes the CLI poll: a write that outlives the wait returns a handle, and the command says Request accepted; the transaction is still settling. An agent must inspect the returned handle before reporting completion. Follow statusUrl, for example with dalp get transaction-requests index <transactionId>, because resubmitting with a new idempotency key can create a second instruction.
Prefer --format json or --schema over parsing toon or human help text. --schema returns a command's argument and option shape as JSON Schema, which an agent can validate against before it runs anything.
Treat any command under delete, patch, or replace as requiring explicit confirmation in your agent's own policy. The CLI itself does not prompt for confirmation before a mutating call.

Operating an organisation with an assistant

An operator decides whether, and how, to let an assistant touch a live organisation rather than a build or test pipeline. The assistant is not a separate DALP role: it inherits the authenticated account, active organisation, visible data, and assigned roles of the session you give it, so the same permission checks and API validation apply to every command it runs. If those credentials allow minting, pausing, inviting users, or changing compliance provider state, the assistant can run the same operations, and the CLI does not ask before it does. dalp login always creates a read-write key that lasts 90 days, so the account's roles are the only way to narrow what the assistant can do. Sign the CLI in as a separate account with only the roles the task needs when your operating model calls for tighter supervision. Install and configure the DALP CLI covers authentication and pinning the active organisation before a session starts.

Privileged operations need a human sign-off

Use an assistant for inspection and for preparing commands. Keep execution of a privileged command under operator review, with the operator accountable for each run. An assistant must not run a command that changes token state, identity or compliance records, or platform access without a human operator approving it first:

creating a token, or minting, burning, pausing, or unpausing one.
changing platform access roles.
submitting or approving an identity or KYC record.
changing a compliance provider's state, secret, or webhook configuration.
retrying a failed webhook delivery, or re-running a mutation after an unclear result, since a blind retry against a consumer that already processed the first attempt can duplicate its effect.

The CLI does not ask before a write, so enforce this rule in the agent host, for example with its approval step for call_write_tool and for shell commands that write.

Apply these rules on every run:

Have the assistant read current state before it proposes a mutation.
Confirm the exact command, including the target token, address, amount, and organisation, before approving it.
Keep high-risk operations under the same approval process you already use for Console or CLI work.
Use roles to limit what the authenticated account can do. Prompt wording is not a permission control.
Keep credentials in the CLI's local credential store. Do not paste an API key, session token, or participant data into the assistant conversation.
Treat assistant output as a draft until you check it against the CLI's own JSON output.

Safe operating pattern

Inspect current state with a read-only command.
Ask the assistant to propose one exact mutation command.
Review the command: the organisation, the target resource, and the expected effect.
Run the approved command yourself, or approve the assistant running it.
Inspect the target state again when the result is unclear.
Keep the CLI's own response as your evidence, not the assistant's summary of it.
If the inspected state still does not match what you approved, stop. Escalate through your incident process before another mutation. Retain the exact command and the CLI's before-and-after output as evidence.

Do not let an assistant retry a failed mutation on its own judgment. If a command times out or returns an unclear error, inspect the target state again before retrying.

What the assistant should return

Before approving a privileged command, ask the assistant for a short run note. Require these facts:

Fact	Why it matters
Active organisation	Confirms the assistant is acting in the right organisation.
Target record	Confirms the exact token, user, provider, or delivery being changed.
Read-only checks performed	Shows what state the assistant inspected before proposing the change.
Proposed command	Lets you review the exact operation before it runs.
Expected effect	Makes the state change, and how to recover from it, explicit.

Keep secrets, API keys, and recovery material out of the run note.

What stays outside the assistant

The platform account, wallet custody, and your human approval process decide what is allowed. Keep each of the following entirely outside the assistant:

DALP roles and organisation membership.
wallet custody and transaction signing policy.
approval policy for privileged operations.
API keys, session credentials, and recovery material.
incident escalation and final operational sign-off.

A command like mint, burn, pause, or unpause is a platform-side state change. An agent that runs it with the CLI's API key sends no wallet PIN or code, because the platform does not ask an API-key request for wallet verification, and the configured custody path signs the instruction. The account's roles and any maker-checker hold still apply. Keep private signing keys outside the assistant environment.

No platform switch controls this

No platform setting enables, disables, or scopes an AI assistant that drives the CLI. The organisation's hosted MCP switch governs only the Hosted MCP server, not the CLI. An assistant is an ordinary CLI session, indistinguishable from a person running the same commands from the same workstation: the platform applies the same credential and permission checks and writes its audit records under the account and its CLI API key. Restrict it through the roles of the account it signs in as. End its access with dalp logout, or by revoking the dalp-cli key under API keys in the Console.

Next steps

Install and configure the DALP CLI covers authentication, configuration precedence, and credential storage that apply the same way whether a person or an agent runs the command.
Read security and compliance posture for the control layers a privileged command still has to pass.