Skip to main content
The NeetoPlaydash CLI (neetoplaydash) lets you read your Playwright test results from your terminal. It covers the v1 REST API: list projects and runs, drill into the specs and tests a run recorded, group a run’s failures by their shared error, pull a test’s history across earlier runs, and fetch Playwright trace viewer links. The CLI is read-only. It never changes or deletes anything in your workspace. It is designed for people comfortable with a terminal or HTTP. You do not need to be a developer: run neetoplaydash setup to connect an AI assistant such as Claude or Cursor, then describe the task in plain language.

​
Why use the CLI?

Triage from the terminal

Filter a project’s runs by branch and status, then drill straight into the failing specs without leaving your shell.

Group failures by cause

top-errors collapses a run’s failing tests onto their shared error log, so one broken selector reads as one problem.

Separate flakes from breaks

Pull a test’s result history across recent runs to tell a new failure from a long-standing flake.

Watch the trend

insights aggregates runs and test results by day, so you can see whether the suite is improving or drifting.

Built for AI agents

Use token-efficient --toon output and one-command setup for Claude, Cursor, Copilot, and more.

​
CLI vs MCP: which should I use?

NeetoPlaydash’s MCP server reaches the same resources the CLI does - projects, runs, test entities, top errors, result histories, traces, and insights - and both are read-only. Neither one can do more than the other, so choose on how the work reaches NeetoPlaydash.

​
Reach for the CLI when

  • No AI assistant should be in the loop. A cron entry or a CI step runs neetoplaydash with nothing but the binary and the workspace you already signed in to - no assistant open, no model account, no tokens spent per run. Over MCP, something with model access has to be running before any call happens at all.
  • The output feeds another program. --quiet prints the bare run record for a shell check that decides whether a deploy proceeds; --json returns records plus pagination for jq, a spreadsheet, or your own script. An assistant replies in prose you would have to copy out by hand.
  • You are working through thousands of records. Over MCP every page is a separate tool call, and a list that long crowds out the assistant’s context. The CLI pages on your terms instead: test-entities list with --page-size 100 and --json returns total_pages and total_records alongside the records, so a loop knows how many pages are left and walks all of them unattended. Each page lands in a file or goes straight into jq, so nothing has to be held in memory and the size of the list stops mattering.
  • You need the same run every time. A neetoplaydash command is plain text you can save. Drop it into a runbook or a pull request and anyone can read exactly what it will do before it runs, then run it later and get the identical call. An assistant works from a prompt rather than a fixed command, so the same request can come out as a different set of calls on a different day.

​
Reach for MCP instead when

  • The details live in your chat, not in your head. A stack trace pasted from Slack, a reviewer’s screenshot, or the diff you just wrote gets weighed against what the run recorded, with no retyping. The CLI cannot see any of it.
  • You have not decided the steps yet. “Last night’s run went red - find out why” means reading the failed attempts and choosing whether to open the trace, the earlier runs, or a different spec. A command can only carry out a decision you have already made.
  • One request should cover several steps. Find the run, list its failing tests, and check one test’s history across earlier runs, with no glue between commands.
  • The person doing it does not use a terminal. NeetoPlaydash hosts the server, so there is nothing to install or keep updated.
You can have both. Run neetoplaydash setup claude and your AI assistant drives the CLI itself, so a plain-language request still ends in an exact command you can read, repeat, and paste into a script.

​
What you need

  1. Access to one or more NeetoPlaydash workspaces.
  2. Permission to view the projects and test runs you want to work with.
  3. The neetoplaydash binary. See Installation.
Unlike the API, which authenticates with an X-Api-Key header, the CLI signs you in through your browser and stores credentials locally. See Authentication.

​
How the resources nest

Every command below the top level takes the identifiers of the resources above it:
traces and top-errors hang off the run, not off a test entity: traces list optionally narrows to one entity with --test-entity-id, and top-errors list reports across the whole run. insights sits beside runs and aggregates across many of them.

​
How ids are passed

A command takes the id of the resource it acts on as its positional argument, and names the ids of the resources containing it as flags:
Every NeetoPlaydash id is a short alphanumeric string. --project and --run are required wherever they apply. The API also accepts a record’s UUID wherever it accepts the short id. projects list needs no id, and insights show and runs list take only a project id as their positional argument. Start with projects list. Each response ends with breadcrumbs that name the next command to run.