Skip to main content
Glama

Read the on-screen UI tree

android_dump_ui
Read-only

Dump the current screen's view hierarchy as text, including tap coordinates for each element, so agents can identify UI elements and tap them directly without guessing pixel positions from screenshots.

Instructions

Dump the current screen's view hierarchy as text, with tap coordinates for every element.

This is the cheap way for an agent to see what is on screen. It gives exact text, resource ids and content descriptions, plus a centre point for each node that can be passed straight to android_tap — no guessing at pixel positions from a screenshot.

By default only meaningful nodes are returned (anything with text, a content description, a resource id, or that is clickable). Layout containers are dropped.

Args:

  • serial (string, optional): target device

  • include_all (boolean): return every node including empty containers (default: false)

  • filter (string, optional): case-insensitive substring; keeps only nodes whose text, id or description matches

  • response_format ('markdown' | 'json')

Returns: { "count": number, "nodes": [ { "index": number, "class": string, // e.g. "android.widget.Button" "text": string, "desc": string, // content-description "id": string, // resource-id "clickable": boolean, "center": [number, number], // pass to android_tap "bounds": string // "[left,top][right,bottom]" } ] }

Examples:

  • Use when: you need to press a button and must know where it is -> filter="submit"

  • Use when: verifying a screen shows the expected text after a change

  • Use when: a screenshot is ambiguous and you want the literal string values

  • Don't use when: you need to see rendering, colour or layout quality (use android_screenshot)

Error Handling:

  • "could not get idle state" means the UI is still animating; wait briefly and retry

  • WebView content is often opaque to uiautomator; a screenshot may be the only option there

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoKeep only nodes whose text, resource id or description contains this string.
serialNoDevice serial from android_list_devices. Optional when exactly one device is connected; required when several are.
include_allNoInclude layout containers and other nodes with no text or id.
response_formatNoOutput format: 'markdown' for human-readable, 'json' for machine-readable.markdown
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=true, etc.), the description discloses default filtering (meaningful nodes only), error handling ('could not get idle state'), WebView limitations, and the exact return shape. This adds significant behavioral context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Args, Returns, Examples, Error Handling). Every sentence contributes meaningful information, and the purpose statement is front-loaded. No redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description provides a full return contract, error handling, and interaction with sibling tools. It covers all necessary context for an agent to decide when and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches each parameter with practical usage (e.g., filter='submit') and clarifies the response_format options. It also explains how the output (center point) feeds into android_tap, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Dump the current screen's view hierarchy as text, with tap coordinates for every element.' It clearly distinguishes from android_screenshot by explaining when a screenshot is preferred, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when' and 'Don't use when' sections give explicit context and name alternatives (e.g., android_screenshot for visual rendering). It also references android_tap for coordinates, showing how the tool fits into a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jjs03111/android-build-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server