DEV Community: Alon N

How an AI agent can use Android apps that have no API (five routes in 2026)

Alon N — Sun, 18 Oct 2026 16:53:42 +0000

Disclosure: I work on Phonebox, which is the fifth option below. The other four are Google's or open source, and I've tried to be straight about what each can and can't do.

A lot of the apps people want an agent to use have no API: food delivery, rides, banking, most of what's on your phone. So how does an AI agent actually get work done in them? In October 2026 there are five routes, and which one works depends on who you are and which app it is.

Five ways, best first

	Works when	Who can use it
1. The app's API or MCP server	The app publishes one	Anyone with access
2. Android AppFunctions	The app adopted it; Android 16+; experimental	System agents such as Gemini; Gemini support in private preview
3. Gemini doing it for you	Select food, grocery and ride apps; Pixel 10, Galaxy S26; US and Korea	The phone's owner, who taps the final order button
4. An agent framework on your own phone	You connect a phone or emulator over ADB	Developers; Play bans autonomous agents built on accessibility
5. An agent on its own cloud phone	Any app a person can use	Any agent over MCP, CLI or API

AppFunctions is the clean future: apps annotate functions with @AppFunction, and agents call them directly, on the device. Google calls it "the mobile equivalent of tools within the Model Context Protocol". But it's experimental, needs Android 16, and only works for apps that adopted it, called by a limited set of system agents.

Gemini's in-app tasks (beta since February 2026) can run multi-step tasks in DoorDash, Uber, Lyft, Instacart and a few others, in a virtual window on the phone. It stops before the buy button and asks you to tap it.

Accessibility-based agents like Mobilerun, mobile-use and AppAgent run an observe-act loop on a phone you connect over ADB. Great for experiments. Note that Google Play's policy prohibits shipping an app that uses AccessibilityService to autonomously plan and execute actions.

How an agent uses the screen

Whatever runs the phone, the loop is the same:

Observe. Read the screen as a list of elements with their labels (plus a screenshot).
Act. Tap by visible text, type, swipe.
Check. Read the new screen and confirm the result before the next step.

Reading text rather than pixels is what makes it hold up: "tap Sign in" still works after a redesign moves the button. This is what an agent reads on a Phonebox phone:

snapshot snp_4f2k7m3q6z3a
app com.android.launcher3
keyboard hidden
screen 1080x2400
[1] EditText "Search apps" #search clickable editable (540,250)
[2] TextView "Chrome" #icon clickable (200,1900)

Where the common tasks draw the line

Food and rides. Let the agent build the order, then confirm and pay yourself. Gemini works the same way: it stops before the buy button.
WhatsApp. Messaging customers belongs on the WhatsApp Business Platform: opt-in, templates outside the 24-hour window, and a limit that starts at 250 people a day. WhatsApp's Terms prohibit "bulk messaging, auto-messaging, auto-dialing, and the like" from regular and Business app accounts, and it bans accounts for it. An agent doing a few user-directed things in your own account isn't explicitly addressed; treat that as a grey area, never as a way to send in bulk.
Accounts. Sign in only to accounts you own or may use. When an app wants a one-time code, a person should enter it.

The fifth route

That's the gap Phonebox fills: a cloud Android phone the agent drives over MCP, CLI or API, which keeps its apps and sign-ins between sessions, with nothing attached to your machine. When a step needs a person, such as a code or a payment, the agent sends a live view link and waits.

Originally published on phonebox.dev. If you've found another route that works for apps with no API, I'd like to hear it.

What is agentic testing? A practical definition for mobile app teams

Alon N — Sun, 18 Oct 2026 16:52:54 +0000

Disclosure: I work on Phonebox, which gives AI agents cloud Android phones. This post is about the testing approach, not the product; the last section shows one way to try it.

"Agentic testing" is on every testing vendor's homepage this year, and the definitions don't quite agree. Here's a practical one, from a mobile point of view.

The definition

Agentic testing means an AI agent runs the test: you state a goal in plain language, and the agent decides each next action from what it observes on screen, acts, checks the result and adapts until the goal passes or fails.

That separates it from two things it often gets confused with:

Scripted testing: the steps are fixed in advance, in Espresso, UI Automator, Appium or Maestro.
AI-assisted testing: AI writes or repairs a script (Copilot writing Espresso, self-healing locators), and the script then runs as usual.

Tricentis, Momentic, Katalon and Autify all draw the line roughly here. Forrester calls the category "autonomous testing platforms" and doesn't use the word "agentic" at all.

Three ways to automate a UI test

	Scripted	AI-assisted	Agentic
Who decides the steps	The engineer, in code	AI writes the code; it runs like any script	The agent, at run time
When the UI changes	The test breaks	AI repairs the locator	The agent finds another way
Repeatability	Exact	Exact	Different paths to the same goal
Mobile examples	Espresso, UI Automator, Appium, Maestro	Copilot writing Espresso, self-healing locators	Claude Code on a cloud phone, Journeys in Android Studio

Where it falls short

Non-determinism: two runs can take different paths, so a failure can't always be replayed step for step.
Cost and speed: every step is a model call, so it's slower and dearer than a script.
Gestures: Google lists long-press, double tap, multi-finger gestures and rotation among the gaps in its own Journeys preview.
Judgment: the agent only knows the business rules you write down.

So it isn't a replacement for the suite that gates your merges. It's good at the things scripts are bad at: new screens, exploratory passes and reproducing bug reports.

Trying it on an Android app

The agent needs a device it can read and act on. On a laptop that's an emulator plus a local MCP server like mobile-mcp. If the agent runs somewhere without an emulator, a hosted one works:

claude mcp add --transport http phonebox https://phonebox.dev/mcp \
  --header "Authorization: Bearer $PHONEBOX_API_KEY"

Then give it a goal, not steps:

Install the debug APK on my Phonebox phone and open it.
Sign in with the test account from TEST_ACCOUNTS.md, open each tab
in the bottom bar once, then sign out. Read the screen before every
action. Report any crash, error message or empty screen, quoting the
screen text. Park the phone when you finish.

The two habits that matter most: tell it to read the screen before every action, and ask for evidence (the exact screen text, or a recording) so the report can be checked.

Originally published on phonebox.dev. Curious how others are drawing the line between agent runs and scripted suites.

The best Android MCP servers in 2026: twelve compared, local and hosted

Alon N — Sun, 18 Oct 2026 16:52:04 +0000

Disclosure: I work on Phonebox, one of the twelve servers below. Most of the others are free and open source, and I've tried to be fair about when each is the better pick.

If you want an AI agent (Claude Code, Codex, Cursor, your own) to see and control an Android device, you need an MCP server for it. There are a lot of them now, and the lists that rank for "android mcp server" are mostly directory pages with stale star counts. So here is a comparison of twelve, with GitHub numbers checked on October 16, 2026.

All twelve at a glance

Server	Stars	Runs	Phone included	iOS	Agent reads the screen as
mobile-mcp	9,669	Local (stdio or HTTP)	No; optional paid cloud	Yes	Accessibility tree, screenshot fallback
Appium MCP	498	Local, or your Appium grid	No	Yes	Page source XML and locators
Maestro MCP	16,088 (Maestro)	Local, in the Maestro CLI	Maestro Cloud for runs	Simulators	View hierarchy JSON and screenshot
agent-device (Callstack)	5,051	Local CLI and MCP	No; device-cloud proxy	Yes	Accessibility snapshot with refs
Patrol MCP	1,447 (Patrol)	Local, Flutter projects	No	Yes	Native UI tree and screenshot
Android-MCP (CursorTouch)	895	Local (uvx, Python 3.13)	No	No	Interactive elements, optional screenshot
android-mcp-server (minhalvp)	811	Local (Python, adb)	No	No	Clickable-element text and screenshot; no commits since May 2025
android-remote-control-mcp	718	An app on the phone itself	Your own phone	No	Compact accessibility tree and screenshot
Mobilerun MCP	New (Mobilerun: 9,675)	Mobilerun Cloud	Yes, Mobilerun Cloud phones	Yes	Accessibility tree via the Portal app
BrowserStack MCP	155	Local or hosted (OAuth)	Yes, real devices	Yes	Session screenshots; sessions and test runs, not step control
Sauce Labs MCP	Hosted	Hosted (username and key)	Private devices, paid add-on	Yes	UI source and screenshot
Phonebox	Hosted	Hosted (API key)	Yes, cloud Android phones	No	Numbered text list of elements and screenshot

Which one to use

The default, on your own machine: mobile-mcp. Free, active, Android and iOS, with logs, screen recording and location built in.
Your team already runs Appium: Appium MCP, which can also generate Appium test code from what the agent did.
Your tests are Maestro flows: Maestro MCP, built into the CLI you already have.
React Native or Expo: agent-device, with replayable sessions and Maestro export.
Flutter: Patrol MCP, to write and run Patrol tests.
The agent runs in CI, a cloud sandbox or a teammate's laptop: a hosted server. Phonebox needs only an API key and keeps the phone signed in between sessions; Mobilerun Cloud and the device-farm servers need their platform accounts.
Driving your own personal phone remotely: android-remote-control-mcp, which runs on the phone.

Local or hosted: the real difference

Every local server needs an emulator or a USB phone that adb can see, on the same machine as the agent. That's free and fast on a workstation, and impossible on most CI runners and cloud sandboxes. A hosted server moves the phone to the cloud: the agent needs a URL and a key, and any machine can use the same phone.

# Local servers: they drive an emulator or USB device on this machine
claude mcp add appium-mcp -- npx -y appium-mcp@latest
claude mcp add mobile-mcp -- npx -y @mobilenext/mobile-mcp@latest
claude mcp add maestro -- maestro mcp

# Hosted: the phone comes with it
claude mcp add --transport http phonebox https://phonebox.dev/mcp \
  --header "Authorization: Bearer $PHONEBOX_API_KEY"

Not device control

Two names that show up in searches do something else. Google's Android Management API MCP manages enterprise device policies, not the screen. mikechambers/adb-mcp controls Adobe apps, not Android.

The full comparison, kept up to date, is on phonebox.dev. If I missed a server you use, tell me in the comments and I'll check it.

How to give Claude Code an Android phone: ADB, an emulator, or a cloud phone

Alon N — Sun, 11 Oct 2026 12:25:20 +0000

Disclosure: I work on Phonebox, one of the options below. The other three are free, and I've tried to be fair about when each is the better fit.

You can give Claude Code an Android phone four ways: a USB phone it drives with ADB, the same phone mirrored with scrcpy, a local emulator, or a cloud phone through a hosted MCP server. ADB is free if the phone is on your desk. A cloud phone is one command, works from any machine, and gives Claude Code the screen as text, so it taps by label instead of by coordinates.

The four options

	Needs	Claude Code sees	Works in CI / sandboxes	Cost
USB phone + ADB	A phone, a cable, USB debugging, platform-tools	Screenshots and UI dumps it parses itself	No	Free
ADB + scrcpy	The same, plus scrcpy	The same; scrcpy is for you to watch	No	Free
Local emulator	Android Studio, a system image, hardware acceleration	Screenshots and UI dumps through adb	Rarely (needs nested virtualization)	Free; uses your RAM and CPU
Cloud phone over MCP	One command and an API key	A numbered list of on-screen elements, plus a screenshot	Yes	Paid per minute

Option 1: a USB phone and ADB

Turn on developer options. Settings > About phone, tap Build number seven times, then turn on USB debugging.
Install platform-tools, plug the phone in, accept the prompt, and check that adb devices lists it.
Tell Claude Code to use adb. It can run adb install, adb shell input tap x y, adb shell input text and adb exec-out screencap -p in its terminal.

It works, and it's free. The limits show up quickly: Claude Code has to work out tap coordinates from screenshots, the phone has to stay plugged into the machine Claude Code runs on, and a dropped connection or a locked screen stops the run. ADB-based MCP servers wrap the same commands in tools, with the same requirement of a device next to the agent.

Option 2: add scrcpy to watch

scrcpy mirrors the phone to a window on your desktop and lets you control it with your mouse. It doesn't give Claude Code anything new, since the agent still acts through adb, but it's useful for watching the agent and stepping in.

Option 3: a local emulator

An emulator from Android Studio avoids the cable and can be reset. It needs gigabytes of SDK and system images and hardware acceleration, and it competes with your IDE for memory. Most CI runners and cloud sandboxes can't run it, because they don't offer nested virtualization.

Option 4: a cloud phone through MCP

A hosted Android MCP server runs the phone in the cloud. With Phonebox it's one command:

claude mcp add --transport http phonebox https://phonebox.dev/mcp \
  --header "Authorization: Bearer $PHONEBOX_API_KEY"

Claude Code then gets 13 tools: observe returns the screen as numbered elements with their labels, act taps and types by label, install_app installs the APK it just built, live_view_url hands the phone to you for a one-time code, and park_phone stops billing while keeping the apps and sign-ins. This is what the agent reads:

snapshot snp_4f2k7m3q6z3a
app com.android.launcher3
keyboard hidden
screen 1080x2400
[1] EditText "Search apps" #search clickable editable (540,250)
[2] TextView "Chrome" #icon clickable (200,1900)
[3] TextView "Settings" #icon clickable (500,1900)

It costs $0.06 per phone-minute while running and nothing while parked. There's a 56-second demo and a 3-minute setup video.

Which to choose

USB and ADB if a spare phone sits on your desk and Claude Code runs on that machine.
A local emulator for repeatable tests on a workstation that can run one well.
A cloud phone when Claude Code runs remotely, in CI or in a sandbox, when the phone has to stay signed in between sessions, or when you'd rather not set anything up.

The full comparison, kept up to date, is at phonebox.dev/guides/how-to-give-claude-code-an-android-phone.

Give Claude Code business context through MCP

Alon N — Wed, 09 Sep 2026 17:03:18 +0000

Claude Code can do more with company context than another spreadsheet export. Connect it to the business records it needs, give it a clear question, and let it query those records through MCP.

We build Combined, a managed data layer for this workflow. Combined connects to business applications, keeps selected data synced, and exposes scoped, read-only access to compatible agents. Here is the setup path for Claude Code.

Prepare one useful dataset

Start with one source and a question you already care about: open pipeline by stage, for example. In Combined, choose a Ready connector, complete authorization, select the relevant datasets and fields, and run the first sync. Check the records in Explore.

Give the agent access to those datasets through the onboarding or Access workflow. The scope should match the question. You can expand it when a later question needs another dataset.

Connect Claude Code

Use the account-specific instructions supplied by Combined. Replace ACCOUNT_UUID below with your account ID, then add the HTTP server in Claude Code:

claude mcp add --transport http combined-context \
  "https://platform.trycombined.com/mcp?account_id=ACCOUNT_UUID"

Open /mcp in Claude Code and follow authentication. The account ID selects the account; authentication provides access. Keep credentials in the supported setup flow.

Ask the agent to discover the data

Business systems differ, so let the agent inspect the available source, logical dataset, and field names before writing SQL. A useful first instruction is:

Use the combined-context MCP server.
List my permitted sources and use the one I select.
List its datasets and describe the dataset needed for my question.
Check freshness, then run a read-only query returning at most five rows.
Report the source, freshness, query receipt ID, and any truncation.

Once that works, ask a precise business question. For pipeline, specify the pipeline, time boundary, stages, and currency treatment. Have the agent aggregate the relevant records rather than infer a total from a small row sample.

Make the answer useful

The best answer gives you the result and enough context to act on it: which source it used, when that data last synced, and any missing coverage. If a record just changed in the source, sync the change before expecting it in the result.

Start with one question you would otherwise answer manually. Connect its source once, then keep the question inside your existing agent workflow.

Combined includes an initial 5 million MAR without a card. Follow the full connection guide or see the HubSpot pipeline example.

Install the reusable workflows

We have also published six free, open-source agent skills for setup, business-data questions, customer context, read-only SQL, revenue analysis, and HubSpot–Stripe reconciliation:

npx skills add sqrr-ai/combined-agent-kit

Select the skills and agent you want in the installer. The skills guide the workflow; the MCP connection and your dataset grants provide access.

The public agent kit includes a runnable SQL example showing how a naive CRM-to-invoice join doubles totals, plus the corrected aggregation. Its fixture uses synthetic data and can be explored before connecting an account. Browse the 471 connector guides for source-specific setup and dataset references, or start with Combined to connect your own business data.

References: Combined MCP documentation and Claude Code MCP documentation.