Skip to main content
Glama
This server has been deprecated

Rebranded to ComposeLint AI. Repository has been moved to TechsOneAi/ComposeLintAI.

run_gradle_build

Run whitelisted Gradle tasks asynchronously to verify code changes compile before continuing, returning a job ID for status polling.

Instructions

Run a Gradle task with async tracking support.

When to use:
- Call to verify that surgical edits or token refactorings compile without errors.
- Call after batch changes before approving or completing a task.

When NOT to use:
- Do not use for arbitrary shell execution; tasks are strictly whitelist-restricted.
- Do not use for simple file reading or AST validation (use check_syntax_cli or ast_finder instead).

Side effects:
- Executes a Gradle build process in background; may write build artifacts to build/ directories.


This lets the agent verify that code changes compile successfully
before continuing with more changes, without locking the MCP connection.

Args:
    task: gradle task to run (whitelist enforced: assembleDebug, assembleRelease, test, lint, clean, etc.).
    timeout_seconds: max execution time (default 5 min).
    async_mode: if true (default), returns job_id immediately so agent can poll with get_gradle_status.

Returns:
    JSON with job_id and status, or execution result if sync.

Input Schema

NameRequiredDescriptionDefault
taskNoassembleDebug
async_modeNo
timeout_secondsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.5
    • addedInput schema / properties / async_mode
      Added value: +{
      +  "default": true,
      +  "title": "Async Mode",
      +  "type": "boolean"
      +}
  2. Added
  3. Removed
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that the build runs in the background, that it writes artifacts to build/ directories, that tasks are whitelist-restricted, and that async mode returns a job_id for polling with get_gradle_status. This explains why readOnlyHint=false without contradicting destructiveHint=false, since artifacts are build output rather than user data.

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?

Well front-loaded and sectioned (When to use / When NOT to use / Side effects / Args / Returns), so an agent can scan quickly. Slight redundancy: the paragraph 'This lets the agent verify that code changes compile…' restates the when-to-use bullets, and the Args/Returns text duplicates the input and output schemas.

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 non-readonly build-invocation tool with an output schema present, the description covers side effects, async lifecycle, and the follow-up tool. The only omission is a concrete pointer for discovering the full task whitelist, which would be useful given the incomplete enumeration.

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 carries the load and does document all three parameters: task with whitelist enforcement and example values, timeout_seconds with a 5-minute default, and async_mode with its default and downstream polling behavior. The whitelist list is left as 'etc.' and does not point to the sibling list_allowed_gradle_tasks, which would have closed the remaining gap.

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?

States a specific verb and resource ('Run a Gradle task') plus the differentiating trait 'with async tracking support'. An agent can distinguish it from get_gradle_status (polling) and list_allowed_gradle_tasks (enumeration) without opening any schema.

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?

Explicit when-to-use bullets (verify surgical edits compile, run after batch changes) and explicit when-NOT-to-use bullets that name the alternative tools (check_syntax_cli, ast_finder) for the cases this tool does not cover. The alternative-routing is fully spelled out.

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