dotnet-coverage-mcp

An MCP (Model Context Protocol) server that gives AI assistants — Claude Code, Gemini CLI, and others — direct access to .NET test-coverage tooling. Run dotnet test, parse Cobertura XML, identify uncovered branches, diff coverage between runs, and append test code — all over stdio.

Purpose

This server lets an AI assistant run unit tests, collect coverage data, and analyse results — all without leaving the chat. Instead of manually running dotnet test and parsing reports, the AI can call the server's tools directly to:

• Discover source files and build smart batches by line budget
• Run a filtered set of tests and collect coverage
• Read compact, AI-optimised coverage summaries (method-level line/branch rates)
• Check per-file coverage against a configurable target rate (default 80%)
• Identify uncovered branches as structured JSON
• Diff coverage between runs to see only what changed
• Append new test code to an existing test file with atomic writes

How It Works

The server starts as a console process and communicates over stdio using the MCP protocol. An MCP-compatible client (Claude Code, Gemini CLI, etc.) launches the process and calls its tools as if they were functions.

AI Client  <--stdio/MCP-->  dotnet-coverage-mcp  <--shell-->  dotnet test + reportgenerator

Available Tools

Batch Workflow

For projects with many source files, the recommended workflow is:

1. Discover — Call GetSourceFiles on a folder or .csproj to get all files and smart batches
2. Run once — Call RunTestsWithCoverage with a broad filter (e.g., *) to collect coverage across all files
3. Check per-file — Call GetFileCoverage for each file in the current batch (instant XML parsing, no test re-run)
4. Focus — Pick the 3 lowest branch-coverage methods and call GetUncoveredBranches for each
5. Write tests — Use AppendTestCode to add test methods
6. Re-run and diff — Run tests once, call GetCoverageDiff to verify improvement
7. Repeat — Continue until batch files meet the target rate (default 80%) or 3 cycles with no improvement, then move to next batch

This minimises dotnet test invocations (the main bottleneck) while still tracking per-file progress.

Concurrency

Multiple AI agents can safely run in parallel against the same repository by passing a sessionId to each tool call:

• Isolated output directories — RunTestsWithCoverage creates TestResults-{hash}/ and coveragereport-{hash}/ per session, preventing one agent from deleting another's XML mid-parse
• Scoped state files — Coverage state is written to .mcp-coverage/.coverage-state-{hash}, so ResolveCoberturaPath resolves to the correct XML for each session
• Scoped baselines — GetCoverageDiff stores baselines as .coverage-prev-{hash}.xml per session
• Atomic writes — All file writes (state files and test code) use write-to-temp-then-rename to prevent corruption from race conditions or process crashes

Without sessionId, tools use shared defaults — safe for single-agent use.

Requirements

• .NET 9.0 SDK (or later) — https://dotnet.microsoft.com/download

• reportgenerator global tool — install once:

  dotnet tool install --global dotnet-reportgenerator-globaltool
  

• An MCP-compatible client (Claude Code, Gemini CLI, etc.)

• COVERAGE_MCP_ALLOWED_ROOT — recommended. Set to your repository root to restrict every tool's filesystem access to that subtree. Any path passed by the client outside this root is rejected with pathNotAllowed. When unset, the server logs a warning once and accepts any path (backward-compatible, but not recommended for shared environments).

  export COVERAGE_MCP_ALLOWED_ROOT=/path/to/your/repo
  

Install

The recommended way to install is as a global .NET tool from NuGet:

dotnet tool install --global dotnet-coverage-mcp

After install, the dotnet-coverage-mcp command is on your PATH.

Build & Run (from source)

cd <path-to-dotnet-coverage-mcp>

# Restore dependencies
dotnet restore

# Build
dotnet build

# Run
dotnet run

The server will start and wait for MCP messages over stdin/stdout.

MCP Client Configuration

If you installed via dotnet tool, point your MCP client at the global command:

{
  "mcpServers": {
    "coverage": {
      "command": "dotnet-coverage-mcp",
      "transport": "stdio",
      "env": {
        "COVERAGE_MCP_ALLOWED_ROOT": "/path/to/your/repo"
      }
    }
  }
}

To run from source instead, use dotnet run:

{
  "mcpServers": {
    "coverage": {
      "command": "dotnet",
      "args": ["run", "--project", "<path-to-dotnet-coverage-mcp>"],
      "transport": "stdio"
    }
  }
}

Or point directly at the compiled executable:

{
  "mcpServers": {
    "coverage": {
      "command": "<path-to-dotnet-coverage-mcp>\\bin\\Debug\\net9.0\\DotNetCoverageMcp.exe",
      "transport": "stdio"
    }
  }
}

Tool Parameters

GetSourceFiles

RunTestsWithCoverage

GetCoverageSummary

GetFileCoverage

GetUncoveredBranches

GetCoverageDiff

AppendTestCode

CleanupSession

State Files

All state files are written to a .mcp-coverage/ subdirectory inside the working directory, keeping the project root clean. Add .mcp-coverage/ to the target repository's .gitignore.

Plugin (Skills & Agent)

This repo includes a plugin/ directory with Claude Code skills and an agent definition for guided test coverage workflows:

plugin/
├── plugin.json
├── agents/
│   └── test-coverage.agent.md
└── skills/
    ├── scaffold-test-files/     — Create test directories and files mirroring source structure
    ├── run-coverage/            — Run tests and view coverage reports
    ├── analyze-coverage-gaps/   — Find uncovered branches and compare diffs
    └── improve-test-coverage/   — Iterative loop to reach 80% coverage

The skills support NUnit, xUnit, and MSTest with framework-agnostic reference docs in references/unit.md and references/integration.md.

Dependencies

Security

dotnet-coverage-mcp runs as a local stdio process and validates every tool argument against COVERAGE_MCP_ALLOWED_ROOT to confine filesystem access. See SECURITY.md for the threat model, hardening recommendations, and how to report a vulnerability.

Contributing

Contributions are welcome. See CONTRIBUTING.md for development setup, pull request guidelines, and code conventions. Notable changes are tracked in CHANGELOG.md.

Releasing (maintainer notes)

Releases are automated via .github/workflows/release.yml, which fires on any v*.*.* tag.

One-time setup:

1. Generate a NuGet API key at https://www.nuget.org/account/apikeys.
2. Add it as repo secret NUGET_API_KEY (Settings → Secrets and variables → Actions).

To cut a release:

# Update "version" in server.json (both the top-level and packages[0])
# to match the tag you are about to push, then:
git commit -am "Release vX.Y.Z"
git tag vX.Y.Z
git push origin main --tags

The package version is injected from the git tag via -p:Version= in the release workflow, so there is no <Version> element to edit in the csproj.

The workflow builds, tests, packs, pushes the package to NuGet, and creates a GitHub Release with auto-generated notes.

Submitting to the MCP registry

After NuGet has indexed the new version (5–15 minutes — verify by visiting https://www.nuget.org/packages/dotnet-coverage-mcp/<version>), publish to the official MCP registry with the mcp-publisher CLI:

# macOS
brew install mcp-publisher
# Linux/Windows: download the binary from
# https://github.com/modelcontextprotocol/registry/releases
# and put it on your PATH

mcp-publisher login github     # opens device-code OAuth in your browser
mcp-publisher validate         # sanity-checks server.json against the schema
mcp-publisher publish          # submits the local server.json

The registry verifies NuGet package ownership by scanning the published package's README for the literal marker mcp-name: <namespace>/<server> (already present in this repo's README near the top). If you fork or rename, update that marker to match your server.json name field, otherwise the publish will fail with a 400.

The name field in server.json is also case-sensitive — it must match your GitHub username's casing exactly (e.g. io.github.Hyeonu-Cha/..., not io.github.hyeonu-cha/...).