Tada
Get started

Check what your coding agent builds

Give Claude Code, Cursor or any MCP client a QA it can call. Tada walks the feature the agent just built in a real browser and answers passed or failed.

Your coding agent writes a feature, says it is done, and moves on. Nothing in that loop opened the app. Tada gives the agent a QA it can call before it says done.

Overview

For a feature built from a ticket, the agent makes two calls:

  1. plan_feature. The agent sends the ticket. Tada answers with the proof in plain words: the tests, who does each one, what it depends on, and what is missing. The agent shows you the plan, and you confirm or correct it.
  2. verify_feature. The agent writes the steps for each test and sends them. Tada opens your app in a real browser on its own machines, walks every test, and saves the feature under the ticket’s name. That is one check.
  • Every test passes: the agent gets a watch link to the film it can hand you.
  • A failing test fails the check: the agent gets no link. It gets the step that failed and what the screen showed, so it can fix the feature and try again.

Nothing happens on your computer except a small client that sends the steps and waits for the answer.

Set up

  1. Install the CLI:

    npm i -g tada-mcp

  2. Sign in. This opens your browser, so no password goes in the terminal:

    tada login

  3. Add Tada to your agent. For Claude Code:

    claude mcp add tada -- npx tada-mcp

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

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

Your agent now has plan_feature and verify_feature. You never call either yourself.

Ask for a proof

Give your agent the ticket and tell it what you want proven:

Prove the checkout feature you just built. Plan it with Tada first.

The agent sends the ticket to plan_feature and shows you the plan. Once you confirm it, the agent writes the steps for each test, with an expect after each step that matters, and calls verify_feature.

For a small change with no ticket, the agent can skip the plan and send the steps of one test. To prove a saved feature again, it calls verify_feature with the feature’s name alone.

What comes back

On a pass, the agent gets the watch link and a line saying it passed. Tada keeps the feature and its tests. If the app is connected to Tada, it replays them on every future pull request. Nothing is written into your repository.

On a failure, there is no link. The agent gets every step that failed the check and the check’s page, where the failing frame is:

⛔ Failed. Tada published no film: an `expect` did not hold, so a film would not show the feature working.
  · step 4 (expect): expected URL to include "/library", but still at "/login"

still at "/login" is usually the whole diagnosis. The answer reaches the agent as a tool error, which is what lets it fix the steps and call again without you.

A walk is not a pull request check

verify_feature walks only the tests the agent sent. It does not replay your app’s other features, and it posts nothing on a pull request. For a verdict on every deploy, see Checks on pull requests.

Next