analyze-coverage-mcp
About
MCP server that bridges LCOV coverage reports to AI agents.
Details
- Author
- sofia-open-source
- Categories
- Developer Tools
Jump to
Setup
Install analyze-coverage-mcp in your MCP client (Claude Desktop, Cursor, Windsurf, and others).
Repository: https://github.com/sofia-open-source/analyze-coverage-mcp
Follow the installation instructions in the repository README, then restart your MCP client.
MCP server that bridges LCOV coverage reports to AI agents.
MCP server that bridges LCOV coverage reports to AI agents. It runs locally and gives agents precise, structured visibility into test coverage — which lines are hit, which branches are missed, and where to focus testing efforts.
LCOV is a standard text format for code coverage data. It records which lines, functions, and branches were executed during tests. The format is widely supported by test runners (Vitest, Jest, Istanbul, etc.) and is typically written tolcov.info. Each record describes coverage for a source file: line hits, branch hits, and function hits.
The server also watcheslcov.infofor changes (polling every 1 s) and auto-reloads — so coverage stays current while tests run in watch mode.
All MCP tools (get_coverage_overview,list_uncovered_regions,get_annotated_source) require these parameters in every call. They identify which coverage report to load and how to resolve source file paths.
The directory where tests run (thepackage root) must have this layout:
<package_root>/ ← same as project_root in single projects; in monorepos, parent of coverage/ (e.g. apps/app-api) ├── coverage/ │ └── lcov.info └── src/ └── ...
src/andcoverage/must be siblingsunder the package root. In single projects, pass that directory asproject_root. In monorepos,project_rootcan be the repo root; the MCP infers the package root from thelcov_pathlocation.
If your structure differs, usesource_rootoradditional_roots(seePath resolution and file locations).
{ "mcpServers": { "analyze-coverage": { "command": "npx", "args": [ "-y", "@sofia-open-source/analyze-coverage-mcp" ] } } }
pnpm bundle # generates js bundle in ./analyze-coverage-mcp with shebang node executable chmod +x ./analyze-coverage-mcp # make it executable cp ./analyze-coverage-mcp ~/.local/bin/analyze-coverage-mcp # available in $PATH
{ "mcpServers": { "analyze-coverage": { "command": "analyze-coverage-mcp" } } }
# Install dependencies pnpm install # Run in watch mode (no build needed) pnpm dev # Type-check and build pnpm build # Run tests pnpm test # Run tests with coverage pnpm test:coverage
- The agent callsget_coverage_overviewwithlcov_pathandproject_rootto load the report.
- The LCOV file is parsed in-memory into aMap<filename, FileCoverage>and cached.
- Subsequent tool calls reuse the cache (identified bylcov_path+project_root) or trigger a reload viarefresh_coverage.
- Source paths are resolved with fallbacks:project_root+ path, common prefix stripping (src/,lib/, etc.), and when lcov is incoverage/, the parent directory is used for monorepos. SeePath resolution and file locations.
The MCP server readslcov.infofiles. Here’s how to generate them with common test runners:
import { defineConfig } from 'vitest/config' export default defineConfig({ test: { coverage: { provider: 'v8', reporter: ['text', 'lcov'], reportsDirectory: './coverage', }, }, })
Install Istanbul (used by Jest for coverage):
Configurejest.config.jsorpackage.json:
{ "jest": { "collectCoverage": true, "coverageReporters": ["text", "lcov"], "coverageDirectory": "coverage" } }
{ "nyc": { "reporter": ["text", "lcov"], "report-dir": "coverage" } }
Output:./coverage/lcov.info(or.nyc_output/lcov.infodepending on config)
Most runners support LCOV via plugins or built-in options. Ensure the reporter outputslcovand that the path tolcov.infois passed aslcov_pathto the MCP tools.
- Vitest with@vitest/coverage-v8:<project>/coverage/lcov.info
- Jest with--coverage:<project>/coverage/lcov.info
- Istanbul/nyc:<project>/.nyc_output/lcov.info
SeeRequirementsfor parameter and structure requirements.
LCOV records store source file pathsrelative to the package that ran the tests. For example, if tests run fromapps/app-api, paths look likesrc/core/auth/service.ts, notapps/app-api/src/core/auth/service.ts.
In monorepos,project_rootis often the repo root (e.g./repo), but LCOV paths are relative to the package root (e.g.apps/app-api). The MCP handles this automatically:
- Whenlcov_pathis inside acoverage/directory (e.g.apps/app-api/coverage/lcov.info), theparent of that directoryis used as a fallback source root.
- Soproject_rootcan be the monorepo root; source files underapps/app-api/src/are still resolved correctly.
Example:lcov_path: /repo/apps/app-api/coverage/lcov.infowithproject_root: /repo→ sources resolve under/repo/apps/app-api/.
Forget_annotated_source, the MCP resolves LCOV paths to filesystem paths in this order:
- Absolute path— if the LCOV path is already absolute.
- source_root+ path— whensource_rootis provided (optional param).
- project_root+ path— e.g.project_root/src/foo.ts.
- Stripped prefixes— if the path containssrc/,lib/,dist/, orapp/, triesproject_root+ the path from that segment onward.
- additional_roots— for each root in this optional array, triesroot + path.
- Derived from lcov location— when lcov is incoverage/, tries the parent directory ofcoverage/as root.
Flexible overrides (get_annotated_source)
When the automatic heuristics fail, use these optional parameters:
Example:get_annotated_sourcewithsource_root: "/repo/apps/app-api"forces resolution under that directory, ignoringproject_rootfor that call.
Forlist_uncovered_regionsandget_annotated_source,file_pathcan be:
- Theexact pathas it appears in the LCOV report (e.g.src/core/auth/service.ts).
- Asuffixthat uniquely identifies the file (e.g.auth/service.tsorservice.ts).
- Afilenameif it is unique across the report (e.g.service.ts).
Useget_coverage_overviewto list available paths when unsure.
- Source file must exist on disk forget_annotated_source.That tool reads the source to annotate it. If resolution fails:"Source file not found on disk. Try setting project_root, source_root, or additional_roots to the directory containing your source files."list_uncovered_regionsonly uses coverage data and does not require the source file.
- Usesource_rootoradditional_rootswhen heuristics fail.When the automatic monorepo detection fails, passsource_rootwith the package root (e.g.apps/app-api), or useadditional_rootsto add extra search paths.
- Paths are case-sensitiveon most systems.
This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.
Uses TypeScript AST to determine which tests are affected by code changes
AI-Safe Code Analysis with 113+ MCP tools for guard validation, memory, workflow, and testing.
Structural code quality analysis for Python with baseline-aware CI governance, canonical reports, and a triage-first MCP control surface for agents and IDEs.
Prevents regression by providing Blast Radius data to AI based on your git history
A powerful Model Context Protocol (MCP) server that supercharges your Python development workflow with AI-powered code review, intelligent test generation, and comprehensive test execution.
Local MCP that allows your agent to keep track of code analysis coverage
Bring agent evaluations, observability, and synthetic test set generation directly into your IDE for free with Galileo's new MCP server
Browser automation via MCP for Chrome and Firefox
Bring the full power of BrowserStack’s Test Platform to your AI tools, making testing faster and easier for every developer and tester on your team.
Official Chrome DevTools MCP server for controlling and inspecting a live Chrome browser from coding agents such as Gemini, Claude, Cursor, and Copilot.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
