Skip to main content
Glama
ProgrammerDream

coverage-mcp

by ProgrammerDream
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

coverage-mcp

把 tool/ 那套 Bash + 内嵌 Python 的 JaCoCo 分支覆盖率能力，抽成 Python 全栈内核 + MCP server， 定位「Java 分支级、按测试类、能指到未覆盖行的 agent 覆盖率反馈器」，填补现有 MCP （test-coverage-mcp 只给%、se333 instruction/方法/全量）的精确缺口。

进度

  • M0 解析层 ✅ csv/xml/surefire + 未覆盖分支行，搬成可单测纯函数（对 optaplanner 真实报告快照锁定）。

  • M1 端到端 ✅ runner 复刻 maven 覆盖率链路；与 bash run-module-test.sh 对同一 case 逐字段一致（含未覆盖行）。

  • M2 MCP 壳 ✅ FastMCP 暴露 coverage_check，返回紧凑 JSON。

  • M3 按包自动收集 + JSON 瘦身 ✅ --package fanya/schedule 一条测整包；uncovered 的 file 相对模块路径省 token。

  • M4 去耦合 ✅ 砍掉对 tool/env.sh、git bash、IDEA 集成参数的依赖；maven 发现 + 配置走纯 Python（env.py + jacov.toml）；跨平台 subprocess 直调 mvn。已独立 git 仓 + CI + entry points。

Related MCP server: codecov-mcp-server

结构

src/jacov/
  model.py    数据模型 + 阈值兼容（80 / 0.8）
  jacoco.py   解析 jacoco.csv / jacoco.xml / surefire（对齐 run-module-test.sh 三段）
  runner.py   复刻 maven 覆盖率链路（复用 tool/env.sh 的 Maven 环境）
  check.py    编排 + 人读输出 + 结构化组装（check_coverage / build_result）
  server.py   FastMCP server（coverage_check 工具）
tests/        14 个用例（解析层 11 + 组装层 3），fixture 取自 optaplanner 真实报告

跑测试

cd coverage-mcp
python -m pytest -q          # 免安装（pyproject 配 pythonpath=src）

命令行用（人类用法）

适用于 PowerShell / CMD / Git Bash。命令一行写完最省事，不要用 bash 的 \ 换行。

第 0 步：装一次（只做一次）

pip install -e coverage-mcp

装完后 python -m jacov.check 在任何目录都能用——不用设 PYTHONPATH，也不用 cd 进 coverage-mcp。

最常用：测一个业务包（自动收集该包的测试类 + 业务类）

在项目根目录执行：

python -m jacov.check --module-dir fanyajwproject-course-v2\fanyajwproject-course-v2 --package fanya/schedule --min-branch 80

--package fanya/schedule 会自动找该包下所有 *Test.java 当测试、所有 .java 当业务类，不用手列一长串。

或者：手动指定测试类 / 业务类

python -m jacov.check --module-dir optaplanner-jxjy\optaplanner-jxjy --tests TeacherDayOfWeekParseStrategyTest --cover CommonMethods --min-branch 80

参数

参数

必填

含义

--module-dir

是

模块目录（含 pom.xml）；相对当前目录或绝对路径都行

--package

与 --tests 二选一

业务包（如 fanya/schedule），自动收集测试类 + 业务类

--tests

与 --package 二选一

测试类，逗号分隔（如 FooTest,BarTest）

--cover

否

卡覆盖率的业务类，逗号分隔；不填 = 整模块汇总

--min-branch

否

最低分支覆盖率，写 80 或 0.8；默认 0（只看不卡）

--no-compile

否

跳过编译（代码已编译时更快）

--no-reuse

否

每个测试类用独立 JVM（严格隔离，多测试类时慢）

看懂输出

测试结果汇总     → 总数 / 通过 / 失败
分支覆盖率汇总   → 每个业务类 [PASS/FAIL] 分支总数 / 已覆盖 / 未覆盖 / 覆盖率
未完全覆盖分支   → 文件:行号 + MISS（全没覆盖）/ PARTIAL（只覆盖一半）+ 源码

退出码：全通过且达标 = 0，否则 = 1（可用于 CI / 脚本判断成败）。

⚠️ PowerShell 用户注意

  • 别抄 bash 写法：PYTHONPATH=src python ...（PS 不支持这种前缀赋值）和行尾 \ 换行（PS 续行符是反引号 `）——都会报 Missing expression after unary operator '--'。

  • 装好包后一行命令最干净，什么前缀都不用加。

配置（jacov.toml，可选）

不放 jacov.toml 时走默认：maven 从 PATH / MAVEN_HOME 自动发现、JaCoCo 0.8.11、JDK17 add-opens、settings 和本地仓用 maven 默认（~/.m2）。

需要自定义时，把 jacov.example.toml 复制为 jacov.toml（已被 .gitignore，因含机器相关路径）：

[maven]
home = "/path/to/maven3"            # 本机没有 mvn/mvnw 时，指向 maven 安装根（其下有 bin/mvn）
settings = "/path/to/settings.xml"  # 私有仓 / 镜像 / 凭据
local_repo = "/path/to/.m2/repository"
[jacoco]
version = "0.8.11"
excludes = "com.sun.proxy.*"        # instrument 排除（动态代理类，避免污染覆盖率）
[test]
add_opens = ["java.base/java.lang"] # fork 测试 JVM 的 --add-opens（JDK17+）

查找顺序：从 --module-dir 上溯 → 包目录。

全量纯测试（像 Jenkins，不跑覆盖率）

只想跑测试看通过/失败、不要覆盖率（更快），用 jacov.runtests：

# 全量：模块下所有 *Test.java（相当于 mvn test）
python -m jacov.runtests --module-dir fanyajwproject-course-v2\fanyajwproject-course-v2

# 只测某个包 / 某几个类
python -m jacov.runtests --module-dir fanyajwproject-course-v2\fanyajwproject-course-v2 --package fanya/schedule
python -m jacov.runtests --module-dir fanyajwproject-course-v2\fanyajwproject-course-v2 --tests FooTest,BarTest

  • 跑的过程实时显示编译（Building/Compiling）和每个测试类（Running XxxTest / Tests run: N），不会静默——能看到跑到哪、卡在哪。

  • 结尾 Jenkins 式汇总：套件 / 用例 / 通过 / 失败 / 错误 / 跳过 + 失败套件清单；退出码 0（全过）/ 1（有失败）。

  • ⚠️ 全量可能慢（course-v2 ~1900 用例、~3 分钟，大头是少数连外部/DB 的集成测试）；只验证某块用 --package 秒级。

项目编译（Python 版）

jacov.compile 把旧 tool/compile.sh 的项目编译策略迁到 Python，适合 CLI 和 MCP 共用。

# 默认双层项目：clean → compile
python -m jacov.compile fanyajwproject-course-v2 --workspace-root C:\Users\lin\IdeaProjects

# shared-jar：clean → install -Dmaven.test.skip=true
python -m jacov.compile fanyajw-shared-jar --workspace-root C:\Users\lin\IdeaProjects

# rpc：按旧脚本 7 步串联 clean/install/compile
python -m jacov.compile fanyajwproject-rpc --workspace-root C:\Users\lin\IdeaProjects

装包后也可以直接用：

jacov-compile fanyajwproject-course-v2 --workspace-root C:\Users\lin\IdeaProjects

编译日志统一写到 <workspace-root>/target/maven-logs/，避免 mvn clean 删除模块自身 target 时把正在写入的日志删掉。执行过程中会打印当前步骤、总步骤数、已耗时、单步开始/结束时间和单步耗时。

Git Bash 下 Windows 路径请用正斜杠，例如 --workspace-root C:/Users/lin/IdeaProjects。不要写 C:\Users\lin\IdeaProjects，反斜杠会被 Git Bash 当转义符吞掉。

性能与开关

覆盖率合并成单条 maven 命令（prepare-agent → 测试 → report），避免多次 JVM 冷启动；多测试类默认复用 fork JVM。

开关（CLI 反向）

默认

说明

compile_first（--no-compile）

True

True 含增量编译（测最新代码）；False 用 surefire:test 跳过编译

reuse_forks（--no-reuse）

True

True 多测试类复用同一 fork JVM（快 ~4x）；False 每类独立 JVM（严格隔离）

实测 course-v2 schedule 包 21 测试：拆 3 次 maven + 独立 JVM 会超时 → 合并 1 条 + 复用 fork 12s（覆盖率逐字段一致）。 若怀疑测试间静态状态污染导致覆盖率异常，用 --no-reuse 切独立 JVM 对照。

接入 Claude Code（MCP）

  1. 装包：pip install -e coverage-mcp（带 mcp 依赖）。

  2. 在项目 .mcp.json 的 mcpServers 里加一个 jacov 条目（command 用本机 python.exe 绝对路径，与装包的解释器一致；已有别的 server 就并列加）：

    {
  "mcpServers": {
    "jacov": {
      "command": "<python.exe 绝对路径>",
      "args": ["-m", "jacov.server"]
    }
  }
}

  3. 重启 Claude Code（或 /mcp 重连）。之后可调 coverage_check(module_dir, tests, cover, min_branch)。

注：coverage_check 首次调用会真跑 maven（编译 + 测试 + JaCoCo），耗时分钟级。 返回紧凑 JSON：status / tests / coverage / uncovered（行号+MISS·PARTIAL+源码） / reports。

Available Tools

2 tools
compile_projectA

编译目标并返回每个 Maven 步骤的状态与日志路径，三级回退自动识别入参。

Args: project_name: 注册项目名（全名/短名，如 fanyajwproject-course-v2 或 course-v2）， 或含 pom.xml 的目录路径（相对/绝对/嵌套/双层同名均可，相对优先）。 未注册的目录按 path 策略 clean+compile。 workspace_root: 工作区根目录；空则优先从当前目录或 coverage-mcp 父目录推导 strategy: 可选策略覆盖：default/top-level/shared-jar/rpc

ParametersJSON Schema
NameRequiredDescriptionDefault
strategyNo
project_nameYes
workspace_rootNo

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a 'three-level fallback' but does not explain side effects, permissions, error handling, or whether the compilation modifies files. Minimal transparency compared to the ideal for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a one-sentence overview followed by structured parameter documentation. Every sentence adds value, though the initial line could be more concise by not including the fallback detail implicitly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description mentions return values (status and log paths), which is helpful. However, it does not specify the output format, error behavior, or prerequisites like Maven installation. For a compilation tool, this is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter descriptions add significant value beyond the input schema, which has 0% coverage. For 'project_name', it explains accepted formats and resolution priority; for 'workspace_root', it specifies default derivation; for 'strategy', it lists valid values. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compiles a project using Maven and returns status and log paths for each step. The verb 'compile' and resource 'project' are specific, and the sibling tool 'coverage_check' has a distinct purpose, providing differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus the sibling tool 'coverage_check'. There is no mention of prerequisites, such as requiring Maven to be installed, or context about when compilation is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

coverage_checkA

跑指定测试类并按类卡分支覆盖率，返回测试结果 / 覆盖率 / 未覆盖分支行。

Args: module_dir: 模块目录（含 pom.xml） tests: 测试类，逗号分隔（可带或不带 .java）；给了 package 可留空 cover: 卡覆盖率的业务类，逗号分隔；空=ALL 汇总 min_branch: 最小分支覆盖率，支持 80 或 0.8 compile_first: True=含增量编译，保证测最新代码（默认）；False=跳过编译，代码已编译时更快 reuse_forks: True=多测试类复用同一 fork JVM（默认，快得多）；False=每类独立 JVM（严格隔离） package: 业务包（如 fanya/schedule）；给了就自动收集该包全部测试类+业务类，tests/cover 可留空

ParametersJSON Schema
NameRequiredDescriptionDefault
coverNo
testsNo
packageNo
min_branchNo
module_dirYes
reuse_forksNo
compile_firstNo

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key behaviors: incremental compilation option, JVM fork reuse, auto-collection of tests when package is given, and acceptance of different formats for min_branch. It does not mention permissions or side effects, but for a test runner, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured as a clear list of arguments with explanations. While not extremely terse, every sentence adds value. It could be slightly more concise, but it remains readable and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, no output schema), the description covers all essential aspects: parameter descriptions, default behaviors, and return value summary. It is complete enough for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description must compensate, and it does so thoroughly. It explains the purpose and acceptable formats for each parameter (e.g., tests can include/exclude .java, cover can be empty, package auto-collects). This adds significant value beyond the minimal schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it runs specified test classes and checks branch coverage, returning test results, coverage, and uncovered branch lines. It distinguishes itself from the sibling tool 'compile_project' which only compiles code.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use the tool (when needing to run tests with coverage) and details on parameter usage. However, it lacks explicit guidance on when not to use it or direct comparison with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.0.1
    • First observedcompile_project
    • First observedcoverage_check
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: compile_project handles Maven compilation with fallback strategies, while coverage_check runs tests and evaluates branch coverage. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent snake_case verb_noun pattern: compile_project and coverage_check. The naming is predictable and clear.

Tool Count3/5

With only 2 tools, the server feels minimal. While the tools themselves are substantial and cover core compilation and testing, the count is at the low end of typical MCP servers.

Completeness2/5

The server lacks essential features for a complete coverage workflow, such as listing projects, retrieving historical coverage data, or managing configurations. Agents must re-run checks to get results, limiting usability.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProgrammerDream/coverage-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server