Tells AI agents which files to test first โ churn, coverage, and test mapping as risk scores.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent โ or use 1-click editor setup below.
๐ก Paste into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)
Give your AI coding agent the quality brain it doesn't have to grow from scratch.
QA Radar analyzes your codebase and produces a structured quality health report โ combining git churn, test coverage, and test-to-source mapping into risk-scored modules. It works as an MCP server for AI coding agents (Claude Code, Cursor, Windsurf) and as a standalone CLI for humans and CI pipelines.
Built for developers who want their AI agent to write targeted tests, not generic ones.
Claude Code โ one step:
Then ask your agent: "What should I test first?"
Or run directly without installing:
QA Radar answers the question every new team member (and every AI agent) asks: "What should I test first?"
It scans three signals and combines them into a per-file risk score:
| Signal | What It Measures | Why It Matters |
|---|---|---|
| Git Churn | Commit frequency, lines changed, recency | High-churn files are regression magnets |
| Coverage Gaps | Line & branch coverage from existing reports | Low coverage = blind spots |
| Test Mapping | Which source files have corresponding tests | No tests = no safety net at all |
The output is a ranked list of modules by risk level (critical โ low), with human-readable reasons for each rating.
A capable agent with bash access could run git log --numstat, parse coverage.xml, and glob for test files. So why an MCP server?
| Concern | What QA Radar does instead |
|---|---|
| Token cost | git log over 90 days on a medium repo is hundreds of KB. QA Radar returns ~5 KB of structured JSON. |
| Determinism | A weighted risk score computed ad-hoc in-context is unreliable. Code is reproducible. |
| Speed | One tool call vs. 4โ6 sequential bash calls + reasoning between each. |
| Format normalization | LCOV / Cobertura / coverage.py JSON / Go cover profiles all parse differently. QA Radar normalizes across formats so the agent doesn't have to. |
| Convention encoding | test_x.py for Python, x.test.ts for JS/TS, x_test.go for Go, FooTest.java for Java โ encoded once, not re-derived each session. |
| Portability | The same MCP tools work across Claude Code, Cursor, and Windsurf without re-prompting. |
The fastest path โ one command wires up the MCP server and installs 4 slash commands. No manual config editing.
Step 0 โ install uv (if you don't have it):
uv launches qaradar on demand from PyPI โ you don't need to pip install qaradar separately.
Step 1 โ add the marketplace:
Step 2 โ install:
What you get: 6 MCP tools auto-configured + 5 slash commands:
| Command | What it does |
|---|---|
/qaradar:qa-check | Full health report โ risk, coverage, untested files |
/qaradar:qa-risky | Ranked list of riskiest files with reasons |
/qaradar:qa-untested | Source files with no detected tests + scaffold suggestions |
/qaradar:qa-plan | Prioritized test plan (chains 3 tools) |
/qaradar:qa-pr-risk | Which changed files in this PR are riskiest |
Example: after merging a big feature branch, run /qaradar:qa-check to see what regressed. Before opening a PR, run /qaradar:qa-pr-risk to see what you need to test first.
Alternative: manual MCP config (if you prefer not to use the plugin):
Add to your Claude Code MCP config (~/.claude/mcp.json for user-level, or .mcp.json in the project root for project-level):
Or start it manually:
Once connected, ask your agent:
"What should I test first in this repo?" "Which files are the riskiest right now?" "Show me the highest-churn files from the last month." "Which source files have no tests at all?" "Which of my changed files are risky?" โ diff-aware
| Tool | When the Agent Uses It |
|---|---|
qaradar_healthcheck | Full quality overview of a repository |
qaradar_risky_modules | What to test first; which files are riskiest |
qaradar_churn | Hotspot detection; where regressions tend to occur |
qaradar_coverage_gaps | Files with low coverage; where the blind spots are |
qaradar_untested_files | Source files with no corresponding test files |
qaradar_pr_risk | Which changed files in this PR need attention |
qaradar_should_run | After finishing work: should QA Radar re-analyze, and over the diff or the whole repo? |
qaradar_pr_risk scores only the files changed between a base ref and HEAD โ not the whole repo. It keeps risk scores calibrated by using full-repo normalization, so a file with 2 commits in a PR isn't falsely flagged CRITICAL just because it's the only changed file the agent knows about.
Ask your agent:
"Which of my changed files are risky?" "Do any of the files I changed lack tests?" "What should I review before opening this PR?"
Or from the CLI:
qaradar_pr_risk auto-detects the base branch from GITHUB_BASE_REF (set automatically in GitHub Actions) or falls back to main/master. Pass base_ref explicitly to override.
Or run without installing:
From source (for development):
All language support lives in one registry โ qaradar/analyzers/languages.py โ so
adding a language is a single entry (extensions, test-name convention, test-function
counter), consumed by both churn and test-mapping.
| Language | Test detection | Coverage |
|---|---|---|
| Python | test_x.py, x_test.py | coverage.py JSON + XML |
| JavaScript / TypeScript | x.test.*, x.spec.*, x-test.* (React Native) | LCOV, Jest/Istanbul JSON |
| Go | x_test.go | Go cover profile (cover.out) |
| Swift | XTests.swift (XCTest func testโฆ) | Cobertura / LCOV |
| Kotlin | XTest.kt (@Test) | Cobertura / LCOV |
| Dart / Flutter | x_test.dart (test(, testWidgets() | LCOV (coverage/lcov.info) |
| Objective-C | XTests.m / .mm (XCTest - (void)testโฆ) | Cobertura / LCOV |
Java, Ruby, Rust โ test detection via naming conventions. Coverage via Cobertura XML or LCOV if emitted.
Coverage parsing is format-driven, so it spans more ecosystems than test-mapping detection, which is language-specific.
Monorepos: Istanbul/Jest reports are auto-discovered under packages/*/coverage and
apps/*/coverage, and absolute/package-relative coverage paths are normalized to
repo-relative so they join correctly against churn and test-mapping signals.
| Format | Tools |
|---|---|
| coverage.py JSON | Python coverage run + coverage json |
| Istanbul / Jest JSON | coverage-final.json, coverage-summary.json (Jest/Vitest/nyc) |
| Cobertura XML | Python, Java/Gradle, .NET (Coverlet) |
| LCOV | JS/TS, Flutter/Dart, C/C++, Rust (grcov) |
| Go cover profile | go test -coverprofile=cover.out |
By default QA Radar is stateless. Opt in to persistence to track a repo across runs and drive incremental re-analysis (daily/weekly, or after N diffs, or after an agent finishes work).
should-run is a gate, not a scheduler โ wire it into whatever you already use:
It reports scope: "full" (interval elapsed) or scope: "diff" (enough files changed),
so an agent calling the qaradar_should_run MCP tool knows whether to follow up with
qaradar_healthcheck or qaradar_pr_risk. State is one .qaradar/state.json per repo,
so a "collection of repos" is just a loop over repos in your own infra.
Tune the criteria in qaradar.toml:
--save also reports a delta vs the previous run โ which files newly became risky,
which got worse, which improved or resolved.
qaradar.toml), Tier 2 language validation, hardeningqaradar_pr_risk + --base CLI flagshould-run, --save, qaradar_should_run)QA Radar is built on three beliefs:
MIT
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/qa-radar)<a href="https://allmcps.com/mcp/qa-radar"><img src="https://allmcps.com/api/badge/qa-radar?style=directory" alt="QA Radar on AllMCPs" /></a>