Android Mobile MCP Server
# Android Mobile MCP Server
Minimal Android-only fork of the original `mobile-mcp` project by MobileNext.
This project keeps only the Android functionality and exposes it through a Streamable HTTP MCP server protected by a shared bearer token.
## License and attribution
This project is derived from the original `mobile-mcp` project and is licensed under the Apache License 2.0.
Keep the Apache License file in this repository and preserve the original copyright notices. This repository is a modified Android-focused fork and is not the official upstream project.
## Requirements
- Node.js 20+
- Android SDK Platform Tools
- `adb` on your `PATH`
- one running Android emulator or one connected Android device
- a shared secret in `.env` via `MOBILEMCP_AUTH`
Check connectivity:
```bash
adb devices
```
## Setup environment
Create a `.env` file in the project root:
```env
MOBILEMCP_AUTH=your_shared_secret_here
```
You can use the example file:
```bash
cp .env.example .env
```
## Install and run
```bash
npm install
npm run build
node lib/index.js --listen 0.0.0.0:3000
```
Server URL:
```text
http://localhost:3000/mcp
```
The server requires a bearer token for every HTTP request.
## Auth header
```http
Authorization: Bearer your_shared_secret_here
```
## MCP config
```json
{
"mcpServers": {
"mobile-mcp": {
"type": "http",
"url": "http://localhost:3000/mcp",
"headers": {
"Authorization": "Bearer your_shared_secret_here"
}
}
}
}
```
## Example device-targeted tool call
```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "mobile_list_apps",
"arguments": {
"device": "emulator-5554"
}
}
}
```
Use the device ID from:
```bash
adb devices
```
## Docker
On Linux, expose the host ADB daemon on TCP port `5037` before starting the container:
```bash
adb kill-server
adb -a start-server
adb devices
```
The `-a` flag is required for Docker clients. Without it, ADB listens only on the host's local Unix socket and container commands fail with `Connection refused`.
The container must be told how to reach the host adb server. `host.docker.internal` is only available on Docker Desktop or when explicitly mapped for Linux.
### Docker Desktop / macOS / Windows
``` bash
docker build -t mobile-mcp-android .
```
### Linux with host networking
```bash
docker run -d \
--network host \
-e MOBILEMCP_AUTH=your_shared_secret_here \
-e ADB_SERVER_SOCKET=tcp:127.0.0.1:5037 \
--name mobile-mcp-android \
mobile-mcp-android
```
If port 3000 is already in use, change the host port mapping to another port, for example `3000:3000` as above.
Then access the server at:
```text
http://localhost:3000/mcp
```
If you are debugging inside the container, the adb server should then resolve correctly:
```bash
docker exec -it mobile-mcp-android sh
adb devices
```
## Notes
- Android-only build
- iOS support removed
- intended for local Android automation and emulator/device control
- anyone without the correct `MOBILEMCP_AUTH` secret cannot connect
## License
This project is distributed under the Apache License 2.0.
See the included `LICENSE` file for the full text.
TDQS
Scored across 27 tools
Most tools map to clearly distinct actions and objects, and the descriptions generally resolve potential confusion. However, mobile_take_screenshot and mobile_save_screenshot have overlapping purposes, and mobile_press_button vs. mobile_click_on_screen_at_coordinates could be misread without careful attention.
All tools share a consistent mobile_ prefix and mostly follow a verb_noun pattern, making the set predictable. Minor deviations exist with longer prepositional names like mobile_click_on_screen_at_coordinates and mobile_long_press_on_screen_at_coordinates, but they do not break readability.
27 tools is on the heavy side for a typical MCP server, but the broad mobile automation scope—UI interaction, app lifecycle, screenshots/recording, crash reporting, and remote device management—largely justifies the count. Still, the surface feels larger than ideal and could be tightened.
The server covers the core mobile automation lifecycle well: app install/uninstall/launch/terminate, screen interaction, navigation, screenshots, recording, and crash retrieval. Notable gaps include file push/pull, device health/battery info, and an explicit wait-for-element/condition tool, but these are workable around.