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. Pass priority (urgent / high / normal / low) to set the fix urgency independently of severity. Pass is_epic: true to create an Epic, or parent_epic_id (UUID/short ID) to create a child in the same authorized project. The response includes hierarchy fields plus project_id, project, short_id, legacy_short_id, and project_short_id.
• list_bug_reports — List and filter reports (max 100 per page). Project filters are applied server-side before pagination. Filter by project (UUID, slug, exact name, or ticket prefix), project_id, project_slug, project_prefix, workspace (UUID, exact name, or workspace ticket prefix), workspace_id/team_id, is_epic, type, severity, status, resolution, root_cause, or reporter_user_id. The search filter searches report text; digits-only input such as 366 is an exact lookup against both legacy and project ticket numbers, so unrelated text containing those digits is excluded. Each result includes tenant-scoped people/project identifiers plus is_epic, parent_epic_id, parent_epic, and bounded epic_progress. Report-read tools do not expose member email addresses.
• 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). Automatically scoped to your workspace — returns tickets across all projects in your team with status new, awaiting-triage, or confirmed and severity S1-S3. Read-only — does not atomically claim tickets. Optional severity (single tier), limit (1-50, default 1). Returns an object with count and bugs; each bug is a reduced queue row rather than the full list_bug_reports shape. Pair with claim_bug for the read-then-claim pattern.
• claim_bug — Atomically transition a bug from status new, awaiting-triage, or confirmed 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. Successful responses include reporter_user_id, reporter_name, assigned_to, and assignee_name. 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 UUID or workspace/project short ID. Returns the standard people/project/quality fields plus is_epic, parent identity, aggregate progress, and a bounded first child page for Epics.
• list_epic_children — Paginate an Epic's child reports with id, limit (1–100), and offset. Returns children, total, has_more, and SQL-aggregated epic_progress without loading every child report.
• update_bug_report — Update standard report fields plus is_epic and parent_epic_id. Pass parent_epic_id: null to detach; reparent/detach is atomic and requires same-workspace, same-project authorization. Promoting to an Epic detaches an existing parent, while an Epic with children cannot be demoted. Existing status/resolution/root-cause and assignment notification rules still apply. A status change on a Jira-linked report is mirrored to the Jira issue via its workflow transitions when exactly one legal transition matches the mapped status; otherwise the issue is left untouched.
• 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.
• link_bug_reports — Create a directional semantic link between two reports in the same authorized project. For parent-of, the from-report must be an Epic and the to-report a standard child. Prefer parent_epic_id on create/update for Epic assignment.
• unlink_bug_reports — Remove a previously-created bug-report link by its UUID (link_id, returned by link_bug_reports or list_bug_report_links).
• list_bug_report_links — List every user-curated link touching a bug report. Returns each link as it reads from the supplied report's perspective — e.g. a stored duplicate-of row where this report is the target renders as duplicated-by; parent-of where this report is the target renders as subtask-of; depends-on where this report is the target renders as blocks; testing-blocked-by where this report is the target renders as blocks-testing. related-to is symmetric. Complements the auto-detected similar_reports field returned by get_bug_report.
• 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. API-key callers require usage:read.
• get_stats — Daily counts, type/severity/status breakdowns

Project Management

• list_projects — List accessible projects with id, name, slug, ticket_prefix, description, and default status. Use those values with bug-report and test-catalog tools to target the correct project.
• 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
• export_okf_bundle — Export a project’s QA knowledge — bug reports, test cases, automations, and performance, security, and exploratory tests — as an OKF/OQA markdown bundle (the Open Query Agent format used by oqa.ai). Defaults to the active project; pass the optional project (slug or name) to export a different one. Returns the list of files in the bundle plus the bundle itself as a base64-encoded zip

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 — Read profile and notification preferences.
• update_settings — Update supported profile and notification preferences. OAuth-only mutation.

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

Jira Cloud report sync is included on Free and Enterprise. A workspace manager must first connect Jira in the dashboard. Workspace API keys can then use jira:read for comparison and jira:write for sync/merge; Atlassian plan and API limits still apply.

• sync_to_jira — Push a report to Jira using the team's shared connection. Routes to the Jira project mapped to the report's bugAgent project (workspace default as fallback), and translates severity through that project's field map. Optional projectKey overrides the routing. You usually don't need this: when the project's sync mode is auto_new or auto_all, reports you create are pushed automatically — call it for a manual push in manual mode, or to target a specific project.
• check_jira_sync — Compare a linked report against its Jira issue (title, severity, status, type) and list new Jira comments. Read-only; run it before merging.
• merge_jira_sync — Bi-directional merge for one linked report. Severity is last-updated-wins; comments and attachments sync both ways; nothing is deleted on either side.
• 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 — Get the sales-assisted Enterprise enrollment link

Performance Testing

• create_performance_test — Create a performance test config with URL, device, virtual users, duration, score threshold, and auto-bug creation toggle. Enterprise only
• run_performance_test — Trigger a page audit and load test for a web performance test. Returns a run ID to poll for results. Mobile app profiling runs are triggered from the dashboard
• 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. Performance testing is Enterprise-only. Free=0, Enterprise=unlimited

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. Enterprise 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. Security scanning is Enterprise-only. Enterprise=unlimited
• 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; 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. 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. AI code review is Enterprise-only; unlimited on Enterprise
• 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, 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, safe authentication metadata, and recent runs. Passwords and ciphertext are never returned.
• 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. Exploratory AI is Enterprise-only; Enterprise: unlimited (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, project, visibility, folder, tag, archive, wiki, date-range, and sort filters. Returns notes the user owns or notes shared with them.
• create_note — Create a note in one of 5 formats: markdown, plain, bugtemplate, 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.
• list_note_folders — List note/wiki folders, optionally scoped to a project.
• create_note_folder — Create a project-scoped note/wiki folder with optional parent, visibility, favorite, and teammate access settings.

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. 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. Self-healing locators (automatic): when a locator action times out, the runner asks Claude for a working selector and retries the step once — assertions are never healed, so real regressions still fail — and each heal is logged in the run stdout. 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: inspect script_versions with get_automation, then pass the preferred durable version_label (for example "v103"). Legacy version_index remains supported but must not be combined with version_label. Default: when both selectors are omitted, the current live script runs. Pruned labels and invalid indices are rejected instead of silently running current. 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 optional device, timezone, failure notification, email, and Slack channel settings.
• 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 and cron_expression; devices is optional.
• 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 100 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). Enterprise 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). Enterprise plan only.
• update_time_entry — Update an existing time entry. Requires id. Can update description, category, duration_minutes, project_id, or entry_date. Enterprise plan only.
• delete_time_entry — Permanently delete a time entry. Requires id. Enterprise 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

Test management with hierarchical folders, nested suites (up to 3 levels deep with sub-suite auto-expansion on runs), drag-drop reorder, 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.

Free limits: 10 stored test cases, 1 suite, 3 folders, 128 KB of structured content per case, 2 active workspace API keys, and 10 total test runs per UTC calendar month. Up to 3 of those runs may use Hermes or another external agent, with 1 active external run and at most 10 cases in each external plan. Free API-key MCP traffic is limited to 30 requests per key and 60 per workspace per minute. Enterprise test case storage and runs are unlimited, subject to general platform protections.

AI test-case generation, AI tag suggestions, Figma import, and test-case file attachments require Enterprise. The 128 KB Free structured-content bound is separate from Enterprise file attachments. Free can store URL references. Core MCP test-case tools remain available on Free within the limits above.

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 accessible test cases with an optional project selector plus search, priority, type, status, and sort filters. API-key callers require test_cases:read.
• create_test_case — Create a test case in the required project selector (UUID, slug, exact name, or ticket prefix; call list_projects first). 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. Optional urls array (max 10 http/https URLs) attaches reference links and is available on Free. File attachments require Enterprise and a dashboard session. API-key callers require test_cases:write.
• get_test_case — Get full test case details including steps and execution history.
• list_test_case_folders — List accessible folders. Capped at 500; accepts a flexible project selector and parent_folder_id filter (use "root" for top-level only). API-key callers require test_cases:read.
• create_test_case_folder — Create a folder in the required project returned by list_projects (nests up to 3 levels via parent_folder_id). API-key callers require test_cases:write.
• 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 (Enterprise) (dashboard session only): 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.

Suites & Runs

• list_test_suites — List accessible test suites with an optional flexible project filter. API-key callers require test_runs:read for backward compatibility with execution workers.
• create_test_suite — Create a suite in the required project returned by list_projects. Nests up to 3 levels via parent_suite_id. API-key callers require test_cases:write.
• list_test_runs — List test runs with suite name, assignee, and pass/fail summary.
• create_test_run — Create a dashboard-managed suite 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.

External Agent Execution

These tools let Hermes or another agent runtime execute an approved suite without becoming the QA system of record. Use a workspace-scoped key with only test_runs:read and test_runs:write. The suite supplies the project boundary; callers cannot override it.

• start_test_plan — Start or resume an immutable suite snapshot with a stable external_run_id. A repeated ID returns the existing matching run and first page instead of creating a duplicate.
• get_test_run_plan — Read canonical run state and a stable plan page. Pass the previous next_cursor; pages default to 100 cases and are capped at 200.
• report_test_results — Submit 1–200 results with passed, failed, blocked, or skipped status. Exact retries are safe; trying to overwrite a case with another status is rejected.
• abort_test_run — Idempotently stop an interrupted run while preserving accepted partial results and the canonical summary.

Quota behavior: retry start_test_plan with the same external_run_id to resume the matching run without consuming another run. Deleting data does not reset monthly run usage.

Runtime boundary: case snapshots exclude credentials, file bodies, and private attachment paths. Result evidence is text in the MVP. Target credentials stay in the execution runtime. Browser, model, and network costs remain customer-side, and customers must restrict target access and network egress. A human remains responsible for defect and release decisions.

The Hermes Agent guide packages this loop as a bugAgent-maintained community skill. The public starter kit contains a copy-ready config and installable skill. It is not an official Nous Research integration.

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 → create a human/dashboard-managed run from a parent suite — sub-suites auto-included
5. start_test_plan → start or resume a retry-safe external-agent run
6. get_test_run_plan → retrieve every immutable plan page, then execute it in the selected runtime
7. report_test_results → return bounded result batches; call abort_test_run if execution cannot continue safely
8. get_test_reports_failures → ask "what to fix this week?" once the run completes
9. 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. Available on the Enterprise plan. 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_bug_reports → review reports filed by booster testers

Mobile Testing (Enterprise)

Mobile resources are project-scoped. Pass project_id or a flexible project selector on creates, imports, and filtered lists. Automations inherit the linked app’s project; otherwise the server uses the workspace default project. Unfiltered lists may still include legacy workspace-level rows until they are migrated.

• list_mobile_apps — List uploaded apps with optional project_id/project, platform, and limit filters. Returns each app’s project_id so agents can keep subsequent operations in the same project.
• upload_mobile_app — Register an APK (Android) or IPA (iOS) app for testing on real devices. Requires name, platform (android/ios), and file_url; pass project_id to assign it to the active project. For iOS, upload the IPA for real-device runs, then use the dashboard to upload a simulator .app build for 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. Private linked login profiles require their active creator; shared profiles require active access to the same project. Schedules inherit the protected automation default.
• list_mobile_automations — List mobile automations with optional project_id/project, app_id, status, and limit filters. Results include project_id and the linked app ID.
• 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; pass project_id when the app is not already project-scoped. For one externally validated, self-contained Maestro YAML flow, set execution_mode to browserstack_maestro; otherwise it defaults to appium_actions. The YAML appId must match the linked app’s stored package or bundle ID; if none is stored, the first validated native flow establishes it. Placeholder app IDs and obfuscated Android resource IDs are rejected. Inline runFlow is supported, but external flow/script file references are rejected in v1. Native Maestro preserves commands such as inputRandomText and copyTextFrom plus runtime expressions such as ${maestro.copiedText} and ${output.value}. A same-project credential_id may supply complete inputText values of ${USERNAME}/${PASSWORD}. A same-project variable_profile_id may save the default for referenced ${DATA_*} values; every referenced key must exist. Data profiles are non-secret synthetic data only.
• import_mobile_script — Import an existing mobile test script and turn it into a runnable automation, preserving the developer’s own locators so runs resolve elements precisely. Supported dialects: Appium‑Python, WebdriverIO, Maestro (YAML flows), and Playwright (mobile‑web). Obfuscated Android resource-ID placeholders are skipped and reported in selector-mapping warnings. Android apps only. Requires name, app_id, and script; optional target_devices and project_id. Returns the automation plus action_count, detected dialect, and selector-mapping warnings.
• run_mobile_automation — Start a mobile automation on a real device. Requires automation_id; optional device, os_version, credential_id, and native-Maestro variable_profile_id. For data, omit variable_profile_id to inherit the automation default, pass null to use no profile, or pass a same-project UUID to override. Every referenced ${DATA_*} key must exist. A private login profile requires its active creator; a shared login profile requires active same-project access. Exact known credential values are filtered and exact data-profile values receive best-effort filtering from persisted textual evidence; transformed, partial, encoded, or app-derived data values may remain. Authorized private video/screenshots remain available and may show values rendered by the tested app, so data profiles must contain only synthetic non-secret values. If credential redaction context is unavailable or sanitization cannot be proven safe, detailed credentialed text is withheld while status and available visual evidence remain. Diagnostics require workspace and project authorization; media links expire after five minutes.
• list_mobile_runs — Get authorized mobile run results (status, device, result summary, private video and screenshot links, BrowserStack session, filtered credentialed native Maestro logs and failures when safely available, and any auto-created bug). Workspace membership and project access are enforced for run diagnostics. Optional filters: project_id, automation_id, status (queued, running, passed, failed, error, archived), and limit. Archived runs are excluded by default.
• create_login_profile — Create a write-only encrypted username/password profile reusable by Mobile, Web Automation, and Exploratory AI. Requires project_id, name, username, and password; optional visibility is private (default) or shared. Private profiles are creator-only. Shared profiles are usable by active members with access to the same project.
• create_mobile_credential — Compatibility name for create_login_profile; uses the same inputs and security boundary.
• list_login_profiles — List only profiles visible to the caller, optionally for one project_id. Returns non-secret metadata including visibility; private profiles owned by other users and inaccessible projects are omitted.
• list_mobile_credentials — Compatibility name for list_login_profiles; never returns credential secrets.
• update_login_profile — Rename, rotate, or change visibility. The active creator may update any field. An active workspace owner/admin may rename or rotate a shared profile but cannot change visibility; private profiles remain creator-only.
• update_mobile_credential — Compatibility name for update_login_profile; uses the same ownership and project checks.
• delete_login_profile — Creator soft delete, with owner/admin lifecycle recovery for shared profiles only. Future-use defaults are cleared while audit history remains.
• delete_mobile_credential — Compatibility name for delete_login_profile; historical references remain for audit.
• create_mobile_variable_profile — Create reusable, project-scoped synthetic test data with project_id, name, and a variables object such as {"DATA_EMAIL":"qa@example.test","DATA_REGION":"ca"}. Keys must be uppercase DATA_* identifiers. Profiles allow 1–100 strings, 4096 UTF-8 bytes per value, and 65536 bytes total. Reserved credential/runtime names are rejected. Never store credentials, tokens, production personal data, or other secrets.
• list_mobile_variable_profiles — List profiles and their readable non-secret values for one authorized project_id. Project assignment rules apply.
• update_mobile_variable_profile — Rename a profile or replace its complete variables object by id. Only the active creator or an active workspace owner/admin may update it.
• delete_mobile_variable_profile — Soft-delete a profile by id. Only the active creator or an active workspace owner/admin may delete it; automation defaults are cleared while historical run references remain.
• list_mobile_schedules, create_mobile_schedule, delete_mobile_schedule — List, create, and remove real-device schedules. Schedules inherit project context, login profile, and non-secret variable profile from their selected automation. Private login profiles require their active creator; shared login profiles require active same-project access. Non-secret variable profiles retain their creator-or-owner/admin policy. Schedule changes and deletion are restricted to the active schedule creator or an active workspace owner/admin.

Example Workflow — Android

1. list_projects → resolve the target project_id
2. upload_mobile_app → register the APK in that project
3. Record securely in the dashboard, or use import_mobile_script / create_mobile_automation
4. list_mobile_automations → resolve the automation in the same project
5. run_mobile_automation → trigger it on a real device, optionally with a login profile
6. list_mobile_runs → check status, result summary, private visual links, and BrowserStack session metadata
7. Failures auto-create bug reports with failure snapshot and step breakdown

Example Workflow — iOS

1. upload_mobile_app → register your IPA with project_id 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_automation → trigger the saved automation on an iPhone (uses the IPA)
5. update_mobile_app → replace IPA with new version when ready

Example Workflow — Native Maestro

1. upload_mobile_app → register the APK or IPA in the target project
2. create_mobile_credential → optionally create a same-project profile for an authenticated flow
3. create_mobile_variable_profile → optionally create same-project synthetic DATA_* values used by the flow
4. create_mobile_automation → pass one known-working YAML flow with the linked app’s exact package/bundle appId, script_type: maestro, and execution_mode: browserstack_maestro. Use ${USERNAME}/${PASSWORD} for login and ${DATA_EMAIL}-style placeholders for synthetic input; pass profile IDs to save defaults.
5. run_mobile_automation → select a compatible device and optionally override the login or variable profile. Omit the variable profile to inherit, or pass null to disable it for one run.
6. list_mobile_runs → inspect authorized pass/fail summaries, private video/screenshots, filtered logs, real step names, detailed failures, and session metadata. If safe sanitization cannot be established for a credentialed run, detailed text is withheld while status and available visual evidence remain.

Refine with AI: the allowlisted beta is available through the dashboard and REST refinement endpoints. No Refine MCP tools are part of the public catalog yet.

Compliance & Evidence (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.