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-
- AlicenseNot gradedqualityBmaintenanceEnables coding agents to build, install, and launch Android apps on emulators and physical devices, automate UI interactions, inspect logcat/crash diagnostics, measure JaCoCo coverage, and discover or scaffold projects through an MCP server.392 npmMIT
- AlicenseBqualityDmaintenanceAn 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.14105 npm19MIT
- AlicenseNot gradedqualityBmaintenanceA local-first MCP server that enables AI agents to inspect and debug Android apps and devices through typed tools for UI interaction, logcat, Java/Kotlin and native/Flutter debugging, performance traces, heap dumps, artifacts, and evidence-based diagnostics.1Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables 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.392 npmMIT
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.