Skip to main content
Test plans run your full regression suite across every environment and configuration in one go. When failures surface, you normally have to navigate the Spur UI to understand what went wrong for each test. With the Spur MCP, your AI agent can do this triage for you — pulling every failure, their reasons, and the detailed artifacts needed to diagnose each one. You can also create and update test plans directly from your editor.

​
Available Tools

Once you have task_ids from get_test_plan_run_overview, use the standard run analysis tools to investigate individual failures:
  • get_test_run_overview — Step-level failure summary for a specific task
  • get_test_run_screenshots — Visual state of the browser at each step
  • get_test_run_console_logs — JavaScript errors and browser warnings
  • get_test_run_network_logs — HTTP requests and responses

​
Common Workflows

​
Create a new test plan

Claude calls list_suites and list_environments to resolve names to IDs, shows you a full plan summary, and waits for your approval before calling create_test_plan to save it.

​
Update a test plan

Claude first calls list_test_plans with the plan_id to get the current configuration, then shows you what will change and asks for approval before calling update_test_plan. When updating suites, the full new list replaces the existing one — so Claude copies across all existing suites and adds the new one.

​
Trigger a regression run and wait for results

Claude calls run_test_plan with the plan ID (discovered via list_test_plans) and then polls get_test_plan_runs to monitor progress.

​
Triage all failures from the latest run

Claude calls list_test_plans to find the plan, get_test_plan_runs to find the most recent run ID, then get_test_plan_run_overview to list every failure with its reason.

​
Deep-dive into a specific failure

Claude takes the task_id from the failed test in the plan overview and calls get_test_run_overview, get_test_run_screenshots, and get_test_run_console_logs to build a full picture of why it failed.

​
Full triage loop

For teams doing post-deploy validation, a complete triage looks like this: You can ask Claude to work through every failure in one pass:
Claude iterates over each task_id from the plan overview, pulls the artifacts for each one, and returns a triage summary — distinguishing test issues (wrong selector, timing, stale step) from actual product regressions.

​
Step-by-Step Example

1

Discover your test plans

Claude calls list_test_plans and returns a list with plan IDs, suite counts, environment names, and the last run time for each.
2

Trigger a run

Claude calls run_test_plan with the plan ID. The run is queued and Claude confirms it has started.
3

Check run history

Claude calls get_test_plan_runs and returns a table of run IDs, timestamps, and pass/fail/error counts so you can pick a run to investigate.
4

Get a full overview of a run

Claude calls get_test_plan_run_overview. Failures are listed first with their failure reasons. Each failure includes a task_id for deeper investigation.
5

Investigate individual failures

Claude uses get_test_run_overview and get_test_run_screenshots with the task_id to pull the step-level failure details and visual context.

​
Tips

You can pass a run ID directly from a Spur URL. In /test-plans/665/runs/107272, the run ID is 107272. Drop it straight into your prompt: “Give me the overview for run 107272.”
Run a plan at the start of your day and ask Claude to triage every failure before your team standup. You’ll arrive with a prioritized list of what needs attention and what’s just noise.
When get_test_plan_run_overview reveals a test issue (not a product bug), ask Claude to fix it in-place: “Update the steps for that test to handle the new modal.” Claude calls update_test to revise the steps without you leaving your editor.