android-remote-control-mcp: an MCP server that lives on the phone
An MCP Server for Android running on the phone, optmized for token usage, supports also files downloads and cloudflare and ngrok automated tunnelling.
At a glance
- What is it?
- A Kotlin Android app that exposes 57 MCP tools over HTTP from the device itself, with optional Cloudflare or ngrok tunnelling. The design bet is that skipping ADB cuts action latency and token cost. The trade-off is that you are granting an AI model accessibility-level control of a phone you probably carry everywhere.
- Who is it for?
- Adopt it if your target is a spare or emulated Android device, you want the MCP endpoint reachable from outside the LAN, and you are willing to work through the Accessibility, Camera and file permissions the tools need. Do not adopt it if you need iOS coverage, if your workflow already standardises on ADB from a host machine, or if the device under control holds accounts you cannot afford to expose.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: ADB in the loop
Most Android automation stacks for AI agents put a computer between the model and the phone. The agent speaks to a host process, the host process speaks ADB, ADB speaks to the device. That chain works, but it imposes two costs that show up in agent loops. The first is latency: the README's comparison table lists 1 to 4 seconds for ADB-based alternatives against 10 to 100 ms for this project. The second is tokens. ADB-based tools typically hand back raw uiautomator XML dumps, which the README describes as 10 to 50 times more verbose than the compact screen representation this project uses. In a loop where the model reads the screen, decides, acts, and reads again, both costs compound per step.
The audience is narrow but real: people building agentic workflows against Android who are willing to run the server on the device rather than beside it. The README frames the project as research and educational, and carries an explicit warning that the authors do not condone illegal or unauthorised use. That is not boilerplate. A tool that reads UI elements, taps, types, and captures screenshots across any app on a phone is the same capability set an account-takeover script would need.
What actually runs on the device
The application is an Android app written in Kotlin. Inside it, Ktor with Netty serves an HTTP endpoint, with optional HTTPS, and the MCP transport is Streamable HTTP at the path /mcp. The README states the transport is MCP-specification compliant, JSON-only, with no SSE. That last detail matters for client compatibility: any MCP client that assumes a server-sent events channel will not work here.
Screen interaction goes through Android's accessibility services plus screenshot capture. That is the same substrate screen readers use, which is why the tool surface spans screen introspection, touch actions, gestures, node actions and text input. Around that core sit file operations, app management, camera, intents, notifications, location and sharing, which is how the count reaches 57 tools across 14 categories.
Tool naming is configurable. By default every tool carries an android_ prefix, so tapping is android_tap. Configure a device slug such as pixel7 and the prefix becomes android_pixel7_, giving android_pixel7_tap. That mechanism is what makes multi-device setups addressable from a single client: the slug is baked into the tool name rather than passed as a parameter.
On the server side, the app supports two authentication modes, a static bearer token, a self-contained OAuth 2.1 server aimed at Claude.ai and Claude Desktop custom connectors with on-device approval, or both together. TLS certificates are either auto-generated self-signed or uploaded by the user. Binding is a choice between 127.0.0.1 and 0.0.0.0, and the server can auto-start on boot.
Getting it onto a device
Releases ship two APK flavours. The GMS build (the filename pattern is …-gms-release.apk) requires Google Mobile Services, meaning Google Play Services must be installed. The README also names a FOSS flavour for devices without GMS. Pick based on whether the target device has Play Services; a de-Googled phone or a bare emulator image will need the FOSS build.
Once installed, the app presents a Material Design 3 interface with three tabs: Server, Settings, About. The Server tab shows running or stopped status and a permission warning banner, plus connection details including IP, port, token and tunnel URL. Settings covers per-tool and per-parameter permissions, permission management for Accessibility, Notifications, Camera and Microphone, tunnel configuration, storage locations, and a log viewer for MCP tool calls and tunnel events.
The README also documents a headless path via ADB for configuring the server, granting permissions, and starting or stopping it without touching the UI. That is worth noting for what it implies: the project's own tooling treats ADB as a setup convenience even though the runtime deliberately avoids it.
For remote access, two tunnel options are automated: Cloudflare Quick Tunnels and ngrok. Both produce a public HTTPS URL, which the README presents as the reason the project can be driven from anywhere rather than only from the same LAN. File tools need a storage location, configured either from the app's automatic locations or through Android's Storage Access Framework authorisation.
The token argument, and where it is thinner than it sounds
The token-efficiency claim rests on three mechanisms. The first is the compact screen representation instead of a raw XML dump. The second is numbered screenshot annotations, so the model can refer to a control by index rather than by coordinates it has to infer. The third is per-tool enable and disable, which the README justifies with the observation that every tool definition costs tokens on every turn. That third point is the one most teams skip and the one with the clearest payoff: if you are only driving the camera and files, shipping 57 tool schemas into every request is waste.
What the README does not do is quantify the compact representation. It gives a 10 to 50 times range for ADB XML verbosity, which is a comparison against other tools, not a measurement of this one. Screenshot resolution and quality are configurable, but no default values or size figures appear in the material available here. Treat the efficiency claim as directionally supported by the design rather than numerically established. The honest version is that fewer bytes per screen read is structurally better for an agent loop, and how much better depends on the app being driven and the screenshot settings you choose.
Tunnels, permissions and the blast radius
The feature list is the risk list. Accessibility services, camera, microphone, notifications, file access through SAF, plus a tunnel that publishes the endpoint to the public internet. The README's security section exists, and the app offers bearer tokens and OAuth 2.1 with on-device approval, but authentication is only the front door. The tools behind it can install apps and post to social accounts, which the demo clips show: a Reddit post, a booking.com install, a Skyscanner flight search. Those demos are the clearest statement of what the tool does when pointed at a real account.
There is a second, quieter failure mode. Accessibility-driven automation depends on what the target app exposes to the accessibility tree. Apps that render into a canvas, use custom drawing, or deliberately mark nodes as not important for accessibility will give the model a thin or misleading view. The screenshot path is the fallback, but a screenshot plus numbered annotations still requires the model to reason about pixels rather than read a labelled node. Expect uneven reliability across apps, and expect the failure to look like a wrong tap rather than an error message.
The wrong-tool case is straightforward. If the phone under control is your daily driver, with your banking app and your primary email signed in, this project hands a remote LLM a very direct path to those accounts. The README's research-and-education framing is the correct reading. A spare handset or a dedicated emulator is the sane deployment.
Compared with ADB-based MCP servers
The README names five alternatives in its comparison table: mobile-mcp, Android-MCP, android-mcp-server, adb-mcp and droidrun-mcp. The difference that matters is architectural, not a feature-count gap. Those projects drive the device from a host machine over ADB, which means a USB cable or a local network path and a computer sitting next to the phone. This project removes the host entirely. That is why it can be tunnelled and reached over the internet while the ADB-based tools cannot, and why the latency and verbosity numbers in the table diverge.
There is a counter-argument the table does not make. ADB is a stable, well-documented interface with a long history of tooling. An accessibility-service app is subject to Android's permission model, OEM customisations, and background-execution limits that vary by manufacturer. The ADB route is more awkward to set up and slower per action, but it is less likely to be killed by an aggressive battery manager on a Xiaomi or Huawei device. The material here does not describe battery-optimisation handling, so that concern is unresolved rather than dismissed.
Among the listed alternatives, mobile-mcp is the only one the table credits with iOS support, which this project does not have. If your automation needs to span both platforms, that single row decides the choice.
Maintenance, licensing and what to check first
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the licence text, not legal advice; if you are shipping this inside a product, have counsel read the actual LICENSE file rather than this summary. The README's own warning about research and educational use sits alongside the MIT grant and does not restrict the licence, but it does signal the author's intent about deployment context.
The repository is not archived and was pushed as recently as 2026-08-26. Releases include a rolling edge tag plus numbered versions, with v1.12.0 tagged on 2026-08-19 and v1.11.1 on 2026-08-14. The edge channel existing at all tells you the project ships continuously and that pinning to a numbered release is the safer choice for anything you depend on. Upgrade cost is the ordinary Android one: sideload the new APK, re-check permissions, and re-verify tunnel configuration, since a tunnel URL that changes on restart will break any client config pointing at the old one.
Before committing, check three things. Confirm the permission list the app requests against what the Android settings screen actually shows after install. Confirm the tunnel URL resolves and that your chosen auth mode (bearer, OAuth, or both) rejects an unauthenticated request. And confirm that disabling a tool in the Settings tab removes it from the tool list the client sees, not just from the set of calls the server will accept, because only the former saves the tokens the README's efficiency argument depends on.
Editorial conclusion
Adopt it if your target is a spare or emulated Android device, you want the MCP endpoint reachable from outside the LAN, and you are willing to work through the Accessibility, Camera and file permissions the tools need. Do not adopt it if you need iOS coverage, if your workflow already standardises on ADB from a host machine, or if the device under control holds accounts you cannot afford to expose. Before trusting it, verify three things: that the APK's claimed permissions match what you see in the Android settings screen, that the tunnel URL is reachable and authenticated the way you configured it, and that the per-tool switches actually remove the tools you do not want from the model's tool list rather than merely rejecting the calls.
Community notes