For developers

Why this is worth ten minutes of setup

Two things change once TestCatalyst is wired in: you can watch QA happen instead of hearing about it after the fact, and you can run the same kind of test yourself, from your terminal, through an agent you already use.

Watching runs live

Every agent-driven run, whether started in the TestCatalyst UI or by an MCP agent, gets a URL under MCP Runs or Runs that streams steps, screenshots, and pass/fail counts as they happen, over server-sent events. Bookmark a suite's run page and you'll see the next execution appear without refreshing. Failed API steps get an automatic request/response snapshot and a "Test it manually" link straight into the API Runner.

Testing your own branch with your own agent

TestCatalyst ships an MCP server (testcatalyst-mcp), a thin bridge that exposes 18 tools an MCP-capable agent can call: list projects, create/find a suite, start a run, report each step, file a bug, save the finished script, and more. It doesn't drive a browser itself, so pair it with Chrome DevTools MCP, Playwright MCP, or the Claude in Chrome extension.

Minimal Claude Desktop config to get started:

{
  "mcpServers": {
    "testcatalyst": {
      "command": "npx",
      "args": ["-y", "testcatalyst-mcp"],
      "env": {
        "TC_API_URL": "https://testcatalyst.co",
        "TC_TOKEN": "your-mcp-token-here"
      }
    }
  }
}

Full setup, the complete tool table, and a sample prompt are in MCP server.

Turning an exploratory session into a regression test

When an agent-driven run passes, it saves the Playwright script it just executed to the project. That script is a real, runnable Playwright test, so pull it into your own CI pipeline. The practical effect: someone asking Claude to "test the checkout flow after this refactor" once can become a test that runs on every PR afterward, without anyone hand-writing it.

Self-healing instead of flaky-red

A failed CSS/XPath selector during a run gets sent, along with a live snapshot of interactive elements on the page, to a model that returns a corrected selector, or confirms the element genuinely isn't there anymore, which is a real bug, not a maintenance chore. Less time spent explaining to QA that a test broke because of an unrelated markup change.

Catching drift between design, API, and UI

If your team uses Figma, an agent can render a specific frame and diff it against a screenshot of the live page, or extract field names from a Figma frame and diff them against what an API actually returned, surfacing naming mismatches between spec and implementation before a user or a PR reviewer does.

A real, enforced viewer role

If you want to give a PM or another engineer visibility into QA activity without write access, the viewer role is read-only everywhere it matters. Suites and bug reports are visible, nothing is editable, and it's enforced server-side, not just hidden in the nav. See Roles & permissions.