Android Remote Control MCP: an MCP server that runs on the phone itself

The problem: MCP control of Android without a computer in the loop

Most MCP servers that drive a phone sit on a host machine and talk to the device through ADB. That design carries a physical constraint. The README states plainly that these alternatives require a USB cable or a local network connection and a computer sitting next to the phone. If you want an agent to operate a device that is somewhere else, in a test lab, in another room, or simply not plugged into anything, the ADB model stops working.

This project inverts the topology. The Android application is the MCP server. It runs on the device, opens an HTTP server (optionally HTTPS) implementing the Model Context Protocol, and lets a model such as Claude connect and interact with any app by reading UI elements, tapping, typing, swiping, capturing screenshots, managing files and launching apps. Because the endpoint lives on the phone, it can be published through a tunnel and reached from anywhere, which is the capability the comparison table marks as absent in the ADB-based projects it lists.

The intended audience is narrow and technical: people building or evaluating agentic loops against real mobile UIs, and researchers who need a device they can reach remotely. The README frames it as software for research and educational purposes only, provided as-is, with users responsible for lawful use.

How the on-device MCP server is put together

The transport is Ktor plus Netty, running inside the Android app. The MCP endpoint is served at /mcp using streamable HTTP, and the README notes it is JSON-only with no SSE. That choice matters for clients: anything expecting an event stream from the server will not get one here.

Authentication is combined rather than exclusive. You can use a static bearer token, or a self-contained OAuth 2.1 server intended for Claude.ai and Claude Desktop custom connectors, with approval happening on the device. TLS is handled by auto-generated self-signed certificates, or you can upload a custom certificate. Binding is configurable between localhost (127.0.0.1) and network (0.0.0.0), and the server can auto-start on boot.

Control itself comes from Android accessibility services plus screenshot capture. That is the mechanism behind the introspection and action tools. The tool surface is 57 tools across 14 categories: screen introspection, system actions, touch actions, gestures, node actions, text input, utilities, file operations, app management, camera, intents, notifications, location and sharing. Names carry an android_ prefix by default, so you call android_tap. Configure a device slug such as pixel7 and the prefix becomes android_pixel7_tap, which is how multi-device setups avoid collisions. The full schemas live in docs/MCP_TOOLS.md rather than in the README.

The token argument is the project's own, and it is a design argument rather than a measured one. The README says ADB-based tools typically return raw uiautomator XML dumps that can be 10 to 50 times more verbose than the compact representation used here, and points to numbered screenshot annotations, configurable image quality and per-tool disabling as the levers. The per-tool point is the sharpest: every enabled tool definition costs tokens on every turn, so a server that ships 57 tools also ships a reason to turn most of them off.

Installing the APK and getting a first tool call through

Distribution is by APK, not by an app store. Each release provides two flavors, and the README tells you to pick the one matching your device: the GMS build, named with a -gms-release.apk suffix, requires Google Mobile Services, while the FOSS flavor is the alternative for devices without Play Services. Install the APK on the phone or emulator you intend to control.

The repository also ships a Makefile with explicit device targets, which is the fastest path if you are building from source. The variables at the top define the app id and the default port:

APP_ID := com.danielealbano.androidremotecontrolmcp
DEFAULT_PORT := 8080

The install and permission targets are named directly in the Makefile, so a source build followed by a device install looks like this:

make install
make grant-permissions
make start-server
make forward-port

Each target does what its name says: install the app, grant the permissions the server needs, start the server, and forward the port. After start-server, the app UI shows a server status of running or stopped, along with connection info (IP, port, token, tunnel URL) and a permission warning banner if something is missing. Accessibility is the permission that matters most; without it the introspection and action tools have nothing to work with.

Point your MCP client at the /mcp path on the port you forwarded, using the bearer token shown in the connection info. For a headless machine there is ADB setup without the UI: the README lists configuring, granting permissions and starting or stopping the server over ADB as supported. Integration tests read their secrets from a gitignored .env copied from .env.example, which is where NGROK_AUTHTOKEN goes if you enable that tunnel.

Where it breaks: permissions, tunnels and the wrong use case

The first failure mode is the permission model itself. Accessibility services are the mechanism, and Android treats them as a high-trust grant. If the service is not enabled, or the OS revokes it, the tool surface degrades to whatever does not depend on it. The app surfaces this as a permission warning banner, but the failure arrives at the agent as tools that cannot see or act, not as a clean error about the root cause.

The second is exposure. Remote access tunnels via Cloudflare Quick Tunnels or ngrok produce a public HTTPS URL. That is the feature that makes the project different, and it is also the feature that turns a phone into an internet-reachable endpoint with an authentication layer in front of it. The README documents a static bearer token and an OAuth 2.1 flow with on-device approval, and it documents binding to 127.0.0.1 or 0.0.0.0. It does not document rollback, and it does not document rate limiting or lockout behaviour for failed authentication attempts. Treat the tunnel as the boundary you have to reason about yourself.

The third is scope. This is the wrong tool when you need deterministic, repeatable UI automation in CI. Accessibility-driven control follows the rendered UI, so it inherits the flakiness of the app under test. It is also the wrong tool if you cannot accept the research-only framing: the README's warning is not decorative, and the licence disclaims warranty. And it is wrong for iOS, which the comparison table marks as unsupported.

How it differs from ADB-based MCP servers

The comparison table names the alternatives directly: mobile-mcp, Android-MCP, android-mcp-server, adb-mcp and droidrun-mcp-server. The distinction is architectural, not a feature checklist. Those projects drive the device from a host over ADB. This one is the device.

That single difference cascades. Running on the phone is what makes internet access possible, because there is no host to tunnel into. It is also what makes latency different: the README lists 10 to 100 ms for this project against 1 to 4 s for the ADB-based tools, presumably because a round trip through ADB and uiautomator is avoided. And it is what makes the token argument available at all, since the compact representation is produced on-device rather than parsed out of an XML dump on the host.

The trade is that you lose the host. ADB gives you a debugging channel that works even when the UI is broken, and it gives you a machine to run the agent on. Here the agent is remote and the device must be healthy enough to run an HTTP server. The table also shows the alternatives spread across tool counts from 5 to 21, with mobile-mcp the only one besides this project claiming multi-device support and the only one claiming iOS. If you need both platforms from one setup, this project is not that.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-26. Recent releases are v1.12.0 on 2026-08-19, v1.11.1 on 2026-08-14, and a rolling edge release on 2026-08-15. The presence of an edge channel alongside versioned tags means there are two upgrade tracks, and the edge one is by definition not the stable line.

The licence is MIT, which is permissive and places few obligations on reuse. It does not change the README's own warning that the software is provided as-is without warranty and is intended for research and educational purposes. A permissive licence on a tool that grants accessibility-level control of a device is not a statement about fitness for production. That is a judgement for you and, if the deployment touches regulated data or other people's accounts, for whoever advises you on it.

Upgrade cost is concentrated in two places. The APK flavor matters: a device without Google Play Services needs the FOSS build, so an upgrade path that assumes the GMS artifact will fail there. And the tool surface is the API. With 57 tools and per-tool, per-parameter permissions configured in the app, a version bump can change what your client sees and what your permission settings still mean. The repository has a version-bump target set in the Makefile (version-bump-patch, version-bump-minor, version-bump-major), which tells you the maintainer tracks this deliberately, but it does not tell you what changed between v1.11.1 and v1.12.0. Read the release notes before upgrading a device you depend on.

Editorial conclusion

Adopt it if you need MCP-driven control of a real Android device that no computer is attached to, and you accept the accessibility-service permissions it requires. Do not adopt it for production automation, for anything touching other people's accounts, or on a phone holding data you cannot lose: the README itself labels it research and educational software provided as-is. Verify first that the Accessibility service grants correctly on your Android version, that the bearer token or OAuth approval is actually enforced on the network binding you chose, and what the Cloudflare Quick Tunnel or ngrok exposure publishes to the internet before you enable it.

Frequently asked questions

Official sources

1. danielealbano/android-remote-control-mcp on GitHub
2. Issues
3. License: MIT
4. README
5. Releases