Loading ToolBench
MCP server that lets coding agents build, install, drive and debug Android apps on a real device or emulator
Strong tool naming (all verb_noun pattern), comprehensive descriptions (avg 180 chars, well above 34-char baseline), and detailed parameter schemas with enums and constraints. All 16 tools have descriptions and input schemas. However, output schemas are not explicitly documented in the source code, responses are described narratively rather than as structured JSON schemas. Error handling is present but recovery guidance is minimal. Tool composition is excellent (single responsibility, clear chaining via serial parameters). Missing: explicit output schema documentation, per-tool error classification, and confirmation patterns for destructive operations.
Build (and optionally install and launch) an Android app. Run a Gradle assemble for an Android project and, when asked, install the APK and start it on a device — the full edit-run loop in one call. Handles the toolchain details that normally break automated builds: picks a JDK Gradle can actually run on (Android Studio's bundled JBR when present), instead of trusting the ambient JAVA_HOME; refuses to start, with an explanation, when the JDK is newer than the Gradle wrapper supports; condenses a failed build's log down to the compiler errors instead of returning thousands of progress lines.
Connect to a device over TCP/IP (Wi-Fi). Useful when USB is unavailable or you want to work wirelessly. The device must be on the same network and have USB debugging enabled. After connecting, use the IP:port address as the serial for other tools.
Describe a connected device in detail: OS version, SDK level, screen geometry, rotation, manufacturer. Useful for understanding device capabilities and debugging layout issues.
Diagnose the Android toolchain: adb, Gradle, JDK, SDK, and device connectivity. Run this when something is not working to get a detailed report of what is installed and what is missing.
Install an APK on a device. Use this when the APK is already built and you only want to install it (or reinstall it). For the full build-install-launch loop, use android_build with install=true and launch=true.
Output schemas not explicitly documented. Tool descriptions state what is returned (e.g., 'Returns a table of serial numbers, states, and properties') but JSON Schema output structures are not visible in source. LLMs cannot reliably parse unstructured responses or plan downstream tool calls without knowing field names and types.
android_screenshot lacks input schema documentation. Parameter 'serial' is described but no explicit type/format is shown in the provided source. Schema score reduced accordingly.
Destructive operations (android_uninstall) lack confirmation or dry-run patterns. No explicit recovery guidance in error responses. Agents could uninstall apps without user confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Press a hardware key or send a key code. Useful for navigation (BACK, HOME), text input (ENTER, DEL), and media control (PLAY, PAUSE).
List connected Android devices and emulators. Returns a table of serial numbers, states, and properties. Use this to pick a device serial for other tools when more than one is connected.
Read the device log (logcat). Useful for debugging app crashes, ANRs, and runtime errors. Filters by package name and log level. Returns the most recent lines.
Take a screenshot of the device screen. Returns the image as a PNG. Useful for verifying the UI state and debugging layout issues.
Set the text of a focused input field directly, bypassing the keyboard. Supports non-ASCII characters (Unicode, emoji, etc.). Faster and more reliable than typing.
Swipe from one point to another on the screen. Useful for scrolling, swiping between pages, and other gesture-based interactions.
Tap a point on the screen. Coordinates are in pixels from the top-left corner. Useful for clicking buttons, links, and other UI elements.
Run a project's tests. Run a Gradle project's tests and report which ones failed. This is the verification half of the loop: after changing code, prove the change works rather than assuming it. Failure output is condensed the same way android_build condenses it — you get the failing test names, not the whole Gradle log. Two kinds of test: 'unit' runs testDebugUnitTest on the JVM. Fast, no device needed. 'instrumented' runs connectedDebugAndroidTest on a connected device or emulator. Slower, and requires a device.
Type text into the focused input field. Only works with ASCII characters; for non-ASCII text, use android_set_text or an IME that accepts adb broadcasts.
Uninstall an app from a device by package name. Useful for cleaning up before a fresh install or testing uninstall scenarios.
Dump the view hierarchy of the currently visible screen. Returns an XML tree of all views, their IDs, text content, and layout bounds. Useful for understanding the UI structure and finding elements to interact with.
Error handling is present but lacks actionable recovery guidance. Tool descriptions mention 'condensed' error output but do not specify error categories (retryable, user-fixable, fatal) or next steps for the LLM.
Interaction tools (android_tap, android_swipe, android_type, android_key, android_set_text) lack detailed parameter constraints. Coordinate ranges, key name enums, and text length limits are not formally specified in visible schemas.