CLI: command reference

The command model, flags, output format, and exit codes for the jentrix client. For install and auth see CLI: install & configuration; for scripting patterns see CLI: recipes & scripting. The CLI overview is the hub.

Every command is a call to an MCP tool. There are two ways to make that call: the generated noun verb commands (ergonomic, with real flags) and the jentrix tool escape hatch (any tool by name, always available). The generated commands are sugar on top of the escape hatch.

Discovering commands

--help works at every level and is the source of truth for any given build — the command tree is generated from the bundled manifest, so it always matches the tools this CLI carries:

jentrix --help                       # every command group
jentrix task --help                  # the verbs under a group
jentrix task create --help           # a command's flags, plus its required scope

Each generated command's help footer names the scope it needs (read / write / admin), so you can tell a read from a mutation before you run it.

The escape hatch: jentrix tool <name>

jentrix tool calls any MCP tool by name — including tools added to the server after this CLI was built. Because the generated commands are sugar on top of it, a lagging CLI never blocks you: the escape hatch always works.

# arguments as inline JSON
jentrix tool list_workspaces --json
jentrix tool get_task --args '{"taskId":"task_123"}' --json

# arguments from a file, or from stdin via "-"
jentrix tool bulk_create_tasks --args-file payload.json --json
jq -n '{columnId:$c, tasks:$t}' --arg c col_1 --argjson t '[…]' \
  | jentrix tool bulk_create_tasks --args-file - --json

A tool name unknown to this build prints a one-line notice to stderr and is still sent (the server decides whether it exists) — this is what keeps the CLI forward-compatible with a newer server.

Generated commands

Every tool in the manifest is also reachable as a noun verb command with real flags derived from the tool's input schema:

jentrix task list --board board_1 --json
jentrix task create --column-id col_1 --title "Ship the CLI"
jentrix task get --task task_123 --json
jentrix board list --workspace ws_1 --json
jentrix board unarchive --workspace ws_1 --board-ids board_1 --board-ids board_2 --json
jentrix comment create --task task_123 --body "on it"

Command groups

High-traffic tools get short curated aliases. The curated groups are:

Full deployments curate more groups on top — contacts, webhooks, harness, delivery — for the tools only they serve.

Every other tool (the full surface is 242 tools — webhooks, automations, harness, delivery, policies, agents, and more) auto-mounts under a group derived from its name, so it is reachable even without a curated alias. An alias buys ergonomics, never reachability; when in doubt, jentrix --help lists everything and jentrix tool <name> always works.

That 242 is a fact about the binary, not about your server: one CLI build ships the whole command tree and points it wherever you aim it. A deployment serving a smaller catalog — the MVP surface serves 62 — still has every command mounted; the ones it does not serve fail at call time with METHOD_NOT_FOUND rather than being hidden from --help. jentrix tool list against your own endpoint is the authority on what is actually there.

How flags are derived from the schema

The CLI maps each tool's input schema to flags:

• Scalars become --flag <value> (strings, numbers, booleans, enums). Boolean properties also get a --no-<flag> form where the schema allows it.
• Cross-cutting id properties are renamed for ergonomics: --workspace (workspaceId), --board (boardId), --task (taskId), --if-unmodified-since (expectedUpdatedAt). A handful of tools whose own url property would collide with the endpoint override are renamed too (attach_artifact → --artifact-url, for instance).
• Nullable "clear this field" properties get a paired --clear-<name> flag that sends null, mutually exclusive with the value flag (and its rename).
• Object/array-shaped properties (for example bulk_create_tasks.tasks) are set as JSON via --<name>-json '<json>' or --<name>-file <f|->, rather than a flood of sub-flags.
• --args '<json>' supplies extra/overflow arguments to any generated command. Precedence: an explicit flag wins over --args, and both win over a config-file default.

Cross-cutting flags

These are mounted on the generated commands and the escape hatch:

Not every flag applies to every command — the CLI mounts each from the tool's schema, so jentrix <noun> <verb> --help is always authoritative.

Output and --json

Every command accepts --json, which prints the tool's structuredContent as stable JSON (recursively sorted keys) — the machine contract, guaranteed by the MCP server's output schema. Pipe it straight into jq:

jentrix task list --board board_1 --json | jq -r '.tasks[] | "\(.key)\t\(.title)"'
jentrix workspace list --json | jq -r '.workspaces[].slug'

Without --json, list results render as a compact human table and everything else falls back to the same JSON. Scripts should always pass --json — the human layout is cosmetic and may change.

--response-format concise|detailed trades size for detail on the tools that support it — list_tasks and get_task here, plus more list/get tools on a full deployment. List tools default to concise; get_task defaults to detailed. Prefer concise in loops — it is a fraction of the token/byte cost and still carries ids, keys, titles, column/status, priority, and due dates.

Exit codes

The CLI maps every MCP error envelope to a frozen exit code, so scripts can branch on $? without parsing text:

8 is the only code that reports a successful operation. It exists because session end used to exit 1 for a clean close with an incomplete capture, which a script could not tell apart from a close that never happened. Treat 0 and 8 as "the session is closed", and everything else as "it is not".

A missing-telemetry close is a warning, not a code. When a session host ran and matched no provider usage receipts, session end and session status print NO TOKEN TELEMETRY: … on stderr and still exit 0 (or 8, if there is real capture debt). 8 means recorded capture debt and only that, so a capture-off session with unattributed telemetry must not raise it; a script that cares should grep stderr or read usage.coverage from --json. Under --json, stdout stays a single parseable document and the Telemetry: line is omitted — the payload already carries usage.

These numbers never change across releases; see recipes → error handling for the scripting patterns that rely on them.

Version

jentrix --version    # 0.5.3 (surface: 242 tools, file dated 2026-07-16)

See install → what --version tells you for what each part means.