AndroidBuildMCP
Related Servers
Alternatives to AndroidBuildMCP
No user-submitted related servers found.
Related Servers
- AlicenseAqualityCmaintenanceEnables coding agents to build, drive, and debug Android apps on a real device, with screenshots, UI dumps, local vision model analysis, and lock-safe Gradle builds.21MIT
- AlicenseAqualityCmaintenanceEnables AI assistants to build, drive, and observe Android/KMM apps end-to-end through ADB and Gradle, with tools for UI automation, error capture, and testing.3324 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables AI coding agents to build, test, lint, and debug Android projects with concise Gradle output, filtered logcat, and connected-device inspection and interaction. It also supports setup across several agent clients and caps noisy output to save tokens.13 npmMIT
- AlicenseBqualityBmaintenanceEnables AI agents to control Android devices and emulators through direct UI interaction, allowing app navigation, automated testing, and real-world task execution via ADB without computer vision or scripts.182MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI assistants and IDEs to drive real Android devices and emulators for cross-app UI automation, testing, and diagnostics, including collecting Logcat output and screenshots.Apache 2.0
- AlicenseAqualityDmaintenanceEnables an agent to inspect and interact with Android emulators or physical devices via ADB, capturing UI snapshots, tapping nodes, typing text, and reading app logs.10MIT
TDQS
Scored across 53 tools
Most tools have clear, distinct purposes (build, device, UI, logging). A few pairs like snapshot_ui and screenshot with annotate could be confused, but descriptions clarify their complementary roles. Overall, the tool set is well-separated into functional areas.
Tools overwhelmingly follow a verb_noun snake_case pattern (build_app, list_devices, start_log_capture). Minor exceptions like statusbar_demo_mode and session_set_defaults are still intuitive and consistent in style. No mixing of camelCase or arbitrary names.
53 tools is excessive given the rule that 25+ is too many. While the scope is broad and each tool has a purpose, the sheer number creates navigation overhead and can overwhelm an agent. A more consolidated set would be better.
The tool surface thoroughly covers the Android development lifecycle: project discovery, building, testing, linting, device/emulator management, UI automation, logging, coverage, and scaffolding. There are no major dead ends or obvious missing operations for the stated purpose.