multi_uiautomator2
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | No | OpenAI API key required for AI features (natural language driving, screen understanding, and self-healing). |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_server_statusA | Get automation-server status: uptime, idle-watchdog countdown and currently connected devices. The underlying server auto-starts on demand and exits after the idle timeout. |
| shutdown_automation_serverA | Manually stop the background automation server to free resources. It is re-spawned automatically on the next tool call, so this is always safe. |
| list_devicesA | List all Android devices attached via ADB, with their online state and whether a uiautomator2 session is already established. |
| connect_deviceA | Connect to an Android device and remember it as the default for all subsequent tool calls in this session. Returns screen size and current app. |
| disconnect_deviceA | Disconnect a device and release its uiautomator2 session. Omit serial to disconnect the current default device. |
| get_device_infoA | Get info about the current device: serial, screen resolution, Android SDK level, screen-on state and the foreground app. |
| start_appB | Launch an app on the current device by package name. |
| stop_appA | Force-stop an app by package name. |
| clear_app_dataA | DESTRUCTIVE: clear all user data of an app (logs the user out, wipes settings). Requires confirm=true. |
| get_screen_elementsA | Dump the current screen as a compact numbered list of interactive elements: [index] text="..." id="..." [flags] center=(x,y). This is the cheapest way to observe the screen; use the center coordinates with tap(x, y) or the text/resource_id with selector-based actions. |
| screenshotA | Capture the current screen as an image so you can visually verify state. Returns the image plus a text summary. Combine with_som=true with get_screen_elements to map numbered boxes to element indices. |
| tapB | Tap the screen either at (x, y) coordinates or on an element found by selector. Provide coordinates OR at least one selector field. |
| double_tapB | Double-tap at (x, y) or on an element found by selector (text / resource_id / index). |
| long_pressA | Long-press at (x, y) or on an element found by selector (context menus, selection mode, drag handles). |
| input_textB | Type text into an input field found by selector, or into whatever field currently has focus when no selector is given. |
| clear_textC | Clear the text of an input field found by selector, or of the currently focused field when no selector is given. |
| swipeC | Swipe/drag from (sx, sy) to (ex, ey). Get the screen size from get_device_info to compute coordinates. |
| scrollA | Scroll the current scrollable view in a direction without needing coordinates. |
| press_keyA | Press a device key: home, back, enter, delete, recent (app switcher), menu, search, volume_up/down, power, camera, or D-pad keys. |
| find_elementA | Check whether an element matching the selector currently exists on screen. Provide at least one selector field. |
| wait_for_elementB | Block until an element matching the selector appears (e.g. after tapping a button, wait for the next page). Provide at least one selector field. |
| ai_understand_screenA | Ask the server-side LLM to semantically analyze the current screen: page type (login/form/list/dialog), purpose and key elements. Requires OPENAI_API_KEY (or LLM_API_KEY / OPENAI_BASE_URL / LLM_MODEL) to be configured; otherwise prefer get_screen_elements + screenshot and analyze yourself. |
| ai_execute_goalA | Delegate a natural-language goal to the server-side AI agent, which runs its own observe-think-act loop on the device and returns a step log. Needs OPENAI_API_KEY (or LLM_API_KEY / OPENAI_BASE_URL / LLM_MODEL). Prefer the primitive tools (get_screen_elements + tap + input_text) unless the user explicitly asks to delegate. |
| ai_debug_screenA | Diagnose the current screen for crashes, ANRs, permission blockers or unexpected overlays and report findings; with auto_fix=true it also attempts recovery. Requires OPENAI_API_KEY (or LLM_* env). |
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 24 tools
Tools are largely distinct, but there is some overlap between screenshot/get_screen_elements (both observe the screen) and among the AI-powered tools (ai_debug_screen vs ai_understand_screen vs ai_execute_goal). Descriptions clarify differences, but an agent might occasionally misselect between observation and AI analysis tools.
Most tool names follow a verb_noun pattern (e.g., list_devices, start_app, input_text). The main deviation is 'screenshot', which is a noun without an explicit verb, and 'press_key' could be seen as slightly inconsistent but still clear. Overall, the naming is predictable and readable.
With 24 tools, the server is on the heavier side (16-25 is considered heavy). However, the count is justified by the breadth of features: device management, app lifecycle, UI interactions, observation, and AI delegation. Still, some tools (like the three AI ones) might be consolidated, making the set feel slightly bloated.
The toolset covers the core lifecycle: device connection, app control, UI interaction (tap, swipe, scroll, input), observation (screenshot, get_screen_elements), and waiting/finding elements. It lacks explicit handling of system dialogs or advanced gestures, but the AI tools can cover some gaps. Overall, no critical dead ends for typical automation workflows.