Skip to main content
Glama
Fdondi

android-agent

by Fdondi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

android_build

Run Gradle builds safely alongside Android Studio, avoiding file lock conflicts, and get a detailed failure report with errors, context, and a markdown brief for quick fixes.

Instructions

Build the project with Gradle, safely alongside Android Studio, and explain any failure.

ALWAYS use this instead of running gradlew in a terminal: an agent terminal runs Gradle in a sandboxed daemon that keeps R.jar locked against Android Studio. This tool runs the build in Android Studio's own daemon pool, waits if Studio is building, and names any process holding a locked file.

On failure the result is a complete report: category, every compiler/resource error with its file, line and surrounding source, Gradle's explanation, recently changed files, and the path of a self-contained markdown brief you can hand to a fixer subagent.

Args: project_dir: Gradle root (the folder containing settings.gradle[.kts] and gradlew). module: App module, used to derive the default task and find the APK. variant: Build variant, e.g. debug or freeDebug. tasks: Explicit Gradle tasks. Default "::assemble". For a fast compile-only check use [":app:compileDebugKotlin"]. install: Install the built APK on the device afterwards. device: Device serial for install; defaults to the first physical device. release_locks: Stop IDLE Gradle/Kotlin daemons that hold this project's build outputs (e.g. one left behind by an agent terminal). Never touches busy builds. allow_uninstall: If install hits a signature/version conflict, uninstall first (wipes data). wait_if_busy_s: How long to wait for a busy Android Studio daemon before giving up. timeout_s: Build time limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksNo
deviceNo
moduleNoapp
installNo
variantNodebug
timeout_sNo
project_dirYes
release_locksNo
wait_if_busy_sNo
allow_uninstallNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/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 meets it by disclosing daemon behavior, waiting, lock naming, uninstall data wiping, and idle daemon release. It also details the failure report contents, including source snippets and a markdown brief path for a fixer subagent.

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 organized into a terse imperative summary, a bold routing warning, failure-report detail, and a labeled Args block. Every sentence earns its place by providing selection guidance, behavioral transparency, or parameter meaning.

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?

For a complex build tool with no output schema, the description explains both return behavior and all parameters, plus side effects like installation and locking. It leaves no significant gap an agent would need to guess about before invoking the tool.

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?

Despite 0% schema description coverage, the 'Args:' section explains all 10 parameters with defaults and intent, including task derivation and an example. It adds semantically rich guidance—such as release_locks not touching busy builds and allow_uninstall wiping data—that is not inferable from the bare 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 states a specific action—'Build the project with Gradle'—and immediately distinguishes the tool from sibling alternatives by emphasizing safety 'alongside Android Studio'. It also specifies the tool's unique failure-report behavior, making its role unmistakable.

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 gives explicit routing guidance: 'ALWAYS use this instead of running gradlew in a terminal', with a concrete rationale about R.jar locking. It also advises on fast compile-only checks and lock release, giving agents actionable decision criteria.

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

Deploy Server

Other Tools