LookTap: I benchmarked 9 tools that let AI agents use a phone

The same 12 steps on an iPhone simulator and an Android emulator, 10 runs each, checked by a neutral oracle. What an agent actually feels is calls, bytes and setup.

Lakpriya Senevirathna · Oct 18, 2026 · 5 min read

Coding agents can write a mobile screen in minutes, but most of them can't look at it. They build the app, say it works, and you find out on the phone that the button is hidden behind the keyboard. I built LookTap so the agent can check for itself: it reads the screen as text, taps by label, types, swipes and reads the logs and crash reports, on iPhone and Android.

There are already several tools for this: Appium, Maestro, mobile-mcp, ios-simulator-mcp and others. So before telling anyone to use mine, I measured it against all of them.

What I measured

Every tool did the same 12 steps in the system Settings app: launch the app, read the screen, tap by label, go back, tap a point, swipe, scroll to a label, fill a field, take a screenshot, go home, open a URL and stop the app. Each tool ran the scenario 10 times on an iPhone 14 simulator (iOS 26) and a Pixel 9a emulator (Android 16), on one M3 Pro Mac.

Two choices made the numbers mean something:

A neutral checker decided whether each step worked, not the tool. On iOS that was idb ui describe-all; on Android, dumpsys. That mattered more than I expected: some tools reported success when nothing had happened.
Tools were driven the way an agent drives them. MCP servers ran over stdio with tools/call, CLIs ran once per step, and when a tool couldn't act on a label, the step read the screen first and that read counted as a call.

Raw speed isn't what an agent feels most. Each tool call is another round trip through the model, which takes seconds, not milliseconds. So alongside the time until the result was on screen, I report agent time: that time plus 2 seconds for every call. I also count the bytes of text each tool returns, because every byte lands in the agent's context window.

The results

On iOS, over the 8 steps every tool can do:

| Tool | Agent time | Calls | Text returned | Setup | |---|---:|---:|---:|---:| | LookTap CLI | 21 s | 8 | 747 B | 0.5 s | | LookTap MCP | 25 s | 8 | 3.2 KB | 0.5 s | | Maestro MCP | 30 s | 9 | 17 KB | 18 s | | Appium MCP | 36 s | 10 | 102 KB | 29 s | | mobile-mcp | 39 s | 14 | 24 KB | 7.6 s | | ios-simulator-mcp | 44 s | 20 | 17 KB | 1.5 s |

On Android, over 11 steps, the LookTap CLI took 28 s against 49 s for Appium MCP, 60 s for Maestro MCP and 62 s for mobile-mcp. Reading the screen took 108 ms, against 1.6–5.6 s for the others.

The biggest gap is the text. For the whole iOS scenario the LookTap CLI sent the agent 747 bytes. The MCP servers sent 17–102 KB, and most of them put a 40–270 KB screenshot inline as well. LookTap saves the screenshot to a file and prints its path, so the agent only spends image tokens when it decides to look.

Where LookTap loses

A benchmark written by the author of one of the tools should say where that tool does worse, so here it is:

On raw device time on iOS, ios-simulator-mcp is faster (4.5 s against 5.2 s), mostly because its fill takes 0.5 s against LookTap's 1.8 s. It needs 20 calls where LookTap needs 8, though, and its swipes sometimes did nothing.
On Android, Maestro MCP needs one call fewer (11 against 12), because it fills a field in a single call.
The LookTap MCP server is slower per action than the CLI. Every action waits for the screen to settle and returns it, which saves a call but costs 0.7–1.9 s. On Android that makes the MCP's total 13 s against the CLI's 4.4 s. That's the clearest thing for me to fix.
LookTap 0.2.1, the version I measured, couldn't do two of the steps: stopping an app, and the Home button on iOS. Both arrived in 0.3.0 (looktap stop and looktap home), but they aren't in these numbers.

And the limits of the benchmark itself: I wrote it and every adapter in it, LookTap was developed against this same app, and it covers one system app on a simulator and an emulator, not a real app on a real phone. The adapters are in the repo, and I'd welcome corrections from the other tools' authors.

Why the output is so small

Most agent mobile tools return the whole accessibility tree as JSON or XML. LookTap's ls prints one line per element that's actually on screen: a short ref, its type, its position and size, and its label.

text

@1   Button           16, 285 358x54  General
@2   Button           16, 339 358x54  Accessibility
@3   TextField        33, 773 324x38  Search  = Search

The agent taps by label (looktap tap General) or by ref, and adding --ls to any action returns the new screen in the same call. If a label matches more than one element, that's an error, never a guess. That's why one step is usually one call.

It's also why there's no server. Each platform gets a small helper that starts on first use and keeps running in the background: on iOS a macOS helper that reads the simulator's accessibility tree through Apple's simulator frameworks, and on Android a 10 KB jar pushed to the device that keeps one UiAutomation connection open. The CLI talks to it over a local socket, and the package has no npm dependencies.

Try it

npm install -g @looktap/cli
looktap doctor
looktap boot "iPhone 16 Pro"
looktap launch com.apple.Preferences --ls

In Claude Code, looktap skill --install teaches the agent how to use it, and there's an MCP server for chat apps that don't have a shell. The full benchmark, with every step, p90s, memory use and the commands to reproduce it, is in the repo.