Skip to main content
Glama
diffblue

Diffblue Cover MCP Server

Official
by diffblue
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

MCP Server for Diffblue Cover CLI

This repository provides a Model Context Protocol (MCP) Server for the Diffblue Cover CLI tool (dcover), making it callable and manageable by various AI development environments that adhere to the MCP specification (like the Gemini CLI).

Core Component: The MCP Server covermcp/server.py

The Python script serves as the universal adapter for the dcover create command.

Related MCP server: TestCollab MCP Server

Prerequisites

Before configuring the server with any host environment, ensure you have the following installed:

  1. Diffblue Cover CLI: Thedcover command must be installed and accessible in your system's PATH.

    • You can verify this by running dcover version in your terminal.

  2. uv: A Python project and package manager (https://docs.astral.sh/uv/)

Installing the MCP server

The project uses FastMCP to develop and deploy the MCP server. To install this server, you can use uv run fastmcp install claude-code --server-spec main.py (for example), other LLM tools are supported out of the box:

$ uv run fastmcp install --help
Usage: fastmcp install COMMAND

Install MCP servers in various clients and formats.

╭─ Commands ─────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ claude-code     Install an MCP server in Claude Code.                                                                  │
│ claude-desktop  Install an MCP server in Claude Desktop.                                                               │
│ cursor          Install an MCP server in Cursor.                                                                       │
│ gemini-cli      Install an MCP server in Gemini CLI.                                                                   │
│ mcp-json        Generate MCP configuration JSON for manual installation.                                               │
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

This command will install the MCP server for all projects, which you may not want. If this is the case, then you can be targeted in your installation if you use the mcp-json option to augment a .mcp.json file in the project:

{
  "mcpServers": {
    "Diffblue Cover": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "fastmcp",
        "fastmcp",
        "run",
        "/path/to/cover-mcp/main.py"
      ]
    }
  }
}

This also allows you to specify environment variables. Currently, there are two that you can specify:

  • DIFFBLUE_COVER_CLI : the location of the installed dcover command line

  • DIFFBLUE_COVER_OPTIONS : use these dcover options as well as those supplied by the LLM

To use these variables in the .mcp.json file above, you would do so like this:

{
  "mcpServers": {
    "Diffblue Cover": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "fastmcp",
        "fastmcp",
        "run",
        "/path/to/cover-mcp/main.py"
      ],
      "env": {
        "DIFFBLUE_COVER_CLI": "/path/to/dcover",
        "DIFFBLUE_COVER_OPTIONS": "--verbose --active-profiles=test"
      }
    }
  }
}

This will run the equivalent to /path/to/dcover --batch create <entry points provided by the LLM> --verbose --active-profiles=test

Note: No attempt is made to disambiguate the options provided options.

Developmental Notes

FastMCP contains a tool called "MCP Inspector" which can be used to interact with the MCP server without needing the LLM interaction. To run this developmental server, you can use uv run fastmcp dev. The configuration lives in the file fastmcp.json which provides (among other things) the entry point for the server.

$ uv run fastmcp dev --help    
Usage: fastmcp dev [OPTIONS] [ARGS]

Run an MCP server with the MCP Inspector for development.

╭─ Parameters ────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ SERVER-SPEC --server-spec  Python file to run, optionally with :object suffix, or None to auto-detect fastmcp.json      │
│ --with-editable            Directory containing pyproject.toml to install in editable mode (can be used multiple times) │
│ --with                     Additional packages to install (can be used multiple times)                                  │
│ --inspector-version        Version of the MCP Inspector to use                                                          │
│ --ui-port                  Port for the MCP Inspector UI                                                                │
│ --server-port              Port for the MCP Inspector Proxy server                                                      │
│ --python                   Python version to use (e.g., 3.10, 3.11)                                                     │
│ --with-requirements        Requirements file to install dependencies from                                               │
│ --project                  Run the command within the given project directory                                           │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Project Layout

The project and the dependencies are managed by uv, see the documentation for the usage instructions.

Running Tests

There are unit tests (in the test directory) which you can run with uv run coverage run -m pytest and then get a coverage report with uv run coverage report --omit "test/*" (python includes the coverage of the test files by default -- not that useful).

Linting/Formatting

To run the linter, run uv run ruff check. If successful, you will see a message "All checks passed!". If not, you should address the issues picked up. More information can be found at the Ruff Linter Documentation

To format the code, run uv run ruff format, this should be run before committing any changes. More information can be found at the Ruff Formatter Documentation.

References

Available Tools

3 tools
createA

Invoke Diffblue Cover to generate unit tests for Java code.

This tool executes the dcover CLI to automatically generate JUnit tests for the specified Java classes, methods, or packages. It supports various configuration options to control the test generation process.

Args: path: Path to the dcover executable. If not provided, searches system PATH and the DIFFBLUE_COVER_CLI environment variable. working_directory: Root directory of the Java project to test. Defaults to the current working directory. dcover_timeout: Maximum execution time in seconds. Defaults to 600. Set to None for no timeout (not recommended). entry_points: List of fully-qualified Java targets (packages, classes, or methods) to generate tests for. Examples: ['com.example.MyClass', 'com.example.MyClass.myMethod']. If None, tests entire project. args: Additional arguments to pass to dcover. Defaults to None. ctx: MCP server context for logging and progress reporting (auto-injected by FastMCP).

Returns: dict: Execution result containing: - return_code (int): Exit code (0 for success) - status (str): "success" if completed without errors - output (str): Complete stdout/stderr from dcover - command (list[str]): The exact command that was executed - working_directory (Path): Directory where command was run

Raises: ToolError: If dcover executable not found, command fails, or timeout exceeded. The error includes the partial output collected before failure.

Note: If DIFFBLUE_COVER_OPTIONS environment variable is set, it overrides all option parameters (batch, skip_verification, etc.) except path, working_directory, timeout, and entry_points.

This tool requires a valid Diffblue Cover license. See:
https://docs.diffblue.com/features/cover-cli/commands-and-arguments#create-tests
ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoThe options to pass to dcover
pathNoThe path to the dcover executable
entry_pointsNoThe list of package names, class names, and/or methods to write tests for. The entries here should be fully qualified, in other words you must include the package and class names when specifying a method name.
dcover_timeoutNoThe maximum time in seconds to wait for dcover to create tests.
working_directoryNoThe directory containing the project/app

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It thoroughly explains that this executes an external CLI, what the return structure is, what errors may occur, how timeouts are handled, and that environment variables can override options. It could explicitly mention filesystem side effects such as writing generated test files, but overall the behavior is well disclosed.

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 long but well organized into Args, Returns, Raises, and Notes sections. The leading purpose statement is clear and the subsequent detail is structured rather than a wall of text. A small amount of redundancy exists with return values repeated from the output schema, but it remains efficient for a complex CLI tool.

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 wraps an external CLI, the description is remarkably complete: it covers parameters, defaults, environment overrides, license requirements, error behavior, timeout semantics, and exact return fields. The output schema already exists, and the description still adds the important operational details an agent needs to invoke this tool correctly. Nothing essential is missing.

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

Parameters4/5

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

The input schema has 100% coverage of parameters, so the baseline is 3. The description adds meaningful detail beyond the schema: path searching behavior including DIFFBLUE_COVER_CLI, working_directory defaulting behavior, the implication of timeout=None, fully-qualified entry_point examples, and the effect of DIFFBLUE_COVER_OPTIONS. This elevates parameter understanding beyond the schema alone.

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 identifies the tool as invoking Diffblue Cover to generate unit tests for Java code. The first sentence states a specific action and resource, and distinguishes this 'create' tool from the sibling tools 'refactor' and 'issues' by focusing on test generation.

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

Usage Guidelines3/5

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

The description implies when to use the tool: when you want to generate unit tests for Java code with dcover. However, it does not explicitly discuss when not to use it or how it compares to the sibling tools 'refactor' and 'issues'. The usage context is clear but alternative selection guidance is missing.

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

issuesA

Invoke Diffblue Cover to identify project issues.

This tool executes the dcover issues command to output a prioritized list of project issues that may prevent test generation.

Args: path: Path to the dcover executable. If not provided, searches system PATH and the DIFFBLUE_COVER_CLI environment variable. working_directory: Root directory of the Java project to test. Defaults to the current working directory. dcover_timeout: Maximum execution time in seconds. Defaults to 600. Set to None for no timeout (not recommended). limit: Limit the number of issues to output. skip: Skip the first N issues from the report. prompt: If True, outputs a suggested prompt for each actionable issue. cover_json: Location of the JSON-formatted test-writing summary report. dry_run: If True, passes the '--dry-run' flag to check for readiness. args: Additional arguments to pass to dcover. Defaults to None. ctx: MCP server context for logging and progress reporting (auto-injected by FastMCP).

Returns: dict: Execution result containing: - return_code (int): Exit code (0 for success) - status (str): "success" if completed without errors - output (str): Complete stdout/stderr from dcover - command (list[str]): The exact command that was executed - working_directory (Path): Directory where command was run

Raises: ToolError: If dcover executable not found, command fails, or timeout exceeded. The error includes the partial output collected before failure.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoThe additional options to pass to dcover issues
pathNoThe path to the dcover executable
skipNoSkip the first N issues
limitNoLimit the number of issues to output
promptNoOutput suggested prompt for each actionable issue
dry_runNoRun preflight checks only (aliased as --preflight)
cover_jsonNoPath to a JSON-formatted test-writing summary report
dcover_timeoutNoThe maximum time in seconds to wait for dcover to create tests.
working_directoryNoThe directory containing the project/app

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does an excellent job. It discloses that the tool executes a CLI command, details the exact return dictionary structure (return_code, status, output, command, working_directory), explains timeout and failure behavior, and explicitly lists ToolError conditions including partial output collection. It also documents path resolution and the dry-run flag behavior.

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

Conciseness3/5

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

The description is well-organized into Args, Returns, and Raises sections, but it is long and repeats much of what the schema already provides. It also includes a 'ctx' parameter in the Args list that is not present in the input schema, which could confuse an agent. The extra noise and redundancy reduce the clarity that good structure would otherwise provide.

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

Completeness4/5

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

For a tool with 9 optional parameters and no annotations, the description is nearly complete: it covers all parameters, return values, and error conditions. The output schema is indicated as present, so the detailed Returns section is a bonus. The only notable gaps are the lack of guidance relative to sibling tools and the minor working_directory default discrepancy, but these do not leave an agent unable to call the tool correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics beyond the schema: it explains that `path` searches system PATH and DIFFBLUE_COVER_CLI, that `dcover_timeout` defaults to 600 and setting None is not recommended, and that `dry_run` passes the '--dry-run' flag. There is a slight inconsistency for `working_directory` (description says defaults to current working directory while schema shows default '/app'), which prevents a 5.

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

Purpose4/5

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

The description opens with 'Invoke Diffblue Cover to identify project issues,' which provides a specific verb, resource, and outcome. It clearly says the tool runs the `dcover issues` command and outputs a prioritized list of issues. However, it does not explicitly differentiate itself from the sibling tools 'create' and 'refactor', which are likely also Diffblue commands.

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 gives no explicit guidance on when to use this tool versus alternatives. It implies a pre-test-generation use case with 'issues that may prevent test generation,' but it never mentions create or refactor as alternatives or states conditions for choosing one. An agent must infer the appropriate context.

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

refactorA

Invoke Diffblue Cover to refactor the project (aliased as 'fix-build').

This tool executes the dcover refactor command to apply automated refactorings, such as fixing build issues or adding missing dependencies.

Args: path: Path to the dcover executable. If not provided, searches system PATH and the DIFFBLUE_COVER_CLI environment variable. working_directory: Root directory of the Java project to test. Defaults to the current working directory. dcover_timeout: Maximum execution time in seconds. Defaults to 600. Set to None for no timeout (not recommended). dry_run: If True, passes the '--dry-run' flag to check for readiness without applying changes. args: Additional arguments to pass to dcover. Defaults to None. ctx: MCP server context for logging and progress reporting (auto-injected by FastMCP).

Returns: dict: Execution result containing: - return_code (int): Exit code (0 for success) - status (str): "success" if completed without errors - output (str): Complete stdout/stderr from dcover - command (list[str]): The exact command that was executed - working_directory (Path): Directory where command was run

Raises: ToolError: If dcover executable not found, command fails, or timeout exceeded. The error includes the partial output collected before failure.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoThe additional options to pass to dcover refactor
pathNoThe path to the dcover executable
dry_runNoRun preflight checks only (aliased as --preflight)
dcover_timeoutNoThe maximum time in seconds to wait for dcover to create tests.
working_directoryNoThe directory containing the project/app

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does well: it explains that the command applies changes, that `dry_run` checks readiness without applying changes, that timeouts default to 600 seconds and can be disabled, and that failures raise `ToolError` with partial output. It does not explicitly mention file-system side effects, but 'apply automated refactorings' implies mutation clearly enough.

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 well-structured with clear sections for overview, arguments, return value, and errors. It is somewhat redundant with the schema's parameter descriptions, but the added details earn their place and the opening sentence front-loads the core purpose.

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?

The description is complete for this CLI-wrapper tool: it covers the command being run, all parameter defaults and behaviors, the return structure, and failure modes. An agent has everything needed to invoke the tool correctly without relying on external documentation.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema by explaining that `path` searches the system PATH and the DIFFBLUE_COVER_CLI environment variable, that `dcover_timeout=None` disables the timeout, and that `dry_run` avoids applying changes. These details help an agent call the tool correctly.

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 a specific verb and resource: 'Invoke Diffblue Cover to refactor the project' and identifies the exact command executed (`dcover refactor`). It also gives concrete example use cases ('fixing build issues or adding missing dependencies'), which makes the tool's purpose unmistakable and distinct from the sibling tools.

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 clear context for when to use the tool: applying automated refactorings, fixing build issues, or adding missing dependencies. It does not explicitly contrast with the sibling tools `create` and `issues`, but it gives enough purpose-based guidance for an agent to select it appropriately.

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. 3 tool updatesv0.1.0
    • First observedcreate
    • First observedissues
    • First observedrefactor
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool maps to a distinct dcover subcommand: create for test generation, refactor for build fixes, and issues for diagnosing problems. There is no meaningful overlap in their purposes, and the descriptions clearly differentiate them.

Naming Consistency4/5

Two tools use imperative verbs (create, refactor) while the third uses a noun (issues), creating a slight inconsistency. However, the names are short, memorable, and directly correspond to CLI commands, so the deviation is minor.

Tool Count4/5

Three tools is minimal but appropriate for a focused wrapper around the Diffblue Cover CLI. Each tool covers a real workflow stage, leaving little room for redundancy, though the server might feel slightly thin for broader use cases.

Completeness4/5

The tool surface covers the core workflow: diagnose issues, generate tests, and refactor/fix problems. Minor gaps exist, such as lack of explicit status or configuration tools, but these are not essential and can be worked around via the 'args' parameters.

Maintenance

ActivityInactive
ResponsivenessNo issues

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/diffblue/cover-mcp'

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