android-mcp
Related Servers
Alternatives to android-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables Claude or any MCP agent to see and operate a real Android phone over adb, with fast screen reads, tap/type/swipe actions, app launching, deep links, and brand-aware setup guidance, all without admin rights or an Android SDK.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to control a physical Android device or Docker-hosted emulator over ADB by taking screenshots and performing taps, swipes, key presses, text input, shell commands, app launches, and device info queries. It runs as a local MCP stdio server alongside a web UI and REST API for remote access.1MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to control Android devices via ADB, providing tools for screen capture, tap/swipe/input, app management, and diagnostics. Works locally over USB or WiFi and integrates with MCP clients like Claude and Cursor.1MIT
- AlicenseNot gradedqualityBmaintenanceEnables controlling an Android device from an MCP client via ADB, including wireless debugging discovery, UI-tree inspection, and performing taps, swipes, typing, app actions, and shell commands without relying on screen coordinates.5 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables Android device control over ADB through MCP tools that mirror CLI subcommands, including taps, swipes, text input, app launch/stop, screenshots, UI inspection, and running action sequences. Coordinates from screenshots are converted to screen coordinates automatically.MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents and test runners to control Android devices via local ADB, including listing devices, tapping, swiping, typing, sending system keys, launching apps, and dumping UI hierarchy. Communicates over MCP stdio without exposing network listeners.-
TDQS
Scored across 13 tools
Each tool maps to a distinct action or resource: element-targeted tap vs coordinate tap, swipe vs press_key vs type_text are clearly separated, and observation tools (screenshot, screen_elements, current_app, logcat, devices) each return different data. Descriptions reinforce the boundaries (e.g. screen_elements is explicitly framed as a cheaper alternative to screenshot for tapping).
Action tools follow a consistent verb_noun pattern (tap_element, type_text, press_key, list_apps, launch_app, install_apk), while read-only/inspection tools use bare nouns (devices, screenshot, logcat, current_app, screen_elements) and two are bare verbs (tap, swipe). The split is readable and roughly correlated with purpose, but it is not a single uniform convention.
13 tools is well within the ideal range and each earns its place: input, navigation, app lifecycle, device discovery, and diagnostics are all represented without redundancy.
Covers the core device-control lifecycle (inspect screen, tap/type/swipe/key, launch/install/list apps, logs, screenshot, device list). Minor gaps remain: no long-press or drag gesture, no way to clear an input field, and no keyevent beyond the enumerated set, but agents can work around most of these.