qa-metrics-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_OUTPUT_DIR | No | Where export_dashboard writes HTML | ./output |
| QA_REPORTS_DIR | No | Folder of JUnit XML reports | ./sample-data/reports |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_runsA | List available test runs (oldest first) with build, commit, date and headline pass rate. |
| get_run_summaryB | Totals, pass rate, per-suite breakdown, every failure and skipped test for one run. |
| get_pass_rate_trendB | Pass rate per run over time, overall or for one suite (e.g. 'ui.checkout'). |
| find_flaky_testsA | 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. |
| detect_regressionsA | 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. |
| compare_runsB | Diff two runs: newly failing, fixed, still failing, added/removed tests and significant duration changes. Defaults to previous vs latest. |
| get_failure_clustersA | 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. |
| get_slowest_testsB | Slowest tests in the latest run with their duration trend across the window; flags performance degradation. |
| get_test_historyA | Run-by-run history (status, duration, message) for tests whose id contains the query, e.g. 'apply_coupon' or 'ui.checkout'. |
| generate_quality_reportA | 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. |
| export_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| nightly_triage | Triage last night's run: what broke, why, who should look, and what to quarantine. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.