CLI

The tada-mcp package installs two identical binaries, tada and tada-mcp. Use whichever reads better; they’re the same program.

The CLI does exactly one job: get credentials onto the machine so the recorder can upload. Recording happens through the verify_feature MCP tool.

Install

npm install -g tada-mcp

pnpm add -g tada-mcp

yarn global add tada-mcp

bun add -g tada-mcp

Version

tada --version

0.1.31

The bare string is deliberate: $(tada --version) is directly comparable, so a CI step can gate on it. For a human-readable report use tada status, which prints the version and checks the session.

tada --help prints the command list. Both exit 0; an unknown command exits 1 and writes to stderr, so a typo can never look like success.

Commands

Signing in

tada login

Opens your browser to authorize. Nothing is typed into a terminal, nothing pasted. This is the recommended path on a machine you’re sitting at.

tada login --key <key> · tada key <key>

Saves a personal API key. The right choice for CI and headless boxes, where there’s no browser to open. Create one at taada.dev/settings.

The key can arrive four ways: as an argument, via --key, from a prompt if you’re on a terminal, or piped on stdin:

echo "$TADA_API_KEY" | tada key

The key is validated against the server before the command reports success. A typo’d or revoked key fails immediately and loudly, rather than at 3am inside a CI run.

tada login --password

Email and password. Also scriptable: piped stdin takes two lines, email then password:

printf '[email protected]\nhunter2\n' | tada login --password

Checking the session

These two answer different questions, and the difference matters when you’re debugging.

tada whoami

Asks the server. Prints the account on success; exits non-zero when there’s no valid session. This is the honest check, the one to use in a script or an agent, the same way you’d use gh auth status or aws sts get-caller-identity.

tada status

The fuller report: which credentials are on this machine, then a live server check on them.

Tada CLI v0.1.31
Credentials found for [email protected] — checking with the server… ✓ session valid.

A credentials file on disk is not proof of a live session. It can be expired or revoked and look perfectly fine. That’s why status always makes the round trip, and exits non-zero when the check fails.

tada logout

Removes the stored credentials.

Running the recorder

tada · tada mcp

Starts the MCP server on stdio. This is how your AI host launches Tada. You generally don’t run it yourself:

claude mcp add tada -- npx tada-mcp

tada worker

Claims queued runs from the API and drives them on this machine. It is the same recorder the MCP tool uses, taking its work from the queue instead of from a tool call. That is why it lives in the CLI rather than in a service.

tada worker            # keep claiming until stopped
tada worker --once     # claim a single run, then exit

Each run has a ten-minute wall-clock ceiling, so a hung page releases its claim back to the queue rather than holding it forever.

Environment

Notes

There is no upload command. Not an omission. Tada records the demo itself so it can verify the demo actually worked. A video recorded elsewhere has no checkpoints to attest, so it can’t be published as a Tada demo. See Verification.

Unknown commands fail loudly. tada upload and friends print the usage and exit 1. An earlier version fell through and silently started the MCP server, so a wrong command printed nothing and exited 0. A stale command must never look like a successful no-op.

Upgrades are offered, not forced. The auth commands check npm for a newer version and offer to upgrade in place. On a non-interactive shell they just print the notice.