Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_devicesB

List all connected Android devices/emulators and iOS simulators

device_infoB

(Android) Get detailed information about a connected Android device

connect_deviceC

(Android) Connect to a device over TCP/IP (wireless debugging)

launch_appB

Launch an Android app by package name, optionally specifying an activity

install_apkA

Install an APK file on a connected Android device

uninstall_appA

Uninstall an app from a connected Android device

clear_app_dataA

Clear all data for an app (cache, databases, shared preferences)

force_stopB

Force stop a running app

tap_xyA

Tap at raw screen coordinates (x, y). To tap an element by selector, use the 'tap' tool.

tap_elementC

Find a UI element by text, resource ID, or class name and tap its center

long_pressB

Long press at specific screen coordinates

swipeC

Swipe from one point to another on the screen

scroll_downB

Scroll down on the screen (swipe from bottom to top)

scroll_upA

Scroll up on the screen (swipe from top to bottom)

type_textA

Type text into the currently focused input field. Unicode is supported when ADBKeyboard is installed on the device.

press_keyB

Press a hardware/software key (BACK, HOME, ENTER, MENU, etc.)

take_screenshotA

Take a screenshot of the device screen and return it as an image (returns a large image; prefer observe_ui / observe_webview text — use only when those cannot answer).

dump_uiC

(Android) Dump the current UI hierarchy and return a structured representation of all visible elements

find_elementA

Find a UI element by text, resource ID, or class name and return its attributes and bounds. Returns the FIRST match with 8 of the node's attributes; describe_element returns every match with all 17 plus the index: a flow selector would use, and is the one to reach for when a selector may be ambiguous or when a state flag is in question.

get_current_activityA

Get the name of the currently resumed activity (foreground screen)

is_element_visibleB

Check if an element with the given text or resource ID is currently visible on screen

wait_for_elementB

Wait until a UI element matching the query appears on screen, polling at regular intervals

wait_for_textB

Wait until specific text appears anywhere on the screen

wait_for_activityC

Wait until a specific activity becomes the foreground (resumed) activity

assert_visibleC

Assert that an element is currently visible on screen. Returns an error if the element is NOT found.

assert_not_visibleA

Assert that an element is NOT currently visible on screen. Returns an error if the element IS found.

assert_textC

Assert that an element with a given resource ID contains the expected text

observe_uiB

Capture a compact, token-frugal snapshot of the current screen (actionable elements get a [ref=eN]).

describe_elementA

Read-only: dump EVERY attribute of the element(s) a selector matches — the state flags observe_ui hides (checkable, checked, selected, focused, enabled, password, scrollable), the full resource-id and class, and exact bounds. Returns one block per match with the index: a flow selector would use, so an ambiguous selector shows all its candidates instead of silently picking the first. Accepts the same enabled/checked/focused/selected qualifiers a flow selector does, so the index it reports is the index that selector will get. Use it while authoring to answer 'does this control expose its state at all?' before writing an assertion around it. For a single match with fewer attributes, find_element is the smaller answer.

tapA

Find an element by selector and tap its center. Waits for the screen to settle, then returns a fresh snapshot — annotated if it never settled.

input_textA

Type text into a field (optionally focus it first by selector). Uses ADBKeyboard for reliability. Waits for the screen to settle, then returns a fresh snapshot — annotated if it never settled.

check_testabilityA

Audit the current screen for locator stability: how many actionable elements have a stable id, which don't, and the Compose testTag fix. (Android; on iOS, id-coverage is not meaningful — see docs/ios-testing.md)

validate_flowA

Statically validate a YAML test flow file (schema, fragile-selector + undefined-env lint, and subflow resolution). No device needed. Call flow_reference for the YAML grammar.

flow_referenceA

Return the compact YAML-flow grammar reference (commands, selectors, env, switchContext, examples). Call this before authoring a flow — no file lookup needed.

run_flowA

Run a validated YAML test flow on a device (deterministic, no AI). Writes an HTML report and returns a pass/fail summary + report path. Call flow_reference for the YAML grammar.

observe_webviewA

List the app's debuggable WebView pages and return a compact DOM snapshot of the one with the most content (css-selectored). The app must opt in to WebView debugging: on Android WebView.setWebContentsDebuggingEnabled(true), on iOS WKWebView.isInspectable = true (16.4+; Safari needs no opt-in). Pass match (a URL substring/regex) to target a specific page; pin a page in a flow with switchContext "WEBVIEW_@".

webview_tapB

Tap an element inside the app's WebView by css (or text) selector, then return the updated WebView DOM (auto-waits + scrolls into view). Use the css from observe_webview; pass match= to target a specific page.

webview_inputA

Type text into a WebView field by css (or text) selector, then return the updated WebView DOM (focuses + sets the value so framework inputs accept it).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3/5.0

Scored across 38 tools

Disambiguation2/5

Multiple tools overlap heavily: tap_element and tap both tap by selector; type_text and input_text both type into fields; find_element, describe_element, dump_ui, and observe_ui all provide UI hierarchy/element querying. An agent would need to read detailed descriptions to avoid misselecting the wrong tool.

Naming Consistency3/5

Most tools use a readable verb_noun snake_case pattern, but there are notable inconsistencies: tap_element and tap are near-synonyms, type_text and input_text are duplicate concepts, and webview_tap/webview_input invert the expected verb-object order. The general pattern is still recognizable.

Tool Count2/5

38 tools is a heavy surface for a mobile testing server, and several tools are near-duplicates rather than genuinely distinct capabilities. The count would be more reasonable if tap_element/tap and type_text/input_text were merged.

Completeness4/5

The core mobile testing lifecycle is well covered: discovery, interaction, waiting, assertions, screenshots, app lifecycle, device management, WebView automation, and YAML flow validation. Minor gaps exist, such as clearing text fields, element-level swipes, and waiting for an element to disappear, but these are workaroundable.

Maintenance

ActivityActive
ResponsivenessNo issues