Skip to main content
Glama
jermeyyy

Gradle MCP Server

by jermeyyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Gradle MCP Server

A Model Context Protocol (MCP) server for seamless Gradle integration with AI assistants

Python 3.10+ License: MIT FastMCP 2.0+

Empower your AI coding assistant to build, test, and manage Gradle projects with real-time monitoring

Features • Installation • Quick Start • Web Dashboard • API Reference • Contributing

✨ Features

🛠️ Build Automation

  • Project Discovery — Automatically detect and list all Gradle projects in your workspace

  • Task Management — Browse and execute any Gradle task with full argument support

  • Multi-Task Execution — Run multiple tasks in a single command

  • Safe Cleaning — Dedicated clean tool prevents accidental artifact deletion

📊 Real-Time Monitoring

  • Live Progress Tracking — Visual progress updates during task execution

  • Web Dashboard — Browser-based monitoring with WebSocket updates

  • Daemon Management — Monitor and control Gradle daemon processes

  • Build Logs — Searchable, real-time build log viewer

🔧 Configuration & Diagnostics

  • Config Inspection — View JVM args, daemon settings, and Gradle version

  • Memory Monitoring — Track daemon memory usage and health

  • Structured Error Output — LLM-friendly error responses with deduplicated compilation errors and task failure summaries

Related MCP server: Build MCP Server

📸 Web Dashboard

The Gradle MCP Server includes a powerful web dashboard for real-time build monitoring. The dashboard starts automatically when the server runs and is accessible at http://localhost:3333.

Dashboard Overview

The main dashboard provides:

  • Daemon Status — Real-time view of running Gradle daemons with PID, status, and memory usage

  • Active Builds — Live tracking of currently executing tasks

  • Quick Actions — One-click daemon management (stop all, refresh status)

  • Auto-Refresh — WebSocket-powered updates without manual refresh

Build Logs Viewer

The logs viewer offers:

  • Real-Time Streaming — Watch build output as it happens

  • Log Filtering — Search and filter through build history

  • Clear Logs — One-click log clearing for fresh sessions

  • Persistent History — Logs persist across page refreshes during a session

📦 Installation

Requirements

  • Python 3.10+

  • Gradle project with wrapper (gradlew / gradlew.bat)

  • MCP-compatible client (e.g., Claude Desktop, Cursor, VS Code with Copilot)

Install from Source

git clone https://github.com/jermeyyy/gradle-mcp.git
cd gradle-mcp

# Using uv (recommended)
uv sync

# Or using pip
pip install -e .

🚀 Quick Start

1. Start the Server

# Navigate to your Gradle project directory
cd /path/to/your/gradle/project

# Start the MCP server
uv run gradle-mcp

The server will:

  1. Auto-detect the Gradle wrapper in the current directory

  2. Start the web dashboard at http://localhost:3333 (or higher if port already occupied)

  3. Begin listening for MCP client connections

2. Configure Your MCP Client

Add the server to your MCP client configuration. For example, in Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "gradle": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/gradle-mcp/installation",
        "gradle-mcp"
      ]
      "env": {
        "GRADLE_PROJECT_ROOT": "/path/to/your/gradle/project"
      }
    }
  }
}

3. Start Building!

Your AI assistant can now execute Gradle commands:

"Build the app module"
"Run all tests except integration tests"
"Show me the available tasks for the core module"
"Check the Gradle daemon status"

🔧 Configuration

Environment Variables

Variable

Description

Default

GRADLE_PROJECT_ROOT

Root directory of the Gradle project

Current directory

GRADLE_WRAPPER

Path to Gradle wrapper script

Auto-detected

GRADLE_OPTS

JVM options for Gradle client

—

JAVA_OPTS

General Java options

—

Example Configuration

# Custom project location
export GRADLE_PROJECT_ROOT=/path/to/project
uv run gradle-mcp

# Custom wrapper location
export GRADLE_WRAPPER=/path/to/custom/gradlew
uv run gradle-mcp

📚 MCP Tools API

Project & Task Management

list_projects()

List all Gradle projects in the workspace.

Returns: List of projects with name, path, and description

list_project_tasks(project, include_descriptions, group)

List available tasks for a project, optionally filtered by group.

Parameter

Type

Description

project

str | None

Project path (e.g., :app). Use None, "", or : for root

include_descriptions

bool

Include task descriptions (default: False)

group

str | None

Filter by task group (e.g., Build, Verification)

Returns: Grouped list of tasks

run_task(task, args)

Execute one or more Gradle tasks.

Parameter

Type

Description

task

str | list[str]

Task(s) to run. Examples: build, :app:build, [':core:build', ':app:assemble']

args

list[str] | None

Additional Gradle arguments (e.g., ['--info', '-x', 'test'])

Returns: TaskResult with:

  • success: bool — Whether the task completed successfully

  • error: ErrorInfo | None — Structured error information (see Structured Error Output)

⚠️ Note: Cleaning tasks are blocked — use the clean tool instead.

clean(project)

Clean build artifacts for a project.

Parameter

Type

Description

project

str | None

Project path (e.g., :app). Use None, "", or : for root

Returns: TaskResult with:

  • success: bool — Whether clean completed successfully

  • error: ErrorInfo | None — Structured error information (see Structured Error Output)

Daemon Management

daemon_status()

Get status of all running Gradle daemons.

Returns: Running status, list of daemon info (PID, status, memory), and any errors

stop_daemon()

Stop all Gradle daemons. Useful for freeing memory or resolving daemon issues.

Returns: Success status and error message if failed

Configuration

get_gradle_config()

Get current Gradle configuration including memory settings.

Returns: Configuration object with:

  • jvm_args — JVM arguments from gradle.properties

  • daemon_enabled — Whether daemon is enabled

  • parallel_enabled — Whether parallel execution is enabled

  • caching_enabled — Whether build caching is enabled

  • max_workers — Maximum worker count

  • distribution_url — Gradle distribution URL

  • gradle_version — Gradle version

💡 Usage Examples

With MCP Client

# Discover projects
list_projects()

# List build tasks for a module
list_project_tasks(project=":app", group="Build")

# Build with verbose output
run_task(task=":app:build", args=["--info"])

# Run tests, skipping integration tests
run_task(task=":app:test", args=["-x", "integrationTest"])

# Run multiple tasks
run_task(task=[":core:build", ":app:assemble"])

# Check daemon health
daemon_status()

# Free up memory
stop_daemon()

As Python Library

from gradle_mcp.gradle import GradleWrapper

gradle = GradleWrapper("/path/to/gradle/project")

# List projects
projects = gradle.list_projects()
for project in projects:
    print(f"Project: {project.name} at {project.path}")

# List tasks with descriptions
tasks = gradle.list_tasks(":app", include_descriptions=True)
for group in tasks:
    print(f"\n{group.group}:")
    for task in group.tasks:
        print(f"  {task.name}: {task.description}")

# Run a task
result = await gradle.run_task([":app:build"])
if result["success"]:
    print("✅ Build succeeded!")
else:
    print(f"❌ Build failed: {result['error']}")

🏗️ Architecture

Safety by Design

  • Separated Cleaning — The run_task tool blocks all cleaning operations (clean, cleanBuild, etc.). Use the dedicated clean tool for artifact removal.

  • Gradle Wrapper — Always uses the project's Gradle wrapper for version consistency

  • Progress Reporting — Real-time progress via MCP protocol

Structured Error Output

The run_task and clean tools return structured error information optimized for LLM consumption:

class ErrorInfo:
    summary: str                        # e.g., "Build failed: 2 tasks failed with 12 compilation errors in 1 file"
    failed_tasks: list[FailedTask]      # List of failed task names and reasons
    compilation_errors: list[CompilationError]  # Deduplicated compilation errors

class CompilationError:
    file: str      # Full path (without file:// prefix)
    line: int
    column: int | None
    message: str

class FailedTask:
    name: str      # e.g., ":app:compileKotlin"
    reason: str    # e.g., "Compilation finished with errors"

Example response:

{
  "success": false,
  "error": {
    "summary": "Build failed: 2 tasks failed with 2 compilation errors in 1 file",
    "failed_tasks": [
      {"name": ":app:compileKotlin", "reason": "Compilation finished with errors"}
    ],
    "compilation_errors": [
      {
        "file": "/Users/dev/project/src/Main.kt",
        "line": 45,
        "column": 49,
        "message": "Argument type mismatch: actual type is 'String', but 'Int' was expected."
      }
    ]
  }
}

Key features:

  • Deduplication — Identical errors from multiple targets (e.g., iOS Arm64 + Simulator) are merged

  • Clean paths — file:// prefix is stripped from file paths

  • Concise summaries — Human-readable summary with task/error/file counts

  • Token efficient — Structured data instead of raw build output

🧪 Development

Setup Development Environment

# Clone the repository
git clone https://github.com/jermeyyy/gradle-mcp.git
cd gradle-mcp

# Install with dev dependencies
uv sync --all-extras

Run Tests

pytest tests/

Code Quality

# Format code
black src/

# Lint code
ruff check src/

# Type checking
mypy src/

Project Structure

gradle-mcp/
├── src/gradle_mcp/
│   ├── __init__.py           # Package initialization
│   ├── server.py             # MCP server implementation
│   ├── gradle.py             # Gradle wrapper interface
│   └── dashboard/            # Web dashboard
│       ├── app.py            # Flask application
│       ├── daemon_monitor.py # Daemon monitoring
│       ├── log_store.py      # Log management
│       ├── templates/        # HTML templates
│       └── static/           # CSS/JS assets
├── tests/                    # Test suite
├── art/                      # Screenshots and artwork
├── pyproject.toml            # Project configuration
└── README.md

🤝 Contributing

Contributions are welcome! Here's how you can help:

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

Ideas for Contribution

  • Additional build system support (Maven, Bazel)

  • Enhanced error visualization in dashboard

  • Build statistics and history

  • Custom task presets

📄 License

This project is licensed under the MIT License — see the LICENSE file for details.

Built with ❤️ for the Gradle and AI community

Report Bug • Request Feature

Available Tools

7 tools
cleanA

Clean build artifacts for a Gradle project.

Args: project: Project path (e.g., ':app'). Use None, empty string, or ':' for root project.

Returns: TaskResult with success status and error message if failed.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
successYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the tool performs a 'clean' operation (implying mutation/deletion of artifacts) and mentions the return type 'TaskResult', which adds some behavioral context. However, it doesn't detail side effects (e.g., what artifacts are deleted, whether it's reversible), permissions, or error handling beyond a generic mention, leaving gaps 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.

Conciseness5/5

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

The description is well-structured and front-loaded with the core purpose, followed by concise sections for args and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.

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?

Given the tool's moderate complexity (mutation with one parameter) and the presence of an output schema (which covers return values), the description is mostly complete. It explains the purpose, parameter usage, and return type adequately. However, as a mutation tool with no annotations, it could benefit from more behavioral details like side effects or error specifics.

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 0%, so the description must compensate. It provides clear semantics for the single parameter 'project', including examples (':app') and special cases (None, empty string, ':' for root), which adds significant value beyond the bare schema. However, it doesn't explain default behavior or constraints beyond what's shown, keeping it from a perfect score.

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 clearly states the action ('clean build artifacts') and resource ('for a Gradle project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'run_task' which might also perform build operations, so it doesn't reach the highest score.

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 usage context (cleaning build artifacts in Gradle projects) but doesn't provide explicit guidance on when to use this versus alternatives like 'run_task' with a clean target, or mention prerequisites like needing a Gradle project setup. It's adequate but lacks sibling differentiation and exclusion criteria.

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

daemon_statusA

Get status of Gradle daemon(s).

Returns current daemon status including running daemons and their info. Useful for monitoring daemon health and resource usage.

Returns: DaemonStatusResult with running status, list of daemon info, and optional error.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
daemonsYes
runningYes

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns status information (a read operation) and hints at monitoring use, but lacks details on permissions, rate limits, or error handling beyond mentioning an optional error in returns. This is adequate but has gaps for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, followed by usage context and return details in three concise sentences. Every sentence adds value without waste, making it efficiently structured.

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?

Given the tool's low complexity (0 parameters) and the presence of an output schema (which covers return values), the description is mostly complete. It provides purpose, usage, and a high-level overview of returns, but could slightly enhance behavioral transparency for a tool with no annotations.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary information.

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 specific verb ('Get status') and resource ('Gradle daemon(s)'), and distinguishes it from siblings like 'stop_daemon' by focusing on monitoring rather than control. It explicitly mentions what the tool does without being tautological.

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 this tool ('Useful for monitoring daemon health and resource usage'), which implicitly distinguishes it from siblings like 'run_task' or 'clean'. However, it does not explicitly state when not to use it or name alternatives, keeping it at a 4.

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

get_gradle_configA

Get current Gradle configuration including memory settings.

Returns configuration from gradle.properties and gradle-wrapper.properties including JVM args, daemon settings, and Gradle version info. Useful for diagnosing memory issues or understanding project configuration.

Returns: GradleConfigResult with JVM args, daemon/parallel/caching settings, max workers, distribution URL, and Gradle version.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
jvm_argsYes
max_workersYes
daemon_enabledYes
gradle_versionYes
caching_enabledYes
distribution_urlYes
parallel_enabledYes

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a read-only operation that returns configuration data, which is appropriate, but lacks details on potential side effects, error handling, or performance characteristics (e.g., whether it's resource-intensive). It adds some context by mentioning the source files and use cases, but could be more comprehensive for a tool with zero annotation coverage.

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

Conciseness5/5

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

The description is well-structured and front-loaded, starting with the core purpose and followed by details on returns and usage. Every sentence adds value: the first defines the action, the second specifies sources and content, the third provides context, and the fourth outlines the output structure. There is no wasted text, making it highly efficient.

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?

Given the tool's complexity (read-only configuration retrieval), no annotations, 0 parameters, and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, sources, use cases, and output structure. However, it could improve by addressing potential limitations or dependencies, such as requiring Gradle to be installed or file access permissions.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a baseline score above 3. It effectively compensates by explaining what the tool retrieves, which aligns with the lack of inputs.

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 specific action ('Get current Gradle configuration') and resource ('memory settings, gradle.properties, gradle-wrapper.properties'), distinguishing it from siblings like 'list_projects' or 'run_task' that perform different operations. It precisely identifies what configuration elements are retrieved, making the purpose unambiguous.

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 this tool ('Useful for diagnosing memory issues or understanding project configuration'), which helps differentiate it from siblings focused on execution or listing. However, it does not explicitly state when not to use it or name specific alternatives, such as using 'daemon_status' for daemon-specific checks instead.

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

list_projectsB

List all Gradle projects in the workspace.

Returns: List of Gradle projects.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a list of projects, which is helpful, but doesn't cover important aspects like whether this is a read-only operation, potential performance impacts, error conditions, or pagination behavior. The description adds minimal behavioral context beyond the basic return statement.

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 appropriately concise with two clear sentences. The first states the purpose, and the second describes the return value. There's no wasted language, though it could be slightly more structured by combining both pieces of information into a single flowing sentence.

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 that the tool has no parameters, an output schema exists, and it's a relatively simple list operation, the description provides adequate basic information. However, for a tool with no annotations, it should ideally include more behavioral context about what 'list all' means in practice (e.g., completeness guarantees, ordering, or limitations).

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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to add parameter information, and it correctly doesn't attempt to describe non-existent parameters. This meets the baseline expectation for tools with no parameters.

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 clearly states the verb ('List') and resource ('Gradle projects in the workspace'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_project_tasks', which could cause confusion about when to use each tool.

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 provides no guidance on when to use this tool versus alternatives like 'list_project_tasks' or 'get_gradle_config'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.

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

list_project_tasksA

List all tasks available in a Gradle project.

Returns a nested structure grouped by task group. This is more compact than a flat list and avoids repeating project/group information for each task.

Args: project: Project path (e.g., ':app' or 'lib:module'). Use None, empty string, or ':' for root project. include_descriptions: If True, include task descriptions in the response. If False, return only task names for a more compact response. group: Optional group name to filter tasks (e.g., 'Build', 'Verification'). Case-insensitive. If not provided, all groups are returned.

Returns: List of grouped tasks. Each group contains a group name and list of tasks. If include_descriptions is True, tasks include name and description. If include_descriptions is False, tasks are just name strings.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNo
include_descriptionsNo
groupNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the nested grouped structure of the output, the compactness benefit over a flat list, and the effect of 'include_descriptions' on the response format. However, it lacks details on error handling, permissions, or performance implications (e.g., whether it's a heavy operation).

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

Conciseness5/5

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

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by key behavioral details, then a structured breakdown of parameters and returns. Every sentence adds value without redundancy, and the use of sections (Args, Returns) enhances readability.

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 moderate complexity (3 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage context, parameter semantics, and output behavior. The output schema exists, so the description correctly focuses on explaining the structure and logic rather than repeating schema details, providing all necessary context for an agent.

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?

Schema description coverage is 0%, so the description must fully compensate. It adds substantial meaning beyond the schema: it explains the purpose of each parameter, provides examples (e.g., ':app' for 'project', 'Build' for 'group'), clarifies default behaviors (e.g., root project handling), and describes the impact of 'include_descriptions' on the output. This fully documents all three parameters.

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 specific action ('List all tasks'), resource ('in a Gradle project'), and scope ('available'), distinguishing it from siblings like 'list_projects' (which lists projects) and 'run_task' (which executes tasks). The verb+resource combination is precise and unambiguous.

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 this tool (to get a compact, grouped list of tasks) but does not explicitly mention when not to use it or name alternatives. For example, it doesn't contrast with 'run_task' or explain if this is for discovery vs. execution. The guidance is implied through the description of the output structure.

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

run_taskA

Run one or more Gradle tasks.

Args: task: Task(s) to run. Single task, space-separated tasks, or list of tasks. Examples: 'build', ':app:build :core:build', [':core:build', ':app:assemble']. args: Optional Gradle arguments (e.g., ['--info', '-x', 'test']).

Returns: TaskResult with success status and error message if failed.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYes
argsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
successYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool executes tasks and returns a TaskResult with success status and error messages, which covers basic behavior. However, it lacks details on side effects (e.g., file system changes), performance implications, or error handling beyond the return structure.

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 sections for Args and Returns, making it easy to scan. It's front-loaded with the core purpose, and each sentence adds value (e.g., examples for parameters). It could be slightly more concise by integrating the examples more tightly, but overall it's efficient.

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?

Given the tool's complexity (executing tasks with potential side effects), no annotations, and an output schema (implied by Returns section), the description is fairly complete. It covers purpose, parameters with examples, and return values. However, it lacks context on error scenarios or integration with sibling tools, leaving minor gaps.

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?

Schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for both parameters: 'task' explains it can be a single task, space-separated tasks, or a list with examples, and 'args' describes optional Gradle arguments with examples. This adds substantial meaning beyond the bare schema.

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 clearly states the tool's purpose as 'Run one or more Gradle tasks' with a specific verb ('Run') and resource ('Gradle tasks'). It distinguishes from siblings like 'clean' or 'list_project_tasks' by focusing on execution rather than cleanup or listing, though it doesn't explicitly contrast them.

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like 'clean' or 'list_project_tasks' for task discovery.

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

stop_daemonA

Stop all Gradle daemons.

Stops all running Gradle daemons. Useful for freeing up memory or when experiencing daemon-related issues.

Returns: TaskResult with success status and error message if failed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNo
successYes

TDQS

A4.7/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 burden of behavioral disclosure. It clearly states this is a destructive operation ('Stops all running Gradle daemons'), mentions the purpose (freeing memory, resolving issues), and describes the return format (TaskResult with success/error). However, it doesn't specify potential side effects like interrupting ongoing builds or permission requirements.

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

Conciseness5/5

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

The description is perfectly structured with zero waste: first sentence states the core action, second explains purpose and use cases, third describes return format. Every sentence earns its place, and it's appropriately sized for a simple tool with no parameters.

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 simplicity (0 parameters, no annotations, but has output schema), the description is complete enough. It explains what the tool does, when to use it, and what it returns. The output schema handles return value details, so the description doesn't need to elaborate further on response structure.

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 0 parameters with 100% coverage, so the baseline would be 4 even without parameter information in the description. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's behavior and output.

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 specific action ('Stop all Gradle daemons') and distinguishes it from siblings like 'daemon_status' (which checks status) and 'run_task' (which executes tasks). It explicitly identifies the resource being acted upon (Gradle daemons) with a precise verb (stop).

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

Usage Guidelines5/5

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

The description explicitly provides when to use this tool ('Useful for freeing up memory or when experiencing daemon-related issues') and distinguishes it from alternatives by focusing on stopping daemons rather than checking status (daemon_status) or performing other operations. It gives clear context for application.

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.

  1. 6 tool updatesv1.0.0
    • Changedclean2 fields changed
      • addedOutput schema / $defs
        Added value: +{
+  "CompilationError": {
+    "description": "A single compilation error.",
+    "properties": {
+      "column": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "file": {
+        "type": "string"
+      },
+      "line": {
+        "type": "integer"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "file",
+      "line",
+      "column",
+      "message"
+    ],
+    "type": "object"
+  },
+  "ErrorInfo": {
+    "description": "Structured error information.",
+    "properties": {
+      "compilation_errors": {
+        "items": {
+          "$ref": "#/$defs/CompilationError"
+        },
+        "type": "array"
+      },
+      "failed_tasks": {
+        "items": {
+          "$ref": "#/$defs/FailedTask"
+        },
+        "type": "array"
+      },
+      "summary": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "summary",
+      "failed_tasks",
+      "compilation_errors"
+    ],
+    "type": "object"
+  },
+  "FailedTask": {
+    "description": "Information about a failed task.",
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "reason": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "reason"
+    ],
+    "type": "object"
+  }
+}
      • changedOutput schema / properties / error / anyOf
        Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/ErrorInfo"
+  },
+  {
+    "type": "null"
+  }
+]
    • Addeddaemon_status
    • Addedget_gradle_config
    • Changedlist_project_tasks6 fields changed
      • addedInput schema / properties / group
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedInput schema / properties / include_descriptions
        Added value: +{
+  "default": false,
+  "type": "boolean"
+}
      • addedOutput schema / $defs / GroupedTasksInfo
        Added value: +{
+  "description": "Tasks grouped by their group name.\n\nWhen include_descriptions is True, tasks contains TaskWithDescriptionInfo objects.\nWhen include_descriptions is False, tasks contains task name strings.",
+  "properties": {
+    "group": {
+      "type": "string"
+    },
+    "tasks": {
+      "anyOf": [
+        {
+          "items": {
+            "$ref": "#/$defs/TaskWithDescriptionInfo"
+          },
+          "type": "array"
+        },
+        {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      ]
+    }
+  },
+  "required": [
+    "group",
+    "tasks"
+  ],
+  "type": "object"
+}
      • removedOutput schema / $defs / TaskInfo
        Removed value: -{
-  "description": "Information about a Gradle task.",
-  "properties": {
-    "description": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "group": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null
-    },
-    "name": {
-      "type": "string"
-    },
-    "project": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "name",
-    "project"
-  ],
-  "type": "object"
-}
      • addedOutput schema / $defs / TaskWithDescriptionInfo
        Added value: +{
+  "description": "Task with its description.",
+  "properties": {
+    "description": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "description"
+  ],
+  "type": "object"
+}
      • changedOutput schema / properties / result / items / $ref
        Previous value: -"#/$defs/TaskInfo"New value: +"#/$defs/GroupedTasksInfo"
    • Changedrun_task4 fields changed
      • addedInput schema / properties / task / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
      • removedInput schema / properties / task / type
        Removed value: -"string"
      • addedOutput schema / $defs
        Added value: +{
+  "CompilationError": {
+    "description": "A single compilation error.",
+    "properties": {
+      "column": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "file": {
+        "type": "string"
+      },
+      "line": {
+        "type": "integer"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "file",
+      "line",
+      "column",
+      "message"
+    ],
+    "type": "object"
+  },
+  "ErrorInfo": {
+    "description": "Structured error information.",
+    "properties": {
+      "compilation_errors": {
+        "items": {
+          "$ref": "#/$defs/CompilationError"
+        },
+        "type": "array"
+      },
+      "failed_tasks": {
+        "items": {
+          "$ref": "#/$defs/FailedTask"
+        },
+        "type": "array"
+      },
+      "summary": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "summary",
+      "failed_tasks",
+      "compilation_errors"
+    ],
+    "type": "object"
+  },
+  "FailedTask": {
+    "description": "Information about a failed task.",
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "reason": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "reason"
+    ],
+    "type": "object"
+  }
+}
      • changedOutput schema / properties / error / anyOf
        Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/ErrorInfo"
+  },
+  {
+    "type": "null"
+  }
+]
    • Addedstop_daemon
  2. 4 tool updates
    • First observedclean
    • First observedlist_project_tasks
    • First observedlist_projects
    • First observedrun_task
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a distinct purpose with clear boundaries: clean removes artifacts, daemon_status monitors daemons, get_gradle_config retrieves configuration, list_projects enumerates projects, list_project_tasks shows available tasks, run_task executes tasks, and stop_daemon terminates daemons. There is no overlap or ambiguity between these functions.

Naming Consistency4/5

Tools follow a consistent verb_noun pattern (e.g., clean, daemon_status, get_gradle_config, list_projects, list_project_tasks, run_task, stop_daemon), with all using snake_case. The minor deviation is 'get_gradle_config' using 'get_' prefix while others like 'list_' or 'run_' use different verbs, but overall naming is predictable and readable.

Tool Count5/5

With 7 tools, the server is well-scoped for Gradle project management. It covers essential operations like cleaning, task execution, project listing, configuration retrieval, and daemon control, without being overly sparse or bloated. Each tool serves a clear purpose in the domain.

Completeness4/5

The toolset provides comprehensive coverage for core Gradle workflows, including project discovery, task management, execution, and daemon handling. A minor gap is the lack of tools for modifying configuration (e.g., updating gradle.properties) or advanced operations like dependency management, but agents can work around this with existing tools for most common tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Gradle Tomcat MCP Server

    lkb2k
    A
    license
    A
    quality
    D
    maintenance
    Enables management of Gradle-based Tomcat applications with capabilities for starting, stopping, restarting processes and querying application logs.
    6
    1
    MIT

  • Build MCP Server

    TeodorTrotea
    F
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to manage development workflows by running build commands, executing tests, analyzing package.json files, installing dependencies, and performing code linting. Supports multiple package managers (npm, yarn, pnpm) and provides detailed error reporting for development operations.
    5
    -