Loading ToolBench
Model Context Protocol (MCP) server enabling AI agents (Claude, Cursor, LLMs) to control, inspect, and automate Android devices and Waydroid via ADB.
12 tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (android_*) and are action-oriented. Descriptions are present (avg ~100 chars) but lack context on when to use each tool and what to expect in responses. Parameters have types but many lack descriptions (e.g., android_check_connection, android_screenshot, android_get_ui_tree have empty required arrays with no param docs). No documented output schemas, LLMs cannot plan downstream calls. Error handling is absent from descriptions. Security-critical tool (android_shell) lacks warnings about command injection risks.
Check connection status with Android device or emulator, returning model and Android OS version.
Smart-click: searches the screen UI hierarchy for an element with matching text or description and taps its center.
Inspect all visible UI elements on the current Android screen, returning text labels, resource IDs, and bounding coordinates.
Launch an Android app by its package name (e.g. com.android.settings).
List installed application package names on the device.
Press an Android hardware/system key (BACK, HOME, ENTER, TAB, POWER, VOLUME_UP, VOLUME_DOWN).
No output schemas documented. LLMs cannot infer what fields to expect from tool responses (e.g., does android_check_connection return {model, version} or {device_model, android_version, build_id}?). This breaks tool chaining and forces agents to guess field names.
android_shell lacks security warnings and error guidance. Executing arbitrary shell commands is irreversible and injection-prone. Description should warn about command injection risks and guide LLMs to validate/escape inputs. No mention of what errors to expect or how to recover.
Parameters in no-arg tools (android_check_connection, android_screenshot, android_get_ui_tree) have empty required arrays but no descriptions of what they return or when to call them. Descriptions lack context on prerequisites (e.g., 'Requires device connected via ADB') and expected output structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Capture the current screen of the Android device and return it as a base64 PNG image for visual analysis.
Execute an ADB shell command directly on the Android device.
Force-stop a running Android application.
Perform a swipe or drag gesture from (x1, y1) to (x2, y2).
Tap on specific screen coordinates (x, y).
Type a string of text into the currently active input field on Android.
No error handling guidance in any tool description. LLMs cannot distinguish retryable errors (device disconnected) from fatal ones (invalid coordinates). Descriptions should include 'If device disconnected, reconnect and retry' or 'Invalid coordinates, ensure x/y are within screen bounds.'
Coordinate parameters (x, y, x1, y1, x2, y2) lack range constraints. Descriptions should specify 'X coordinate in pixels (0 to screen width)' and validate that coordinates are within device bounds. Unbounded integers invite out-of-range taps.