Loading ToolBench
Android device MCP tools for managing Android devices via ADB (Android Debug Bridge)
This MCP server has 18 tools with varying quality. Tool naming is generally good (verb_noun pattern), but parameter and output documentation is severely lacking. While tool descriptions exist and meet minimum length (10-1024 chars), parameter descriptions are mostly adequate but lack important details like constraints, ranges, and valid values. Critical issues: (1) No visible output schemas documented anywhere, LLMs cannot predict what fields will be returned; (2) Many parameters lack proper validation guidance (e.g., no constraints on timeout values, no enum for shell commands); (3) No error handling guidance visible, tools don't indicate recovery steps or error categories; (4) High-risk operations (reboot_device, shutdown_device, uninstall_app, execute_shell_command) have no confirmation/dry-run patterns; (5) Missing actionable error messages that could guide the LLM on retry or alternatives. Naming is solid (list_*, get_*, execute_*, etc.) but the pattern:tool and pattern:command-tool requirements are not fully satisfied.
Clear logs from logcat on a specific Android device
Dump current screen of Android device.
Execute shell command in an Android device.
Retrieve detailed information about an installed app using its name or package name.
Get and save logs from logcat on a specific Android device
Retrieve network, Wi-Fi information for an Android device by serial number.
Install an APK file on an Android device.
No output schemas documented for any tool. LLMs cannot predict field names, types, or structure of responses. This violates pattern:tool and pattern:response-shaper requirements. A call to list_installed_apps returns ???, the LLM must guess whether to expect {apps: []} or {data: {apps: []}} or a plain array.
High-risk irreversible operations (reboot_device, shutdown_device, uninstall_app, execute_shell_command) lack confirmation/dry-run patterns. Agents can accidentally reboot all devices or delete critical apps without a confirmation step. Per pattern:command-tool, destructive operations should require explicit confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Launch an APP in an Android device.
List all connected Android devices with their serial numbers and detailed info.
List all files in a given directory on an Android device using its serial number.
List all installed applications on a specific Android device
Pull or copy files from a given directory on an Android device using its serial number.
Push or copy files from a given directory on local machine to an Android device using its serial number.
Reboot a specific Android device using its serial number.
Record the screen of an Android device using its serial number.
Shut down a specific Android device using its serial number.
Capture a screenshot from an Android device using its serial number.
Uninstall an APP from an Android device.
No error handling guidance visible in code. Tools provide no recovery hints or error classification (retryable vs user-fixable vs fatal). If execute_shell_command fails, the LLM has no guidance on what went wrong or what to try next. Per pattern:recovery-guide, errors should tell the LLM what to do.
Parameter descriptions lack constraints and validation guidance. Examples: (1) time_out in get_device_logs has no range (0 - 3600? 1 - 60?); (2) mode in reboot_device lists no valid values (bootloader? recovery? fastboot?); (3) execute_shell_command accepts arbitrary shell commands with no injection guards or allowed-command list. Per pattern:constrained-input, parameters should declare enums and ranges.
Parameter 'serial' is required across all 18 tools but is treated as a free-form string. No guidance on format (e.g., 'emulator-5554' vs 'FA6AX1A123'). If a lookup tool (search_devices_by_name) existed, serial could be discovered; currently, LLMs must guess or ask the user. Per pattern:natural-identifiers, tools should accept user-friendly identifiers.
No pagination or result-limiting visible for tools that return lists (list_installed_apps, list_devices, list_files). If a device has 1000 installed apps, does the tool return all 1000? Per pattern:paginated-result, list tools should support page/limit/offset and return a total count.
Tool composition concern: no batch variants for operations agents commonly call in loops. If an agent needs to uninstall 5 apps, it must call uninstall_app 5 times. A batch uninstall_apps([package_names]) tool would be more efficient and reduce token waste.
The 'mode' parameter in reboot_device is marked optional but has no enum or description of valid values. Android supports modes like 'bootloader', 'recovery', 'fastboot', 'sideload', etc. Without constraints, LLMs will guess invalid values. Per pattern:constrained-input, optional params with enumerated values must declare them explicitly.