The mabl MCP offers a large and growing set of capabilities. To navigate its tools more easily, this reference groups them into the handful of common workflows to help you get the most value. When using these prompts, keep in mind the following:
- These are starter prompts, not one-shot commands. The best results from the mabl MCP come from a back-and-forth: share your context and goal, review the agent's approach, and refine from there.
- Where a workflow includes a Combine with other MCPs note, it explains how to chain mabl together with the other tools your team already uses, such as an issue tracker, a design tool, or your codebase.
Use this table of contents to skip ahead to the workflow you want to try:
- Get oriented with the mabl MCP
- Create a new browser test from a requirement
- Check a test for coverage gaps against its requirement
- Map your mabl tests to Xray for compliance
- Run a test against a preview or branch URL before you ship
- Run a morning quality standup
- Deep-dive a single failing test with the evidence
- Triage a failed deployment while the PR is open
Get oriented with the mabl MCP
I just connected the mabl MCP server. What can you help me do? Show me a few example things I can ask, then list my workspaces, applications, and most recent test runs so I know what I'm working with.
What to expect: A quick orientation. The agent suggests a handful of example asks, then returns your workspaces, applications, and a snapshot of recent test runs. It's read-only, so nothing changes.
Where the conversation goes next:
- Drill into one workspace's recent activity
- Ask for example prompts tailored to your role (QA, developer, manager)
- Jump into any of the workflows below
Create a new browser test from a requirement
I want to create a new browser test for the [application name] app using the mabl MCP. The requirement is: [describe the feature or user journey to validate — or point me at it, e.g. "the acceptance criteria in Jira ticket MABL-1234"].
Before creating anything, walk me through how you'd test this end to end. If you're pulling from a ticket or doc, show me the criteria you extracted first so I can confirm. Let me know my options for test authoring and any other information that would help you produce the best test.
What to expect: mabl's test planning agent shapes the test intent and steps conversationally, working from what you describe or from a connected source like Jira. Once you confirm the plan, it hands off to an authoring session in the cloud or on your local Desktop App and gives you a task URL to watch it build.
Where the conversation goes next:
- Adjust the extracted criteria or plan before authoring starts
- Start the authoring session in the cloud (recommended) or locally
- Check authoring progress, then review and edit the generated test
Combine with other MCPs: Instead of describing the requirement, have the agent read it from the source. An issue-tracker MCP such as Atlassian/Jira (or Atlassian Rovo) pulls acceptance criteria from a ticket; a design MCP such as Figma pulls intended behavior from a spec; a docs MCP such as Confluence pulls it from a page. mabl alone can't read these — name the MCP you want it to use.
Check a test for coverage gaps against its requirement
Compare my [test name] test in the [workspace name] workspace against this requirement: [paste the requirement, or reference a Jira ticket ID]. Give me a structured coverage report that highlights what's covered, what's missing, and what I should add.
What to expect: A structured report showing what the test already covers, what the requirement asks for that the test is missing, and concrete steps or assertions to add. It's scoped to one test against one requirement, not a whole-workspace scan.
Where the conversation goes next:
- Have the agent add the missing steps to the test
- Re-run the coverage check after changes
- Compare a second test against the same requirement
Combine with other MCPs: Pull the requirement straight from your issue tracker (e.g. Atlassian/Jira) instead of pasting it, so the comparison always runs against the live requirement.
Map your mabl tests to Xray for compliance
List my mabl tests in the [workspace name] workspace and the Xray test cases in project [PROJ]. Map each mabl test to its matching Xray case, and flag any Xray cases that have no automated mabl coverage yet.
What to expect: The agent attempts to match your mabl tests to their corresponding Xray cases, apply those mappings, and surface any Xray cases that have no automated mabl coverage yet, providing a compliance gap view you can act on. Requires the Xray sync integration to be configured in the workspace.
Where the conversation goes next:
- Author tests for the uncovered Xray cases
- Adjust or confirm individual mappings
- Export the coverage view for an audit
Run a test against a preview or branch URL before you ship
Run my [test name] test in the cloud against my preview deployment at [https://pr-1234.preview.example.com] and tell me if it passes. Re-fetch the results rather than reusing anything from earlier. If it fails, analyze why.
What to expect: mabl runs the test in the cloud against your override URL and reports pass/fail. On failure, the agent pulls AI failure analysis automatically, so you can understand why without leaving your chat.
Where the conversation goes next:
- Override other settings for the run (browser, environment, credentials)
- Run a whole plan against the preview URL instead of one test
- Triage a failure in depth
Combine with other MCPs: Kick off the run automatically after a deploy step driven by your CI/CD MCP, or post the pass/fail summary to a chat MCP such as Slack.
Run a morning quality standup
Give me a 5-line standup for the [workspace name] workspace: what's running right now, what failed in the last 24 hours, which failures look like new regressions vs. known flaky, and the one thing I should look at first.
What to expect: A read-only digest of tests currently running, what failed in the last 24 hours, which failures look like new regressions vs. known-flaky, and a single "look here first" recommendation.
Where the conversation goes next:
- Deep-dive the "look here first" failure
- Expand the window to the last week
- Filter to a specific plan or environment
Combine with other MCPs: Have a chat MCP such as Slack post the standup to your team channel each morning.
Deep-dive a single failing test with the evidence
Test run [ID] failed. Run failure analysis with evidence, then pull the screenshot and DOM snapshot from the failing step and explain what went wrong in plain language. Was it the app, the test, the environment, or something else?
What to expect: mabl's AI failure analysis provides a synopsis, root cause, suggested next steps, and a plain-language verdict on whether it's an app bug, a test issue, or an environment problem.
Where the conversation goes next:
- Continue the analysis conversationally: "Dig into why the API call timed out"
- Pull more artifacts, such as screenshots, logs, and network data
- Apply the suggested fix and re-run
Combine with other MCPs: Once you agree on the root cause, have your issue-tracker MCP (e.g. Atlassian/Jira) open a bug with the analysis and a link to the run.
Triage a failed deployment while the PR is open
My latest mabl deployment for the [workspace name] workspace failed. Pull the failed tests, run mabl's AI failure analysis on each, and tell me whether each is a real regression or just flaky. For any real regression, look at my current branch diff and point me at the file most likely responsible. I'd rather fix it before I merge.
What to expect: Using mabl's AI failure analysis, the agent assesses whether each failure looks like a real regression or intermittent flakiness. When you run this inside your repo, it can also compare the evidence against your current branch diff to suggest the file most likely responsible, so you can fix it before merging.
Where the conversation goes next:
- Re-trigger the deployment once environmental issues are ruled out
- Deep-dive any single failure
- File a bug for a confirmed regression
Combine with other MCPs: If a failure is due to a regression, searching for related files requires that you work with a coding agent with your repo checked out. The failure triage itself works with the mabl MCP alone.