Mobile MCP is a Model Context Protocol server that gives an AI agent control of native iOS and Android applications, running against simulators, emulators and real hardware. It is built for mobile developers and QA engineers who would rather have an agent install an app, walk its screens and read data back than maintain two separate automation suites, and for anyone assembling agent workflows that need to touch a phone. The project comes from Mobile Next, is written in TypeScript under the Apache-2.0 license, and has gathered roughly 7,300 stars since it was created in March 2025. It was still receiving pushes in September 2026.
What it does
The problem it addresses is the split between platforms. Automating iOS normally means XCUITest; automating Android normally means Espresso. That is two codebases and two skill sets, just to tap one button. Mobile MCP puts a single platform-agnostic interface in front of both, so the agent issues the same instructions whether the target is an iPhone simulator, an Android emulator or a physical device.
In practice the server exposes a toolset that lets an agent:
- install an application onto a device and launch it
- tap and move through the app's screens
- read what is currently displayed
- pull data out of the interface, which is the "scraping" half of the project's description
None of that requires platform-specific code on your side. The agent is the test script.
How it works
The distinguishing choice is how the server tells the model what is on screen. Rather than handing over a screenshot and asking a vision model to guess at pixels, Mobile MCP builds a structured accessibility snapshot: the elements the operating system already exposes for screen readers, with their identities intact. The agent targets a named element instead of a coordinate, which is both cheaper in tokens and less brittle when layout shifts. Where that tree is not usable, the server falls back to coordinate-based taps derived from screenshots, so the two approaches sit side by side rather than one replacing the other.
Everything is delivered over MCP, which is what makes the client list open-ended. The README names Claude Code, Codex, Gemini, GitHub Copilot and Antigravity, and adds that any MCP-compatible client will do. The server itself is a TypeScript package published to npm as @mobilenext/mobile-mcp.
Getting started
Installation is an MCP client configuration entry rather than a build. Point the client at npx -y @mobilenext/mobile-mcp@latest and the server fetches and runs on demand; VS Code users get a one-click install link from the README badge. Project documentation lives in the repository wiki, and the README is also maintained in Japanese and Simplified Chinese translations.
Locally you still need a device to drive, which means the usual simulator or emulator tooling for whichever platform you are targeting, or a phone plugged in. If you do not have one to hand, the maintainers run Mobile Next Cloud, a hosted option offering the same tools against real iOS and Android devices with no local setup. That is a commercial service from the same team, and worth reading as such when you weigh the project.
When to use it / when not
This fits best when the work is exploratory or one-off: poking at a build to see whether a flow works, reproducing a bug report, extracting data from an app that has no public API, or letting a coding agent verify its own change end to end on a device instead of reporting that it compiled. It is also a reasonable answer when you support both platforms and cannot justify two maintained automation suites for a handful of smoke paths.
It is a weaker fit as the backbone of a regression suite. An agent driving a phone is slower than a compiled test and not deterministic in the way CI wants; a flake there costs you more than it saves. The accessibility-tree approach also inherits your app's labelling, so a screen built without accessibility identifiers gives the model less to work with and pushes it back onto coordinates. And it does not touch the layer below the interface at all, so unit and integration tests keep their jobs.
Alternatives
The honest comparison is the pair the project positions itself against. XCUITest and Espresso are still the tools to reach for when you want a fast, repeatable, per-platform regression suite that fails loudly in CI, and Mobile MCP does not replace them. What it replaces is the cost of writing platform-specific automation for tasks that only need doing once, or that a human would otherwise do by hand.
Mobile developers and QA engineers already working with a coding agent should take this seriously: it closes the gap between an agent that can edit mobile code and one that can actually run the app it just changed, and it does so without asking either platform's automation framework to be learned first. Teams with a mature, deterministic test suite should treat it as a complement for exploratory and data-extraction work rather than something to migrate onto. The cloud service is the maintainers' business model, but the server is Apache-2.0 and runs perfectly well against a simulator on your own machine.