agent-phone
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| phone_startA | Boot an Android phone, installing anything missing first. Choose a device profile (pixel-8, pixel-8-pro, small-phone, compact, tablet), or pass width/height/density to match any phone. Reuses the phone if it's already running. |
| phone_stopC | Shut down a running emulator. |
| phone_listA | Show connected devices and the available device profiles. |
| phone_lookA | Read the current screen: the numbered element list, plus a screenshot unless screenshot is false. |
| phone_tapA | Tap an element by ref or visible text, or a point by x/y (screenshot pixels). Set long for a long-press. |
| phone_typeA | Type text into the focused field, or first tap a field given by ref or field (its visible text or hint). Newlines press Enter. ASCII only for now. |
| phone_scrollB | Scroll to reveal more content in a direction ("down" shows what is below). Optionally inside a scrollable element. |
| phone_swipeA | Drag a finger from one point to another (screenshot pixels). For gestures that scrolling does not cover. |
| phone_keyA | Press a hardware or navigation key: back, home, recents, enter, delete, backspace, tab, escape, space, menu, search, power, volume_up, volume_down, up, down, left, right, or any Android KEYCODE_* name. |
| phone_openB | Open an installed app by package name (e.g. com.android.chrome), a URL or deep link (myapp://route), or "settings". |
| phone_installA | Install (or update) an APK file from this computer, granting its permissions. Pass open with the app's package name to launch it afterwards. |
| phone_appA | List installed apps (action "list"), or force-stop, clear the data of, or uninstall an app by package name. |
| phone_logsA | Read logcat. Filter to one app by package, by minimum level, or to crashes only. clear empties the log first. |
| phone_test_startB | Restart an app and record everything you do from here as a repeatable test. Defaults to the app currently on screen. |
| phone_assertA | Check that text (or an element id) is on screen, or with visible false that it is not. Waits up to 5 seconds. While recording, passing checks become assertions in the test. |
| phone_test_saveB | Write the recording as a Maestro-format YAML flow. Recording continues, so you can save again later. |
| phone_test_runA | Replay a Maestro-format YAML flow on the phone, step by step, and report pass or fail. No AI is involved in the replay. |
| phone_shellB | Run a command in the device shell (adb shell). For anything the other tools do not cover. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target clearly different actions: UI interaction, emulator lifecycle, app management, logs, and test recording are well separated. A few boundaries are softer, such as phone_scroll versus phone_swipe, phone_open versus phone_start, and phone_list versus phone_app list, but the descriptions clarify these cases.
All tools use a consistent lowercase snake_case phone_ prefix, and the test tools form a clear phone_test_start/save/run family. Minor inconsistency comes from some names being resource-oriented (phone_logs, phone_app, phone_shell, phone_key) while others are action-oriented (phone_tap, phone_look).
Eighteen tools is slightly heavy but justified by the broad mobile-automation scope, which spans emulator lifecycle, app management, UI interaction, logs, shell access, and test recording. Each tool appears to earn its place, though the set is near the upper end of what feels comfortably scoped.
The surface covers the core mobile-agent workflow well: boot/stop devices, install/open/manage apps, inspect and interact with the screen, read logs, run shell commands, and record/replay tests. Minor gaps exist around test artifact management (listing, deleting, or editing saved flows) and some device controls are only reachable through phone_shell.