CLI and MCP

The standalone dancer CLI has a public binary release at 0.1.28. Install it from the Dancer release channel and verify dancer version. A command in a release does not imply that its server capability is enabled.

curl -fsSL https://github.com/happycatlabs/dancer-cli-releases/releases/latest/download/install-dancer.sh | sh
export PATH="$HOME/.local/dancer/bin:$PATH"
dancer version --json
dancer login

The CLI uses create for authenticated Events app setup:

dancer projects create --name "My App" --json

Create returns the same organization project on repeat runs; an older project with the same name requires an explicit --adopt <project-id>. It never prints the app capture key. An agent can read that write-only ingestion key through the separately scoped projects key command and place it in the server's secret store as DANCER_PROJECT_KEY; no user copy step is needed. Set the hosted ingest origin separately.

login is an operator terminal flow. The managed coding-agent path uses the provider's scoped identity and does not put an operator credential in a repository. To add Dancer to a repository, preview the generated files, apply, then diagnose:

dancer init --api-url https://your-dancer-api.example
dancer init --api-url https://your-dancer-api.example --apply
dancer doctor --json

init --apply writes the Dancer project binding, setup script, and Cursor environment/MCP files only when their paths are absent. Review conflicts instead of overwriting existing configuration.

dancer mcp serves the coding task tools over stdio. dancer mcp --profile telemetry serves read-only project, error, log, run, and product-event tools after operator login. dancer mcp --profile messages serves Messages tools with a configured private Messages profile. The profile does not activate disabled server routes.

For product-event reads, use an explicit project and named options:

dancer projects list --json
dancer events discover --project <project-id> --since 1d --search checkout --json
dancer events count --project <project-id> --event checkout.completed --since 1d --environment production --json
dancer events series --project <project-id> --event checkout.completed --since 1d --bucket 1h --json
dancer events breakdown --project <project-id> --event checkout.completed --since 1d --property source --limit 10 --json

Use --from and --to instead of --since for a fixed UTC window. The default window is one hour and the maximum is 30 days. Count, series and breakdown can filter environment, release, dist and runtime kind/collector. Discovery does not accept context. Existing --data JSON is an alternative; do not mix it with named query options or repeat an option. Counts remain sampled received-time estimates.

Telemetry exposes dancer.events.discover, dancer.events.count, dancer.events.series and dancer.events.breakdown with the same HTTP query validation. These tools remain in the triggers profile for compatibility, but telemetry has no trigger/webhook writes. Analytics requires a local operator session; coding-task credentials do not acquire operator authority by fallback.

For a bounded telemetry read:

dancer errors list --project <project-id> --since 1h --json
dancer logs query --project <project-id> --since 1h --level error --json

The response includes a continuation recipe when another page is available. Keep its exact time window and filters. A healthy command or MCP process establishes client readiness, not the outcome of a coding run.