Skip to main content
Glama
Sign In
adb-mcp

adb-mcp

by iksnerd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gradle_build

Build an Android project with Gradle (default assembleDebug) and get a compact status, error summary, log path, and fresh APK list. Run long builds in the background and poll with build_status.

Instructions

Build the app with Gradle (default task assembleDebug) in project_dir. project_dir must contain the Gradle wrapper (gradlew). Runs on the host, not a device. Returns a compact summary (status, duration, error count, first errors) and the path of the full log, with credential-shaped values redacted. It also lists the APKs under build/outputs, newest first; that can include APKs left by earlier builds. For builds that take minutes pass background=true: it returns a job id and log path at once, and build_status reports the result.

Input Schema

NameRequiredDescriptionDefault
argsNoExtra arguments passed to Gradle (e.g. --stacktrace, -Pflavor=free).
taskNoGradle task to run. Defaults to assembleDebug.
backgroundNoStart the build detached and return at once with a job id and log path; poll with build_status. Use for builds that take minutes.
project_dirNoPath to the Android project root containing the Gradle wrapper (gradlew). Optional if session_set_defaults has pinned a project_dir for this session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.24.3
    • addedInput schema / properties / background
      Added value: +{
+  "description": "Start the build detached and return at once with a job id and log path; poll with build_status. Use for builds that take minutes.",
+  "type": "boolean"
+}
    • removedInput schema / properties / json
      Removed value: -{
-  "description": "For run_unit_tests/run_instrumented_tests: return the test summary as structured JSON (per-suite timing, full failure stack traces) instead of the human-readable text summary. Ignored by gradle_build and list_gradle_tasks.",
-  "type": "boolean"
-}
    • changedInput schema / properties / task / description
      Previous value: -"Gradle task to run. Defaults to the tool's standard task."New value: +"Gradle task to run. Defaults to assembleDebug."
  2. First observedv1.0.0

TDQS

A4.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 it well: it discloses host execution, credential-shaped value redaction, that the APK listing is newest-first and may include stale APKs from earlier builds, the compact return summary plus full-log path, and the detached job-id behavior in background mode.

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?

Front-loads what it builds and where, then adds return shape, redaction caveat, stale-APK caveat, and background guidance in sequence. Every sentence carries distinct information with no repetition of the schema.

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?

No output schema exists, so the description supplies the return contract (status, duration, error count, first errors, log path, APK list) and covers the async path. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3; the description adds the default task value, the gradlew precondition on project_dir, and reinforces background's return shape (job id and log path) with the polling tool named, going slightly beyond the schema text.

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+resource (build the app with Gradle) plus the default task, project_dir requirement, and that it runs on host not a device. This clearly separates it from siblings like build_and_run, install_app, and list_gradle_tasks.

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?

Gives explicit conditional guidance: pass background=true for long builds and poll with build_status, and notes project_dir is optional when session_set_defaults pinned one. It lacks an explicit contrast with the sibling build_and_run, so the agent must infer which build tool to pick when the goal is to also deploy.

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