Skip to main content
Glama

Read the UI tree

ui_tree
Read-only

Capture the focused window's accessibility tree as JSON to inspect UI elements and target taps or swipes on Android and iOS devices.

Instructions

Return the focused window's accessibility tree as JSON, compact by default: nodes with no text, label or action and nodes off screen are left out. Node bounds [left, top, right, bottom] are the physical pixels tap and swipe take. On an iPhone it needs karagoz's runner: install it once with install_runner.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ui_tree"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNofull: every node.
deviceNoId or name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "full: every node.",
      +  "enum": [
      +    "compact",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial detail beyond readOnlyHint/openWorldHint: the default filtering rule (nodes with no text, label or action and off-screen nodes are omitted), the coordinate semantics of node bounds, and the requirement for karagoz's runner on iPhone. That is the kind of context annotations cannot express.

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?

Three front-loaded sentences with zero waste: output shape first, then coordinate semantics, then the platform prerequisite. Every sentence carries information an agent would otherwise have to guess.

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

Completeness4/5

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

With no output schema, the description does the return-value work: JSON, bounds ordering, and filtering behavior. It stops short of describing what fields a returned node contains beyond bounds, which is the main remaining gap for a tree-reading tool.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it states 'compact by default' (a default the schema does not) and explains what compact actually drops. The device parameter is only covered by the schema ('Id or name'), which caps this below 5.

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?

Specific verb and resource: 'Return the focused window's accessibility tree as JSON', with an explicit scope (focused window) and format. The mention that bounds are 'the physical pixels tap and swipe take' ties it clearly to the sibling tap/swipe tools, so an agent can tell it apart from screenshot without opening a schema.

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

Usage Guidelines4/5

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

States the default mode and the iPhone prerequisite, routing the agent to install_runner explicitly. It never states when to prefer this over screenshot or text, so the when-not side is left inferred rather than declared.

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