MCP

Bug Report Management

• create_bug_report — File a new report with auto-classification across 19 types — bugs, feature requests, enhancements, technical debt, and more (title: 3-500 chars). Optional attachments array accepts base64-encoded files up to 400 MB each: any image, video, audio, PDF, or text/JSON. Set format_description: true to auto-reformat the description into a structured template using AI. Pass time_spent_seconds to track QA effort.
• list_bug_reports — List and filter reports (max 100 per page). Filter by type (one of 19 dashboard categories), severity (s1-s4 or legacy critical/high/medium/low), status (using the dashboard's exact values: new, awaiting-triage, confirmed, in-progress, resolved, retesting, closed, reopened — hyphens are deliberate), resolution (fixed / duplicate / works-as-designed / cannot-reproduce / will-not-fix / need-more-info), or root_cause (open-ended kebab-case tag — common values: regression, missing-requirement, documentation, incomplete-refactor, not-a-bug, requirements-mismatch).
• pick_next_bug — Returns the next bug(s) the agent loop should work on, in priority order (S1 → S2 → S3, oldest first within each bucket). Wraps the public.agent_priority_queue SQL view that materializes the agent's "what to pick up" rule (project=bugagent, status=new, severity in S1-S3). Read-only — does not atomically claim tickets. Optional severity (single tier), limit (1-50, default 1). Returns rows in the same shape as list_bug_reports for tool composability. Pair with claim_bug for the read-then-claim pattern.
• claim_bug — Atomically transition a bug from status='new' to status='in-progress', set assigned_to to the calling user, and stamp claimed_at=NOW(). Race-free across concurrent callers via Postgres' UPDATE-WHERE-RETURNING pattern — if two agents call claim_bug on the same id in close succession, exactly one gets claimed:true with the bug body and the other gets claimed:false with a reason string. A pg_cron reaper releases stale claims (status=in-progress + claimed_at > 30 minutes old) back to new automatically, so a crashed agent's tickets re-enter the queue without manual intervention. Inputs: id (UUID or short ID).
• get_bug_report — Get full details of a report by ID. ID formats: accepts either the UUID (e.g. 1fb72a2c-87c7-...) or the workspace-scoped short ID (e.g. WRKID-545). Short-ID lookups are team-scoped — guessing another workspace's short ID returns 404. Returns qualityScore (integer 1–10), ticket_number, and qualityBreakdown (object with 10 dimension scores: reproductionSteps, expectedVsActual, environmentDetails, evidence, rootCauseAnalysis, impactAssessment, contextAndHistory, heuristicsAndOracles, clarityAndStructure, actionability — each 0.0–1.0).
• update_bug_report — Update fields on an existing report. Accepts UUID or short ID (WRKID-545). Updatable fields include title, description, type (any of 19 dashboard categories), severity, status (matches the dashboard exactly: new, awaiting-triage, confirmed, in-progress, resolved, retesting, closed, reopened — hyphens are deliberate), resolution (fixed / duplicate / works-as-designed / cannot-reproduce / will-not-fix / need-more-info), and root_cause (open-ended kebab-case tag — common values: regression, missing-requirement, documentation, incomplete-refactor, not-a-bug, requirements-mismatch). The agent-loop convention requires both resolution and root_cause to be set whenever status transitions out of new; the dashboard, analytics, and the future claude-bot training corpus all depend on those fields. Also includes assigned_to (user ID from list_team_members) and time_spent_seconds for timer tracking. Changing assigned_to automatically triggers the in-app bell notification AND a courtesy email to the new assignee (respecting their per-user opt-out in Account Settings — same pipeline as the dashboard endpoints).
• add_comment — Add a comment to a bug report (UUID or short ID, body 1-10000 chars). If the report is synced to Jira, the comment is automatically pushed to the linked Jira issue.
• list_comments — List a report's full comment thread, oldest first — each comment with author name, parentId (threaded replies), and timestamps. Comments are not part of get_bug_report, so this is how you read a ticket's discussion. Accepts UUID or short ID.
• classify_bug — Classify a description into one of 19 report types (bugs, features, enhancements, etc.) with confidence score
• flush_reports — Bulk delete old reports (admin only)

Usage & Analytics

• get_usage — Check usage against plan limits
• get_stats — Daily counts, type/severity/status breakdowns

Project Management

• list_projects — List available projects
• create_project — Create a new project (auto-becomes default if first)
• delete_project — Permanently delete a project and all associated data (bug reports, automations, test cases, mobile apps, schedules, geo snaps, notes, time entries). Only owner/manager. Cannot delete last project. Storage is freed automatically

Authentication & Account

• register_account — Create a new account (password: 8-128 chars, rate limited: 5/15min)
• login — Sign in and receive access tokens (rate limited: 5/15min)
• update_profile — Update display name
• change_password — Change account password
• get_settings / update_settings — Manage preferences

API Key Management

• generate_api_key — Create a named API key
• list_api_keys — List active keys (prefix only)
• regenerate_api_key — Revoke and replace a key
• delete_api_key — Permanently revoke a key

Team Management

• list_team_members — List all members of your workspace with roles, status, and booster flags
• invite_team_member — Invite a user by email (managers can invite contributors and managers; only owners can invite admins). 5-day expiry link

Integrations

• sync_to_jira — Sync a report to Jira using team's shared connection
• push_to_claude — Generate (or regenerate) the Developer Notes for a bug report — root cause, suggested fix, verification steps, and risk assessment. Accepts UUID or short ID (WRKID-545). Uses platform keys — no per-team Claude connection required. Runs an adaptive chain: three steps on s3/medium or s4/low bugs (Sonnet draft → OpenAI gpt-5 critique → Sonnet synthesis), five steps on the top-two severity buckets — s1/critical or s2/high — (draft → critique → Sonnet rebuttal → Claude Opus adjudicator that reads the full transcript and writes the final notes with independent judgment). Response exposes every round: analysis, draft, critique, rebuttal, challenger_model, adjudicator_model, and a debated flag. Any step failing falls through to the next-best answer. Auto-fires on bug creation; usually only called for manual regenerate.
• analyze_fix_area — Generate (or regenerate) the "Likely Fix Area" sub-block of Developer Notes — a narrow Sonnet output that names where in the codebase the fix most likely belongs. Accepts UUID or short ID. Uses the platform Anthropic key. When the team has a github_connections row and the project has a github_repo mapped, output is grounded in real file snippets from the connected repo; otherwise falls back to general guidance with a nudge to connect a repo. Returns likely_fix_area text, generated_at, repo_used, and a grounded flag. Auto-fires on bug creation — agents typically only need to call this for manual regenerate.
• upgrade_plan — Upgrade subscription via Stripe

Performance Testing

• create_performance_test — Create a performance test config with URL, device, virtual users, duration, score threshold, and auto-bug creation toggle. Pro/Team/Enterprise plans only
• run_performance_test — Trigger a page audit and load test, or a mobile app profiling session on real Android/iOS devices via BrowserStack. Returns a run ID to poll for results
• get_performance_results — Get full results including Lighthouse scores (Performance, Accessibility, Best Practices, SEO), Core Web Vitals (LCP, FID, CLS, FCP, TTFB, INP, TBT, SI), and load test metrics (VUs, requests, RPS, p50/p90/p95/p99 latencies)
• list_performance_tests — List all performance test configurations for the current team
• get_performance_usage — Check monthly performance test usage against plan limits. Free=0, Pro=1/mo, Team=50/mo, Enterprise=unlimited. Top-up: 5 tests for $499 (Pro/Team)

Example Workflow

1. get_performance_usage → check remaining quota
2. create_performance_test → configure a test for your URL
3. run_performance_test → trigger the audit + load test
4. get_performance_results → review scores and vitals

Security Scanning

• create_security_scan — Create a security scan configuration. Web scans use Quick Scanner + Nuclei (4,000+ templates) with three depth levels and optional authenticated scanning. Mobile scans use MobSF for APK/IPA binary analysis. Configurable auto-bug creation with severity thresholds. Pro/Team/Enterprise plans only
• run_security_scan — Trigger a vulnerability scan. Web scans require DNS domain verification. Mobile scans require an uploaded app. Returns a run ID to poll for results
• get_security_results — Get full results including security score (0-100), findings categorized by severity (Critical, High, Medium, Low, Info) with CWE references, OWASP mappings, evidence, and remediation guidance
• list_security_scans — List all security scan configurations for the current team with last score and auth/depth badges
• get_security_usage — Check monthly security scan usage against plan limits. Pro=2/mo, Team=50/mo, Enterprise=unlimited. Top-up: 10 scans for $299 (Pro/Team)
• list_security_schedules — List all scheduled security scans for the team with cron, timezone, enabled state, next run, and notification settings. Joins with the parent scan config (name, scan_type, target_url)
• create_security_schedule — Create a recurring schedule for a security scan. Requires scan_id and cron_expression. One schedule per scan config. Optional timezone, notify_on_fail (none/email/slack/both), notify_email, slack_channel_id. Every run counts against your monthly cap; Security+ and admin users bypass the cap. Scan depth is always read from the scan config at run time
• delete_security_schedule — Delete a scheduled security scan. Does not affect the parent scan config or completed runs

Example Workflow

1. get_security_usage → check remaining quota
2. create_security_scan → configure a scan for your URL or repo
3. run_security_scan → trigger a one-off vulnerability scan
4. create_security_schedule → automate recurring runs (e.g. weekly SAST on main branch)
5. get_security_results → review findings and remediation

Code Review

• list_code_reviews — List recent AI code reviews for the team. Returns quality scores, severity counts, PR info, and timestamps. Team/Enterprise only
• get_code_review — Get a code review with all findings. Each finding includes severity, category (bug/security/performance/style/logic/maintainability), title, description, code suggestion, file path, and line numbers
• get_code_review_usage — Check code review usage. Unlimited on Pro, Team, and Enterprise plans
• get_code_review_analytics — Get review analytics: trends, finding categories/sources, severity breakdown, velocity metrics, top repos/authors. Supports 7/30/90-day lookback

Example Workflow

1. get_code_review_usage → check remaining reviews
2. Review a PR in the dashboard at /dashboard/code-review
3. list_code_reviews → see recent reviews
4. get_code_review → get findings and suggestions

Exploratory AI

Multi-agent autonomous website bug finder with up to 10 parallel agents, each using a different testing strategy.

• list_explorations — List Exploratory AI configs for the team
• create_exploration — Create a new exploration. Accepts agent_count (1–10, Pro: max 3, Team: max 10) to run multiple parallel agents with unique strategies: happy_path, edge_case, security, accessibility, error_path, performance, mobile, data_integrity, navigation, custom
• get_exploration — Get exploration config with agent settings and recent runs
• get_exploration_run — Get run results with per-agent progress, phase data, findings with agent attribution (agent_index, agent_strategy), and linked bugs
• get_exploration_usage — Check monthly usage. Pro: 3/mo (3 agents), Team: 50/mo (10 agents), Enterprise: 50/mo (10 agents)

Example Workflow

1. create_exploration with agent_count: 5 → configure 5 parallel agents
2. Trigger a run from the dashboard or via POST /api/explorations/run
3. get_exploration_run → poll for per-agent progress and findings
4. View deduplicated findings with agent attribution in the dashboard

Notes

• list_notes — List notes with optional keyword search, project filter, author filter, and date range. Returns notes the user owns or shared notes within the team.
• create_note — Create a note in one of 5 formats: markdown, plain_text, rich_text, checklist, outline. Set visibility to private or shared. Auto-title from first 30 characters if no title provided. Optional attachments array accepts base64-encoded files up to 400 MB each: any image, video, audio, PDF, or text/JSON. Pass time_spent_seconds to track QA effort.
• get_note — Get full note details including content and attachments. Requires id.
• update_note — Update title, content, format, visibility, project, or time_spent_seconds. Pass an attachments array to append new files (max 400 MB each) to the note’s existing attachments without replacing them. Only the author can update. Requires id.
• delete_note — Permanently delete a note and its attachments. Only the author can delete. Requires id.

Example Workflow

1. create_note → start a testing session note
2. update_note → append observations as you test
3. list_notes → search past notes by keyword or project
4. get_note → retrieve full note with attachments

Automation

• create_automation — Create a new automation with a custom Playwright script (no FAB recording required). Requires name. Optional: target_url (auto-derived from the first page.goto(...) URL in the script if omitted), script (Node.js/JavaScript/TypeScript or Python — language is auto-detected; defaults to a placeholder), status (draft or active, default: draft), project_id. Returns the automation id. Pro/Team plan required. Tip — Duplicate an automation: use get_automation to fetch the original script, then call create_automation with name set to "[Copy] Original Name" and pass the original script, target_url, and project_id. The duplicate starts in draft status with no version history.
• list_automations — List Playwright automation scripts. Filter by project_id or status (draft, active, paused). Returns array of automations with name, target_url, last_run_status, and run_count.
• get_automation — Get full automation details including Playwright script and recent runs. Requires id. Returns the automation with the live script, a script_versions stack (oldest-first, up to 100 prior entries, each { script, source, timestamp }), and a recent_runs array where each run carries the script_version_label/script_version_source that executed. Call this before run_automation if you need to pick a specific historical version.
• run_automation — Trigger an immediate run of a Playwright test. Requires automation_id. Virtual mode (default): optional device for viewport emulation (e.g. desktop, iphone-15). Live mode: set browserstack: true with bs_browser (chrome, firefox, safari, edge), bs_os (Windows, OS X), and bs_os_version to run on a real desktop browser. Live real-mobile: set bs_os: "android" (devices: "Samsung Galaxy S25 Ultra", "Google Pixel 10", "OnePlus 13R") or bs_os: "ios" (devices: "iPhone 17 Pro Max", "iPhone 16 Pro Max", "iPhone 15 Pro Max") and pass the device name in bs_os_version. Node.js scripts route through browserstack-node-sdk (covers desktop + Android + iPhone). Python scripts route through browserstack-sdk (pytest-playwright) and cover desktop only — real mobile via Python isn't supported because pytest-playwright's browser_type.connect() can't drive BrowserStack's real-mobile endpoints. Video and network logs captured automatically; console logs desktop-only. Version replay: pass optional version_index (integer, 0-indexed) to execute a prior entry from the automation's script_versions history. Default: when version_index is omitted or null, the current live script runs — don't pass a placeholder value just to "pick current". Out-of-range, negative, or non-integer values are rejected. The run record stores the exact snapshot that ran, and any bug report auto-created from a failed run deep-links back to that version in the editor.
• list_automation_runs — List recent runs for an automation. Requires automation_id. Returns runs with status, duration_ms, and error_message.
• list_schedules — List all scheduled web automation runs with cron, timezone, device, and notification settings
• create_schedule — Create a scheduled web automation run. Requires automation_id and cron_expression. Supports device, timezone, notify_on_fail (email/slack/both), and Slack channel options. BrowserStack Live on scheduled runs: pass browserstack: true with bs_browser, bs_os, and bs_os_version — same device matrix as run_automation (Node = desktop + real Android + real iPhone; Python = desktop only).
• delete_schedule — Delete a scheduled web automation run
• list_mobile_schedules — List all scheduled mobile automation runs with devices, cron, timezone, and notifications
• create_mobile_schedule — Create a scheduled mobile automation run on real devices. Requires automation_id, cron_expression, and devices array
• delete_mobile_schedule — Delete a scheduled mobile automation run
• optimize_automation_script — Send a Playwright script to Sonnet 4 for AI-powered optimization. Applies a 12-point checklist that fixes selectors, wait strategies, assertions, error handling, auth patterns, mobile compatibility, and strict mode. Requires automation_id. The current script version is saved before optimization. Returns the optimized script and a changes summary.
• undo_automation_script — Revert an automation script to its previous version. Up to 10 previous versions are retained. Requires automation_id. Returns the restored script and the number of versions remaining.

Example Workflow

1. create_automation → create a test with a custom script
2. list_automations → browse available tests
3. get_automation → inspect the Playwright script
4. run_automation → trigger the test
5. list_automation_runs → check results and duration

Time Tracking

• list_time_entries — List time entries for the team. Filter by period (today, week, month, all), project_id, category, and sort (newest, oldest, most_time, least_time). Team plan only.
• create_time_entry — Log time spent on QA tasks. Requires description, category, and duration_minutes. Optionally set project_id and entry_date (defaults to today). Team plan only.
• update_time_entry — Update an existing time entry. Requires id. Can update description, category, duration_minutes, project_id, or entry_date. Team plan only.
• delete_time_entry — Permanently delete a time entry. Requires id. Team plan only.

Example Workflow

1. create_time_entry → log 45 minutes of regression testing
2. list_time_entries → view this week's time entries
3. update_time_entry → adjust duration or category
4. delete_time_entry → remove an incorrect entry

Test Cases

Full test management with hierarchical folders, nested suites (up to 3 levels deep with sub-suite auto-expansion on runs), drag-drop reorder, AI-assisted case generation, and an analytics Reports tab with KPI trends, failure analysis, suite health, coverage, and tester productivity. All tools call Supabase directly — no HTTP roundtrip, same latency as the dashboard.

Hands-free execution: the run review page is a carousel with one case visible at a time, keyboard shortcuts (P Pass · F Fail · B Block · S Skip), and voice control. Click the mic, then say "Pass", "Fail", "Block", "Skip", "Next", "Previous", "Add notes" (transcribes into the notes field), "Save notes", or "Voice off". Auto-advances to the next untested case on success results; stays put on Fail so testers can dictate details and spawn a bug. Works in Chrome, Edge, and Safari.

Cases & Folders

• list_test_cases — List test cases with optional search, priority (critical, high, medium, low), type (functional, regression, smoke, integration, performance, security, usability, exploratory), status (active, draft, deprecated), and sort (newest, oldest, name, priority).
• create_test_case — Create a test case. Two template variants: steps (default) — per-step { action, expected } grid via the steps array; text — single free-form description via text_content. Both fields can be sent in the same call (the platform stores them independently so a tester switching template_type later doesn't lose either side's data). Optional urls array (max 10 http/https URLs) attaches reference links. Requires name. Optional: description, preconditions, template_type, steps, text_content, urls, priority, type, tags, estimated_time (seconds). File attachments are uploaded via the dashboard's POST /api/test-cases/:id/attachments endpoint (multipart) — not yet exposed as an MCP tool.
• get_test_case — Get full test case details including steps and execution history.
• list_test_case_folders — List the team's folders (one folder per case via folder_id; distinct from suites, which are many-to-many test-plan groupings). Capped at 500; honors project_id and parent_folder_id filters (use "root" for top-level only).
• create_test_case_folder — Create a folder (nests up to 3 levels via parent_folder_id). Use bulk_update_test_cases to move cases into it.
• bulk_update_test_cases — Apply one action to up to 500 cases at once: set_priority, set_status, set_type, add_tags, remove_tags, add_to_suite, pin, unpin.
• link_test_case_to_bug — Establish traceability between a test case and a bug report (verified_by, covers, or relates).
• list_test_case_links — List all traceability links for a test case.
• list_test_case_review_candidates — Dead-test flags: never_run (90+ days since creation), always_passes (5+ consecutive passes in 90d), always_skipped (3+ consecutive skips).
• mark_test_case_review_flags — Persist current archive-candidate flags onto test_cases.review_flag. Runs automatically every Monday 09:00 UTC via pg_cron.

Imports

• Figma import (dashboard UI + REST): upload a zip export of Figma frames (up to 100 MB), Claude analyzes each screen and drafts test cases into a folder you pick or create. Multi-pass pipeline (classify → per-screen cases → flow-level cases across shared-prefix screens → self-critique) with prompt caching, 429 retry, and per-frame error isolation so one bad frame doesn't fail the batch. Cases land as status=active, tagged ai_generated=true, with source='figma' and source_frame_name preserving a link to the original frame. Uses the platform Anthropic key — no per-team Claude connection required. Endpoints: POST /api/test-cases/import/figma/request, POST /api/test-cases/import/figma/start, GET /api/test-cases/import/figma/:id.

Suites & Runs

• list_test_suites — List test suites with case count and last run status.
• create_test_suite — Create a suite. Nests up to 3 levels via parent_suite_id.
• list_test_runs — List test runs with suite name, assignee, and pass/fail summary.
• create_test_run — Snapshot a suite into a new run. Running a parent suite automatically includes every case in every descendant sub-suite (a case linked to both is added exactly once). Each test_run_results row records which originating sub-suite the case came from, so result pages can group by origin.

Reports (Tier 1 + Tier 4 analytics)

• get_test_reports_overview — Headline KPIs for a window (pass rate, runs completed, cases executed) with deltas vs the prior equivalent window. Same numbers the Reports tab KPI strip shows.
• get_test_reports_failures — Four "what to fix?" lists: failing_cases (≥50% fail, min 3 runs), flaky_cases (most pass/fail flips), failing_suites (≥30% fail, min 5 runs), regressed_cases (most-recent fail with an earlier pass in the window).

Example Workflow

1. create_test_case_folder → make a folder tree (e.g. Smoke → Auth)
2. create_test_case → define cases; move them into folders with bulk_update_test_cases
3. create_test_suite → build a test plan (sub-suites optional, up to 3 levels deep)
4. create_test_run → snapshot a run from a parent suite — sub-suites auto-included
5. get_test_reports_failures → ask "what to fix this week?" once the run completes
6. get_test_reports_overview → track the pass-rate trend week over week

Team Booster

• scale_team — Instantly scale your QA team with booster testers. Accounts are provisioned automatically with tester access. Specify team_size (1–10), location, duration, budget, and optionally product_url, product_types, and tech_levels. Pro and Team plans only. You will not be charged until approval has been given.

Example Workflow

1. scale_team → provision 5 senior testers in the US for 1 month
2. list_team_members → verify new testers appear in your team
3. list_reports → review reports filed by booster testers

Geo-Snap

• create_geo_snap — Capture screenshots of a URL from multiple countries simultaneously. Requires url (string) and countries (array of country codes, e.g. ["US", "DE", "JP"]). Free plan: 1 country per capture, 10 saved screenshots. Pro/Team: up to 5 countries, unlimited saved screenshots. Returns an array of snap objects with id, url, country, screenshot_url, status, and created_at.

Example Workflow

1. create_geo_snap → capture https://example.com from US, DE, and JP
2. Compare screenshots to verify localization, geo-redirects, and compliance

Mobile Testing

• upload_mobile_app — Upload an APK (Android) or IPA (iOS) app for testing on real devices. Requires name, platform (android/ios), and file_url. For iOS: upload the IPA for real-device runs, then upload a simulator .app build on the app detail page to enable recording.
• update_mobile_app — Replace an app binary with a new version. Clears cached URLs and simulator builds so all automations use the new version on next run. Requires app_id and file_url. Optional: version.
• create_mobile_automation — Create a test script. Requires name, app_id, script_type (maestro for YAML, appium for Appium Python, appium_js for Appium JavaScript), and script (the test script content).
• run_mobile_test — Trigger a test run on a real BrowserStack device. All script types run via the Appium 2.x W3C WebDriver protocol. Requires automation_id and device (e.g. "Google Pixel 8", "iPhone 15 Pro"). Returns run ID for tracking. Video, Appium logs, device logs, and network logs are collected automatically.
• list_mobile_runs — Get results for mobile test runs. Optional filters: automation_id, status (queued, running, passed, failed, error, archived), limit. Archived runs excluded from default listing.

Example Workflow — Android

1. upload_mobile_app → upload your APK
2. Record test in browser → actions captured automatically
3. run_mobile_test → run on Google Pixel 8 (real device)
4. list_mobile_runs → check results with video and logs
5. Failures auto-create bug reports with failure snapshot and step breakdown

Example Workflow — iOS

1. upload_mobile_app → upload your IPA (for real-device runs)
2. Upload simulator .app build on app detail page (for recording)
3. Record test in browser → actions captured from simulator
4. run_mobile_test → run on iPhone 15 Pro (real device, uses IPA)
5. update_mobile_app → replace IPA with new version when ready

Compliance & Evidence (Team/Enterprise)

• collect_compliance_evidence — Trigger automated evidence collection from connected services (Cloudflare, GitHub, Sentry, Supabase, Railway). Returns run ID. Collects SSL/TLS settings, WAF status, Dependabot alerts, error trends, deploy history, and more.
• check_config_drift — Check all connected services for security configuration drift from baselines (SSL mode, TLS version, HSTS, WAF rules, security headers).
• generate_access_review — Create a quarterly access review report. Audits team members, roles, MFA status, API key usage, and generates recommendations (e.g., revoke inactive keys).
• get_security_events — Query the cross-service security event timeline. Filter by source (cloudflare, sentry, github) and severity (critical, high, medium, low, info). Events are auto-correlated across services.

Compliance Coverage

These tools help with SOC2 (CC4.1, CC6.1, CC7.2, CC8.1), ISO 27001 (A.5.18, A.8.8, A.8.9, A.8.15-16, A.8.29), and GDPR (Art. 5, 25, 32, 33) compliance requirements.