Skip to main content
The ntro CLI is a thin layer over the Python SDK. Every command parses arguments, calls the SDK, and formats output. No business logic lives in the CLI itself.

​
Install

pip install ntro-cli
ntro --help

​
First-time setup

ntro auth login
ntro auth whoami      # Confirm the key works
ntro tenant list      # Confirm you can see your tenants
auth login writes ~/.ntro/config.toml — see API keys and Configure environment for the full flow.

​
Global flags

All flags go before the subcommand: 
ntro [OPTIONS] COMMAND [ARGS]...
FlagDescription
-c, --connection NAMEConnection from config.toml (env: NTRO_DEFAULT_CONNECTION_NAME)
--host URLOverride the API host (env: NTRO_HOST)
-o, --output FORMATtext (default — Rich tables) or json
--debugEnable debug logging
--log-level LEVELDEBUG, INFO, WARN, ERROR
ntro -c production -o json tenant list | jq '.[].slug'

​
Command groups

ntro auth login                           # Interactive setup
ntro auth login --no-interactive \        # CI/CD setup
  --name production \
  --host https://api.ntropii.com/v1 \
  --api-key ntro_prod_xxx \
  --default-tenant acme-fund

ntro auth list                            # All configured connections
ntro auth test                            # Test the active connection
ntro auth test -c staging                 # Test a specific connection
ntro auth set-default production          # Change the default
ntro auth whoami                          # Current user identity
Used when bringing your own data platform (Snowflake or Microsoft Fabric). Skip this if you’re using managed-postgres — Ntropii provisions and manages the database for you.
# Register a Snowflake account
ntro integration add snowflake \
  --name "Acme Snowflake UK" \
  --account acme-fund.eu-west-2 \
  --warehouse fund_ops \
  --user ntropii \
  --password <secret> \
  --region UK-South

# Or use --json for the full payload
ntro integration add snowflake --json @./snowflake-config.json

ntro integration list
ntro integration info <id>
ntro integration test <id>
ntro integration discover <id>            # List schemas in the warehouse
Every tenant must declare its data-platform strategy at creation. Required values: managed-postgres, snowflake, or microsoft-fabric.
# Managed Postgres — Ntropii provisions the database
ntro tenant create \
  --name "Acme Fund" \
  --slug acme-fund \
  --data-platform managed-postgres

# BYO — register the config first, then bind it
ntro integration add snowflake --name "..." ...
# → dpc_abc123

ntro tenant create \
  --name "Acme Fund" \
  --slug acme-fund \
  --data-platform snowflake \
  --data-platform-config dpc_abc123

ntro tenant list
ntro tenant info acme-fund
The CLI fails fast when --data-platform-config is set with managed-postgres, or missing with a BYO platform. The API enforces the same checks server-side.
ntro entity create \
  --name "Acme Commercial SPV 1" \
  --slug acme-commercial-spv1 \
  --tenant acme-fund \
  --type real-estate-spv \
  --jurisdiction Jersey \
  --currency GBP

ntro entity list
ntro entity list --tenant acme-fund
Tenant resolution: --tenant flag → NTRO_TENANT env var → default_tenant in config.
ntro workflow create --path is a single command that does runbook deploy + workflow binding. Per N-80, workflows are anchored to a runbookSlug; the same runbook can back many workflows across tenants and entities.
# Deploy a runbook + bind it to an entity + add a schedule
ntro workflow create \
  --path ./runbooks/nav-monthly/ \
  --tenant acme-fund \
  --entity acme-spv1 \
  --schedule "0 8 5 * *" \
  --timezone Europe/London

# Update runbook code only (no --entity = no workflow row)
ntro workflow create \
  --path ./runbooks/nav-monthly/ \
  --tenant acme-fund

# Pin the workflow to the version deployed by THIS command
# (without --pin, the workflow follows whatever's currently on the worker)
ntro workflow create \
  --path ./runbooks/nav-monthly/ \
  --tenant acme-fund \
  --entity acme-spv1 \
  --pin

ntro workflow list                        # All entity → runbook bindings
ntro workflow info <id>                   # Detail + current runbookVersion

# Trigger a run
ntro workflow run nav-monthly \
  --tenant acme-fund \
  --entity acme-spv1 \
  --period 2026-03

ntro workflow run nav-monthly --tenant acme-fund --wait     # Poll until complete
ntro workflow run nav-monthly --tenant acme-fund --dry-run
ntro workflow test is covered in Testing locally.
Runbooks are the deterministic Python templates that drive workflows. The CLI surfaces the templates installed on the worker for browsing and feedback.
ntro runbook list                         # All registered runbooks on the worker
ntro runbook info nav-monthly             # Detail + frontmatter + skill definition
ntro runbook templates nav-monthly        # Get the full templates payload
ntro runbook feedback nav-monthly \       # Submit feedback against a runbook
  --message "Period close took longer than expected" \
  --task <task-id>
To deploy a runbook, use ntro workflow create --path (see above) — it wraps the runbook deploy + workflow binding in a single command.
External agents are references to Managed Agents on host platforms (Anthropic, GitHub/Microsoft, …). Registering them with Ntropii makes them addressable by Ntropii UUID from inside a runbook step.
# Register an Anthropic-hosted Managed Agent
ntro agent create \
  --path anthropic://agents/agent_01SxpziMunFrUbnAYkGB5Hu3 \
  --tenant byng \
  --name audit-handover
# Returns the Ntropii agent UUID + API key plaintext (shown once).
# Store the plaintext in an Anthropic Vault.

ntro agent list --tenant byng             # All registered agents under a tenant
ntro agent info <agent-id>                # Detail + kind + externalRef
ntro agent delete <agent-id> --yes        # Tear down the registration
See Register agents for the full lifecycle.
ntro run status <task-id>                 # Single run status + step progress
ntro run list                             # Scheduled / active runs
ntro run history \                        # History for an entity
  --tenant acme-fund \
  --entity acme-spv1
ntro run incoming                         # Queued runs
ntro run pending                          # Runs awaiting human action
Note the linguistic split: ntro workflow run <name> is a verb (execute the workflow). ntro run status <id> is a noun (look at the run).

​
The --json pattern

Write commands accept --json for complex payloads: 
# Inline
ntro tenant create --json '{"name":"Acme","slug":"acme","dataPlatformConfigId":"dpc_123"}'

# From file (@ prefix, Databricks CLI convention)
ntro integration add databricks --json @./databricks.json

​
Output formats

# Default: Rich tables and panels
ntro tenant list

# JSON for scripting
ntro -o json tenant list | jq '.[].slug'
ntro -o json auth whoami | jq .email

MCP server

Same surface, exposed to coding agents over MCP.

Testing locally

ntro workflow test for the design-time inner loop.