qa-metrics-mcp
Analyzes JUnit XML test reports to answer QA questions about runs, regressions, flaky tests, and quality trends.
List test runs with build, commit, date, and pass rate (
list_runs)Summarize a run: totals, per-suite breakdown, failures, skips (
get_run_summary)Chart pass-rate trends overall or per suite (
get_pass_rate_trend)Detect flaky tests with scores, timelines, and suggested fixes, excluding outage-caused failures (
find_flaky_tests)Find regressions pinned to the build/commit that broke them (
detect_regressions)Diff two runs: newly failing, fixed, added/removed, slower (
compare_runs)Cluster failures by normalized root cause and classify them (outage, defect, intermittent, one-off) (
get_failure_clusters)Identify slowest tests and performance degradation (
get_slowest_tests)Show run-by-run history for any test (
get_test_history)Generate a markdown QA health report for Slack/Confluence/Jira (
generate_quality_report)Export a self-contained HTML dashboard (
export_dashboard)
Reads JUnit XML test report artifacts from Bamboo CI to provide QA metrics such as pass rates, flaky tests, and regressions.
Parses JUnit XML reports generated by Cypress to analyze test results, flakiness, and failures.
Reads JUnit XML test report artifacts from GitHub Actions workflows to surface CI test metrics and trends.
Reads JUnit XML test report artifacts from GitLab CI pipelines to analyze test suite health and detect regressions.
Parses JUnit XML reports produced by Gradle test tasks to provide QA metrics like pass rates and failure clusters.
Reads JUnit XML test report artifacts from Jenkins jobs to analyze test results and identify flaky tests.
Parses JUnit XML reports generated by Jest (via jest-junit) to provide test suite analytics and regression detection.
Parses JUnit XML reports generated by pytest (via --junitxml) to provide QA metrics and test history analysis.
Parses JUnit XML reports generated by Vitest to analyze test results, trends, and performance drift.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@qa-metrics-mcp What broke in last night's run and which commit caused it?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
qa-metrics-mcp
Ask your AI assistant about your test suite in plain English, and get answers straight from your CI test reports.
qa-metrics-mcp is a Model Context Protocol server that turns JUnit XML test reports into QA metrics Claude, Cursor, or any MCP client can query:
*"What broke in last night's run, and which commit caused it?"* *"Which tests are flaky, and how should we fix them?"* *"Write the nightly QA summary for Slack."* *"Build me a dashboard for the last two weeks."*
No dashboards to log into, no spreadsheets to update by hand. The assistant calls the tools, reads the numbers, and explains them. ##Demo https://github.com/user-attachments/assets/6e7a83ce-0a69-40ab-8ac8-efbc7a57034e 
Why this exists
Every QA team I've led spent hours a week on the same work: scrolling CI logs to tell a real regression from a flaky test, figuring out which build introduced a failure, and writing the same status update every morning. This server automates that triage so engineers spend their time fixing issues, not finding them.
Related MCP server: Tesults MCP
What it does
Tool | What it answers |
| What runs do we have? Builds, commits, dates, pass rates. |
| How did a run go? Totals, per-suite breakdown, every failure and skip. |
| Is quality getting better or worse? Overall or per suite. |
| Which tests flip between pass and fail, how badly, and what's the likely fix? |
| What was stable and is now broken, and which build and commit broke it? |
| What changed between two runs? Newly failing, fixed, slower, added, removed. |
| Which failures share a root cause? Classified as outage, defect, intermittent, or one-off. A starting point for RCA. |
| Where is the suite slow, and which tests are getting slower over time? |
| Full run-by-run history for any test. |
| A complete markdown QA health report, ready for Slack, Confluence, or Jira. |
| A self-contained HTML dashboard (light and dark mode, no external dependencies). |
Plus a nightly\_triage prompt that chains the tools into a full morning triage: executive summary, regressions with draft bug titles, flakes to quarantine, and incidents for DevOps.
The smart parts
Outages don't pollute flake scores. When one error signature hits 3+ tests in the same run (for example, a downstream service was down), those failures are marked as an environment incident and excluded from flakiness scoring. Healthy tests don't get blamed for a bad night.
Failures are clustered by root cause, not exact text. Messages are normalized (numbers, IDs, UUIDs, and quoted values stripped), so
Timeout 15000msandTimeout 30000mson the same locator group together.Regressions are pinned to a commit. Related breakages that started in the same build are grouped as one incident with the first bad build, its commit, and the last good build.
Flaky tests get a suggested fix based on the failure pattern: timeouts, detached/stale elements, or intermittent downstream dependencies.
Performance drift detection compares early-window vs recent-window runtimes and flags tests that are degrading.
Works with your existing reports
Point it at any folder of JUnit-format XML. That covers most of the ecosystem:
Java: Maven Surefire / Failsafe, TestNG, Gradle
JavaScript/TypeScript: Playwright, Cypress, Jest (
jest-junit), VitestPython: pytest (
--junitxml)CI: GitLab CI test report artifacts, Jenkins, GitHub Actions, Bamboo
Build metadata (build number, commit, branch, environment) is read from <properties> when present. Reports are re-read on every call, so new nightly artifacts show up without restarting the server.
Quick start
git clone https://github.com/Misfit1982/qa-metrics-mcp.git
cd qa-metrics-mcp
npm install # also compiles TypeScript to dist/
npm run smoke # end-to-end test over real MCP stdioThe repo ships with 14 nightly runs of synthetic data for a fictional e-commerce app, with known problems planted in it, so every tool has something to find out of the box.
Connect to Claude Code
claude mcp add qa-metrics -- node /absolute/path/to/qa-metrics-mcp/dist/server.jsConnect to Claude Desktop
Add to claude\_desktop\_config.json:
{
"mcpServers": {
"qa-metrics": {
"command": "node",
"args": \["/absolute/path/to/qa-metrics-mcp/dist/server.js"],
"env": { "QA\_REPORTS\_DIR": "/absolute/path/to/your/junit-reports" }
}
}
}Connect to Cursor
Add the same block to .cursor/mcp.json in your project (or the global Cursor MCP settings).
Configuration
Variable | Default | Purpose |
|
| Folder of JUnit XML reports |
|
| Where |
Example session
**You:** Triage last night's run.
**Claude:** *(calls
compare\_runs,detect\_regressions,find\_flaky\_tests,get\_failure\_clusters)***Summary:** Pass rate is 90% (27/30). Two real regressions, both pricing-related, started in build 1210. Three flaky tests are adding noise.
**Regressions:** Introduced in build **1210** (commit
9f3c2ab). Last good: 1209.
ui.cart::apply\_coupon: cart total 89.99 vs expected 80.99 after SAVE10. *Draft bug: "Coupon discount not applied to cart total after pricing change in 9f3c2ab"*
ui.checkout::tax\_calculation: order total off by about $9.72. Likely the same pricing change.**Quarantine candidates:**
order\_webhook(intermittent 504s from downstream),autocomplete(detached element),shipping\_options(locator timeout).**For DevOps:** Build 1207 had an
inventory-svcoutage (ECONNREFUSED on 6 tests). Not a product defect.
See the full generated report in docs/sample-report.md.
Architecture
flowchart LR
CI\[CI pipeline<br/>GitLab / Jenkins / Actions] -->|JUnit XML artifacts| DIR\[(Reports folder)]
DIR --> P\[parser.ts<br/>JUnit → TestRun model]
P --> M\[metrics.ts<br/>flakes · regressions · clusters · trends]
M --> S\[server.ts<br/>11 MCP tools + triage prompt]
M --> D\[dashboard.ts<br/>HTML export]
S <-->|stdio / MCP| C\[Claude · Cursor · any MCP client]src/
parser.ts JUnit XML → normalized TestRun / TestCase model
metrics.ts Pure analysis functions (no I/O, easy to unit-test)
dashboard.ts Self-contained HTML dashboard renderer
server.ts MCP server: tool definitions, input validation (zod), error handling
scripts/
generate-sample-data.ts Deterministic synthetic data with planted issues
smoke-test.ts End-to-end test via the official MCP clientDesign choices:
Read-only by default. Every analysis tool is annotated
readOnlyHint. Onlyexport\_dashboardwrites a file, and only inside the output folder.Errors are tool errors, not crashes. A bad run ID returns a readable message the assistant can recover from.
Pure metrics layer. All analysis is side-effect-free, so it can be reused in a CLI, a CI step, or a different server.
Testing
npm run smoke launches the compiled server exactly the way Claude Desktop or Cursor does (stdio, official MCP SDK client) and asserts that every planted issue is found:
✓ exposes 11 tools
✓ find\_flaky\_tests finds the 3 planted flakes and ignores the outage
✓ detect\_regressions pins both pricing breaks to build 1210 / commit 9f3c2ab
✓ get\_failure\_clusters flags the build 1207 outage as environmental
✓ get\_slowest\_tests flags guest\_checkout degradation
...
All 14 checks passed.Roadmap
Pull reports directly from the GitLab / GitHub Actions APIs
Allure and TestNG native (
testng-results.xml) formatsPush the health report to Slack or Teams on a schedule
Companion servers: bug-report drafting (failure → Jira ticket) and RCA assistant (failure cluster + commits → 5-Whys write-up)
About
Built by Jared Hood, QA leader with 20 years in SaaS, fintech, and media QA (Selenium, Playwright, Tosca, RestAssured, GitLab CI, AWS). I build AI-assisted QA tooling: MCP servers, test automation frameworks, and reporting that turns test results into decisions.
All data in this repo is synthetic and describes a fictional application.
Available Tools
11 toolscompare_runsCompare two runsBRead-only
Diff two runs: newly failing, fixed, still failing, added/removed tests and significant duration changes. Defaults to previous vs latest.
Inputs: base, head.
detect_regressionsDetect regressionsARead-only
Find tests that were stable-passing and are now failing consistently. Groups them by the build/commit where they first broke, so you know what change to investigate.
Inputs: last_n, min_stable_passes, min_consecutive_fails.
export_dashboardExport HTML dashboardA
Write a self-contained HTML QA dashboard (KPI tiles, pass-rate and failure charts, regressions, flaky tests) to the output folder and return its path.
Inputs: last_n, filename.
find_flaky_testsFind flaky testsARead-only
Detect flaky tests: tests that flip between pass and fail across runs. Failures caused by a systemic outage in a single run (same error hitting 3+ tests) are excluded so outages don't masquerade as flakiness. Returns score, timeline, failure signatures and a suggested fix.
Inputs: last_n, min_flips, min_failures.
generate_quality_reportQA health reportARead-only
Markdown QA health report: summary, regressions with the commit that introduced them, flaky tests with fixes, environment incidents, performance drift and pass-rate trend. Ready to paste into Slack, Confluence or a Jira comment.
Inputs: last_n.
get_failure_clustersFailure clustersARead-only
Group failures by normalized root-cause signature (numbers, ids and quoted values stripped) and classify each cluster: environment outage, persistent defect, intermittent, or one-off. Useful as the starting point for an RCA.
Inputs: run, last_n.
get_pass_rate_trendPass-rate trendBRead-only
Pass rate per run over time, overall or for one suite (e.g. 'ui.checkout').
Inputs: suite, last_n.
get_run_summaryRun summaryBRead-only
Totals, pass rate, per-suite breakdown, every failure and skipped test for one run.
Inputs: run.
get_slowest_testsSlowest testsBRead-only
Slowest tests in the latest run with their duration trend across the window; flags performance degradation.
Inputs: top_n, last_n.
get_test_historyTest historyARead-only
Run-by-run history (status, duration, message) for tests whose id contains the query, e.g. 'apply_coupon' or 'ui.checkout'.
Inputs: test (required), last_n.
list_runsList test runsARead-only
List available test runs (oldest first) with build, commit, date and headline pass rate.
Inputs: last_n.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 11 tools
Each tool targets a distinct QA-metrics workflow: listing runs, summarizing a run, trending pass rates, finding flaky tests, detecting regressions, comparing runs, clustering failures, slow tests, test history, reporting, and dashboard export. Overlaps are minimal and descriptions clarify boundaries, such as flaky versus regression versus failure-cluster analysis.
All tool names use consistent snake_case with a verb_noun pattern (list_runs, get_run_summary, find_flaky_tests, detect_regressions, compare_runs, generate_quality_report, export_dashboard). The verbs vary appropriately by action while the naming convention remains predictable throughout.
Eleven tools is well-scoped for a QA metrics server, covering discovery, analysis, reporting, and export without obvious filler. Each tool has a clear role and there is no excessive surface area for the domain.
The surface covers the core QA metrics lifecycle: run listing, summaries, trends, flakiness, regressions, comparisons, failure clustering, slow tests, history, and report/dashboard outputs. Minor gaps may exist around direct suite-level listing or filtering controls, but agents can work around these using the existing tools.
Related MCP Connectors
Test analytics for AI agents: test history, flaky tests, failure clusters, coverage.
1No-code, AI-assisted UI testing: record new tests, run existing ones, and monitor the results.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Flaky test detection, root cause analysis, and fix suggestions for development teams.
Related MCP Servers
- FlicenseBqualityDmaintenanceProvides tools to analyze test failures, cluster similar failures, and detect flaky tests from input or log files, helping QA teams debug and triage issues.3-

Tesults MCPofficial
AlicenseNot gradedqualityCmaintenanceConnect AI agents to your test results, insights, and targets. Query test runs, failures, flaky tests, and regressions across frameworks including Playwright, Jest, Pytest, Cypress and more.46 npmMIT- AlicenseNot gradedqualityCmaintenanceEnables AI-driven triage of Allure test results by clustering failures into stable signatures and generating root-cause explanations, so you can turn large failing CI runs into a few actionable categories.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to answer QA questions in a single call, covering run reports, failure grouping by root cause, flaky versus regressed test detection, and coverage gaps. Also exposes raw TestRail API access when a question needs it.MIT