Skip to main content
The CLI supports authentication, API-key management, tool discovery, and direct tool invocation. The older call <tool> form remains an alias for compatibility.

Authentication and API keys

login uses the hosted MCP OAuth service and opens a temporary callback only on 127.0.0.1. api-key create requires that OAuth login, prints the raw key once, and saves it for subsequent CLI and stdio MCP calls. Login requests read,write by default. To authorize paid hosted tools, run login --scopes read,write,panel:launch,rewards:send and approve the requested access in the browser. You can grant only the paid scope you need. The CLI creates a read-only key by default. For a research agent that also writes, use --scopes read,write. Paid scopes require write and a positive lifetime cap, for example --scopes read,write,panel:launch --spend-cap-usd 100.

list

Writes one tool name per line to stdout. Sorted alphabetically. Pipe into other shell tools:
No backend call is made — list works without an API key.

describe <tool> [--json]

The human-readable form prints:
  • The tool’s title (one line)
  • Its full description (the same text MCP clients see)
  • Every input flag (--name, optional flag suffix, type, enum choices, default, and description)
Use this to discover argument names and types without leaving the terminal. Like list, it makes no backend call. Use --json before or after the tool name for a stable machine-readable object:
The object includes name, title, description, inputSchema, outputSchema, and annotations. Schemas are JSON Schema, so agents and scripts can inspect types, enum values, defaults, and required fields without parsing terminal prose. If the tool name is unknown, prints Unknown tool: <name> to stderr and exits with code 2.

<tool> [flags]

Runs the tool. Output is the tool’s text response written to stdout — typically JSON, the same payload an MCP client would receive. Tool errors remain JSON on stdout, but return a non-zero status so shells and agents cannot mistake them for success.

Argument forms

You can pass inputs three ways. They behave identically once parsed.
--key value pairs. Values are JSON-parsed when possible, so the right type lands in the schema:
  • --target 25 → number 25
  • --dry_run true → boolean true
  • --quality '["Excellent"]' (on list_interviews) → array
  • --country_code US → string (JSON parse fails, falls back to string)
Flags with no value (e.g. --verbose) are treated as boolean true.

Input validation

Inputs are validated against the tool’s Zod schema before any backend call. Missing required fields, wrong types, and enum mismatches all fail fast:

Exit codes

Output and pipes

Tool responses go to stdout. Diagnostic logs (handler errors, stack traces) go to stderr. This separation means you can safely pipe into jq without log noise:
Backend errors round-trip as JSON on stdout, so a pipeline never silently drops them:
Recoverable API failures may include typed fields in addition to the backward-compatible error string:
For consequential writes such as a paid Panel launch, a timeout or server failure means the outcome is unknown. Retrieve the current study state before deciding whether another write is safe; a request ID is diagnostic context, not an idempotency guarantee.

help

All three forms print the same usage summary plus the full tool list. Makes no backend call.

Environment


Tool inventory

The CLI exposes 49 direct tool commands. The MCP-only review_study app is available in supported hosts. For full descriptions grouped by capability, browse the MCP tool reference — shared names, schemas, validation, and responses are identical. The quickest way to see what’s available locally: