Twelve Android MCP Servers Compared: Local or Hosted
Stars run from 155 to 16,088, but the real split is where your agent runs. A look at the twelve Android MCP servers and the Play policy line.
Twelve MCP servers now let an AI agent see and control an Android device, and the GitHub star counts behind them range from 155 to 16,088.
The comparison was published on 18 October 2026 by Alon N, with "GitHub numbers checked on October 16, 2026". It carries a disclosure: "I work on Phonebox, one of the twelve servers below." Read the vendor's own ranking with that in mind — but the star counts, transports and screen-reading methods are checkable facts, and they are what the choice turns on.
The split that actually decides it
Not stars. Transport. "Every local server needs an emulator or a USB phone that adb can see, on the same machine as the agent. That's free and fast on a workstation, and impossible on most CI runners and cloud sandboxes."
So the first question is where your agent runs. On your laptop, a local server is free. In CI, in a cloud sandbox, or on a teammate's machine, you need a hosted server with a phone attached — which means a platform account or API key for whoever supplies that phone.
The shortlist
| Server | Stars | Runs | iOS too |
|---|---|---|---|
| Maestro MCP | 16,088 (Maestro) | Local, in the Maestro CLI | Simulators |
| mobile-mcp | 9,669 | Local (stdio or HTTP) | Yes |
| agent-device (Callstack) | 5,051 | Local CLI and MCP | Yes |
| Patrol MCP | 1,447 (Patrol) | Local, Flutter projects | Yes |
| Appium MCP | 498 | Local, or your Appium grid | Yes |
| BrowserStack MCP | 155 | Local or hosted (OAuth) | Yes |
The default pick for a local workstation is mobile-mcp — the comparison calls it "free, active, Android and iOS, with logs, screen recording and location built in". If your team already runs Appium or Maestro, the matching MCP server rides on the CLI you have; Patrol MCP is the Flutter path. One listed option, minhalvp's android-mcp-server at 811 stars, has had "no commits since May 2025".
Two names that rank for the same searches do something else entirely: "Google's Android Management API MCP manages enterprise device policies, not the screen. mikechambers/adb-mcp controls Adobe apps, not Android."
How the agent reads the screen
Every server exposes some form of the same loop — observe, act, check — but the representation differs: an accessibility tree, Appium's page-source XML and locators, Maestro's view-hierarchy JSON, or a numbered text list of elements. The companion piece argues text beats pixels for durability: "tap Sign in" still works after a redesign moves the button.
The policy line to know first
Accessibility-driven automation is fine on your own connected device and risky as a product. "Google Play's policy prohibits shipping an app that uses AccessibilityService to autonomously plan and execute actions."
The sanctioned path is Android AppFunctions, where apps annotate functions with @AppFunction and agents call them directly on-device — Google describes it as "the mobile equivalent of tools within the Model Context Protocol". It is also "experimental, needs Android 16, and only works for apps that adopted it, called by a limited set of system agents". Gemini's in-app tasks, in beta since February 2026, cover DoorDash, Uber, Lyft, Instacart and a few others on Pixel 10 and Galaxy S26 in the US and Korea — and stop before the buy button for you to tap.
Practical read: pick by where the agent runs, start with mobile-mcp on a local device, and keep a human on anything that pays or authenticates. Watch AppFunctions adoption — the day the apps you care about ship it, screen-driving stops being the only route.
More from DangMua