Skip to main content
Glama
Starlordzz

multi_uiautomator2

by Starlordzz

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OPENAI_API_KEYNoOpenAI 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 24 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues