Work that used to need a person holding a device — walking an app through a flow, comparing what two shopping apps show, checking that today's build still installs and launches — becomes something an agent can run against a real Android, cloud or physical. Note the current boundary: the MCP server controls Android environments only, while the Linux desktop and browser environments are reached through the CLI and SDK.
Sandboxed Android environments that an agent drives the way a person would: tap, swipe, type, press the hardware keys, take a screenshot and look at what happened. The device can be a cloud virtual one, a cloud physical phone, or an Android handset of your own registered through the CLI. Alongside the touch layer it has the developer's route in as well — APKs installed and removed, apps opened and closed, `adb shell` commands run and logcat read back.
- An Android environment started on demand — cloud virtual device, cloud physical phone, or your own registered handset
- Input as a person performs it: tap, long press, swipe, drag, scroll, and text typed into the focused field
- Hardware and soft keys pressed by name, and arbitrary key events sent
- A screenshot taken after an action, so the agent sees the state it just produced
- Apps opened and closed by package, and APKs installed or uninstalled
- `adb shell` commands run against the device, and logcat read back for what the app reported
- A wait call, for the screens that need a moment before the next step
A gbox.ai account — MCP access requires you to be logged in. The CLI installs from Homebrew on macOS or npm elsewhere, and `gbox mcp export --merge-to claude-code` writes the client entry for you. Connecting a phone of your own needs Developer Mode enabled on the handset; ADB, frpc and Appium are fetched by `gbox setup` when they are not already present.
One command plus a key — npx -y @gbox.ai/mcp-server@latest, then supply credentials