MCP server

Tada ships as an MCP server, tada-mcp on npm. Install it once and sign in once, and your coding agent can call Tada by itself.

What happens where

The program on your machine is a thin client. It sends what to check, waits, and hands back the answer. It opens no browser, films nothing and encodes nothing.

Tada’s own machines drive the browser and check each step, on every check. A check that passes is filmed and gets a link; a try that fails is not filmed. Where a check executes is not an option you pass, so a fix Tada ships reaches your next check without you upgrading. The one thing that touches your machine is a temporary tunnel, opened only when the app is on localhost and closed when the check ends. See Check an app on localhost.

The words

An app has features. A feature has tests. A check is one go at one feature: it runs that feature’s tests and gives one report, which you open in the app. A pass has one film inside its report. People Tada plays in your app are its cast, such as an owner, an admin or a teammate, each with a sign-in. The tool parameters keep older names (journeys for tests, repo for the app) so agent setups written earlier keep working.

Install and connect

npm i -g tada-mcp
tada login
claude mcp add tada -- npx tada-mcp

tada login opens your browser to sign in. On CI or a headless machine, use an API key instead. See the CLI reference.

Cursor, VS Code, Windsurf, Zed and Codex take the same mcpServers block:

{
  "mcpServers": {
    "tada": {
      "command": "npx",
      "args": ["-y", "tada-mcp"]
    }
  }
}

tada with no arguments is the server itself, speaking JSON-RPC on stdin and stdout. The lines above are your client starting that program.

Tools

These work on every version of tada-mcp.

Tool	Arguments	What it does
verify_feature	See verify_feature	Checks a feature in a real browser from the steps your agent sends, and answers with what passed or what failed.
record_demo	Same as verify_feature	An earlier name. Same arguments, same check.
check_result	id	Reads a check by its id when verify_feature stopped waiting before it finished. Starts nothing and is not counted.
about_app	repo	Reads what Tada knows about an app before a test is written: its features and their tests, its cast and their sign-ins, and its screens.
plan_feature	title, and optionally ticket, text	Sends a ticket and returns its proof in plain words. Nothing is checked.
setup_test_account	repo, and optionally role, email, password	Finds out how an app signs in, so a test can reach pages behind a sign-in.
tada_connect_status	none	Says what this account still needs connected, with a link to connect each one.

Run tada --version to see which version you have, and npm i -g tada-mcp@latest to get the newest.

Tries while you build

While a feature is being built, your agent goes back and forth: it sends steps, Tada says what did not hold, the agent fixes it and sends again. Each of those is a try, not a check. This works on every version.

• A try is free for the first several at one check.
• A try is not a report. Nothing is marked failing, nobody is emailed, and no pull request sees it.
• The try that passes becomes the check. It is counted once, its test is saved under Tests, and it is the first report.

A test Tada keeps is switched on: Tada checks it again when a pull request deploys. You can switch any test on or off in the app.

Sign-ins

Steps refer to a sign-in by placeholder, never by its password: {{secret.TADA_TEST_EMAIL}} and {{secret.TADA_TEST_PASSWORD}}, or {{secret.TADA_ADMIN_EMAIL}} for the admin role. about_app lists the cast Tada can already sign in as. setup_test_account with a role asks Tada for a sign-in in a role it does not have. See The cast.

From version 0.1.62

Everything above keeps working, under the same names and with the same arguments. Version 0.1.62 adds a shorter way to ask and a fuller answer.

Three tools

Tool	Arguments	What it does
check_feature	goal, or steps	Checks a feature and answers with its report. It is verify_feature under a new name, and it also takes a goal.
check_result	id	Reads a check by its id: waiting, going, or its report.
about_app	repo	As above, and it also says what is still to connect.

The earlier names stay listed, each with one line saying what to use instead. check_feature takes signIn with a role, which does what setup_test_account does.

Say the goal

goal is what should work, in a sentence or two: “A new customer can sign up and lands on their account page.” Name the app with repo, and add role when it matters who is signed in. Tada writes the test from what it knows about the app, the same way New test does in the app, so it needs an app Tada already knows. For any other app, send steps.

A goal goes through tries the same way steps do. Tada writes the test once and keeps to it each time the same goal is sent, so the answer after a fix says whether the fix held. A test Tada wrote from a goal is saved switched on, unless it presses something that sends, invites, pays or closes an account. That one is saved switched off, and its report says why.

The answer is the report

The answer follows the order of the report in the app:

1. The result.
2. One line that sums it up.
3. What failed: the step, what it expected and what happened.
4. What was not covered.
5. The link to the report in the app, then the test and whether it is switched on.

A check that passes has a film inside its report, and its link comes last. A try has no report, so its answer says it was a try and how many free ones are left.

Improved without an upgrade

When the server starts it asks Tada for its current tool descriptions and its playbook for checking a feature, and serves those. So the way your agent works with Tada gets better without you installing anything. What a tool can do, and what it takes, is fixed by the version you installed. With no network it serves the copy that version shipped with. It waits at most 3 seconds for the answer at start, and then serves the copy it has. To stop the request at start, set TADA_MCP_RIVET=0.