Tada works through a feature in a real browser, the way a QA engineer would, and decides whether it worked. A pass comes with a walkthrough anyone can watch without logging in. A block comes with the frame where it broke.

This package gives your coding agent a verify_feature tool over MCP, plus the tada command line. When your agent finishes a feature, it asks Tada to check it and gets the verdict back.

How it works

Your agent calls verify_feature with the steps to walk and what must appear on screen after each one.
This package sends that run to Tada. Tada's servers open your app in a real browser, walk the steps and check each one. Nothing is recorded on your machine.
Your agent gets the verdict: a watch link when it passed, or the step that failed and where to see the failing frame when it did not.

If the app is running on your own computer (localhost), the package opens a temporary Cloudflare tunnel for the length of the run so Tada's servers can reach it. Your app has to be running for that.

Install

npm i -g tada-mcp
tada login

tada login opens your browser to sign in. On CI or a headless machine, use an API key from app.taada.dev/settings instead:

tada login --key tada_sk_…

tada status shows who you are signed in as; tada logout signs out.

Connect your agent

Claude Code:

claude mcp add tada -- npx tada-mcp

Other MCP clients take the same block in their config file:

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

The `verify_feature` tool

arg	type	notes
`title`	string	shown on the watch page
`steps`	Step[]	the actions to perform, in order
`device`	`desktop` \| `mobile` \| `tablet`	viewport preset, default `desktop`
`initScript`	string?	JavaScript run before the app's own scripts, to seed state such as a locale

record_demo still works as a deprecated alias of verify_feature.

Step actions

goto {url} · click {selector | text} · fill {selector | text, value} · select {selector | text, value} · press {key} · hover {selector | text} · drag {selector | text, toSelector | toText} · scroll {selector | value} · wait {ms} · waitForText {text} · expect {text | urlIncludes | selector} · caption {text, ms} · createInbox · awaitEmail {text}

An expect step is what makes a run a check: if what it names never appears, the run is blocked and nothing is published.

Example

{
  "title": "Creating a task from the board",
  "steps": [
    { "action": "goto", "url": "http://localhost:5173/board" },
    { "action": "caption", "text": "Creating a task from the board", "ms": 2500 },
    { "action": "click", "text": "New task" },
    { "action": "fill", "selector": "input[name=title]", "value": "Ship it" },
    { "action": "press", "key": "Enter" },
    { "action": "expect", "text": "Ship it" }
  ]
}

Checks on your pull requests

For runs that happen without anyone asking, with the verdict posted as a check on the pull request, add flow files to your repository and install the GitHub app. See Flows.