Android Studio MCP
Related Servers
Alternatives to Android Studio MCP
No user-submitted related servers found.
Related Servers
- FlicenseNot gradedqualityAmaintenanceMCP server that provides AI coding agents real Android development tools—Gradle, adb, logcat, lint, crash triage—through a local, permissioned interface. Enables agents to inspect projects, run safe Gradle tasks, capture logs/screenshots, and triage crashes.1-
- AlicenseBqualityCmaintenanceAn MCP server that enables AI assistants to build, test, and debug Android applications by interacting directly with the Android development environment. It provides tools for managing emulators, executing Gradle tasks, running ADB commands, and performing UI automation via accessibility trees.41460 npm18MIT
- 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 gradedqualityAmaintenanceGives MCP-compatible AI assistants vision and control over Android devices — capturing screenshots, tapping, swiping, typing, launching apps, inspecting UI elements, streaming audio/video, transferring files, and running shell commands over ADB, with a fast binary control protocol for near-instant input and screenshots.151 npmMIT
- AlicenseNot gradedqualityAmaintenanceConnects MCP-compatible AI assistants to Android devices, letting them see the screen and act on it through screenshots, taps, swipes, typing, app and UI management, shell commands, file transfer, and clipboard access. It routes interaction through scrcpy's control protocol for fast input and near-instant screen captures, falling back to ADB when no session is active, and adds audio/video streaming and recording.151 npmMIT
- 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 46 tools
Most tools target distinct resources, but several overlap enough to cause misselection: studio_open vs ide_open (both open files in Studio), run_app vs ide_run (both deploy and launch a variant), and ide_problems vs ide_project_problems vs lint_results (three ways to surface errors). The detailed descriptions mitigate but don't fully resolve the boundaries.
There is a general prefix-based convention (ide_*, app_*, emulator_*, device_*, project_*), but ordering is inconsistent (app_launch is noun_verb while ide_read_file is prefix_verb_noun) and several tools are bare unprefixed names (build, input, screenshot, logcat, environment). Readable, but the conventions are mixed rather than predictable.
46 tools is well past the '25+ is too many' threshold, and while the IDE+device+build surface is broad, there are real consolidation opportunities (multiple run tools, multiple problem-analysis tools, IDE-action plumbing). The weight increases the chance of an agent picking a near-duplicate.
The surface covers the full lifecycle: environment discovery, project introspection, Gradle build/test, IDE control, device/emulator management, UI automation, screenshots, logs, and file transfer. Gaps are minor (no breakpoint/debugger control or profiling tools), which agents can work around.