@lessly/cli

lessly — a unified command-line facade over the Lessly platform operations. It renders the same operation registry agents reach over MCP, so the CLI has parity with MCP by construction.

Install (internal test registry)

This package publishes to the internal Google Artifact Registry. With the repo .npmrc in place and gcloud auth configured:

npm i -g @lessly/cli

Auth

Browser (device-code) login for humans:

lessly auth login                 # prints a code + URL, opens your browser, polls
lessly --profile prod auth login  # against the prod auth server

Non-interactive (CI / agents) with a product-scoped service token:

lessly auth login --token "$LESSLY_TOKEN"

Both store the Bearer under ~/.lessly/credentials.json (mode 0600), per profile. Auth servers: staging auth.lessly.dev, prod auth.lessly.com.

Usage

lessly --profile staging organization product list
lessly organization product create --name "Acme" --yes
lessly deployment cloud-sql-database attach --input @args.json
lessly operations              # raw op list (MCP/CLI parity debug)
lessly config set product <id> # active product

Flag placement (gcloud/gh convention)

• Connection flags go BEFORE the command: --profile <staging|prod>, --refresh. Example: lessly --profile prod organization product list.
• Output / behavior flags go AFTER the operation: -o table|json|yaml (--json), --input <json>|@file|-, --yes/--force. Example: lessly organization product create --name Acme --yes.

A behavior flag placed before the command is rejected with an "unknown option" error — move it after the operation. (Behavior flags are per-operation, so an operation may even define its own --input/--force parameter; in that case the flag is that operation's argument and --yes is the confirm bypass.)

Mutations

Mutating operations prompt for confirmation; pass --yes (or --force) to bypass, and non-interactive sessions must pass --yes (otherwise the command exits 2 rather than running a mutation unattended). A few operations define their own --force argument (e.g. deployment environment reconcile); on those the operation's --force is its parameter, so use --yes to bypass the confirm.

Until the gateway emits the MCP readOnlyHint annotation, mutation detection uses a conservative verb heuristic on the operation's action (list, get, show, describe, status, logs, export, … and list-*/get-* / *-list/*-logs/*-status/*-info are treated as read-only; everything else is treated as a mutation). When readOnlyHint is present it always wins. The safe default is to treat the unknown as a mutation, so an occasional read may ask for --yes — never the reverse.

Exit codes

| Code | Meaning | |------|---------| | 0 | success | | 1 | generic error | | 2 | validation | | 3 | auth / token | | 4 | not found / forbidden / no product selected |

Architecture

Commands depend only on the neutral Operation model produced by the operation catalog (tools/list → Operation). The transport seam (src/transport) is the only MCP-specific code; swapping it for a manifest endpoint in step 2 changes no command.