Starter prompts for the mabl MCP

For the full index of agent-friendly pages, see llms.txt.

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:

Use this table of contents to skip ahead to the workflow you want to try:


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:


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:

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:

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:


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:

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:

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:

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:

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.