Skip to main content
Glama

describe_ui

Read the current UI hierarchy as a list of tappable elements with exact pixel centers, so you can aim taps accurately instead of guessing from a downscaled screenshot.

Instructions

Read the on-screen UI hierarchy as a list of elements, each with its text, content_desc, resource_id, class, clickable flag, pixel bounds, and a precomputed center in TRUE DEVICE PIXELS. This is your source of truth for AIMING: pass an element's center straight to tap. Never guess coordinates from the screenshot (it is downscaled and you will miss). The response header states the FOCUSED WINDOW (if it's a system overlay — biometric prompt, permission dialog — the elements belong to that overlay, not your app) and how many nodes the filter hid. Default filter keeps labelled/clickable/id-carrying elements minus redundant wrappers; filter="clickable" returns only tap targets (much smaller); filter="all" returns every bounded node — the only mode where absence proves an element isn't in the hierarchy. Canvas-drawn (RN/Flutter/Skia) content appears in NO mode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoCase-insensitive substring to match against text, content_desc, and resource_id — return only matching elements. The cheap way to ask 'is X on this screen?'. Combine with filter='all' to prove absence definitively.
filterNoWhat to include: 'auto' (default — elements with text, content_desc, resource_id, or clickable; identical-bounds label-less wrappers dropped), 'clickable' (tap targets only, the smallest view), or 'all' (every bounded node, unfiltered — use to PROVE an element is absent from the hierarchy).
serialNoTarget device serial (adb -s). Optional when exactly one device is attached.
compactNoReturn one line per element (center, bounds, flags, labels) instead of JSON — ~10x fewer tokens, same aiming information. Use for repeated look-drive loops and geometry work.
packageNoOptional package expected to own the focused window. If another app or SystemUI owns focus, the response calls that out explicitly.
Behavior5/5

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

With no annotations, the description fully discloses key behaviors: coordinates are true device pixels, response header contains focused window and hidden node count, canvas-drawn content never appears, and filter behavior for proving absence.

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

Conciseness4/5

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

The description is packed with valuable information and well-organized, but slightly verbose. Every sentence serves a purpose, though some could be tightened (e.g., 'This is your source of truth...' sentence is clear but slightly long).

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 the complexity (multiple filters, aiming guidance, canvas limitation, overlay handling) and absence of output schema, the description covers all essential behavioral and usage aspects completely.

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?

Schema coverage is 100%, but the description adds significant context beyond the schema: explains query as a cheap existence check, compact as token-saving, package as owner expectation, and filter modes with concrete use cases.

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 uses a specific verb ('Read') and resource ('on-screen UI hierarchy'), and lists the exact fields returned. It clearly distinguishes from sibling tools like 'screenshot' by emphasizing true device pixels vs downscaled screenshot.

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?

Explicitly states this is the source of truth for aiming, advises against guessing coordinates from screenshots, explains when to use each filter (auto, clickable, all), and warns about system overlays changing the focused window.

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/iksnerd/adb-mcp'

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