Skip to main content
Glama

native-full-hierarchy

Get the full UIKit view tree for deep layout debugging, finding unlabeled views, or verifying structure hidden from the accessibility tree. Prune subtrees and select fields to control large output.

Instructions

Get the complete UIKit view tree for the running app. WARNING: Output can be extremely large (100KB–500KB+) for complex apps, especially those built with SwiftUI. Prefer native-find-views for targeted queries. Use skipClasses / skipClassPrefixes to prune SwiftUI internal subtrees and reduce output size. Use the fields param to request only the properties you need. Use when you need deep layout debugging, finding views with no accessibility labels, or verifying view structure not exposed through the accessibility tree. Returns { status: "ok", windows, screen } with the full view hierarchy. screen gives the screen size in points on its portrait axes, and the interfaceOrientation of the UI (portrait, portraitUpsideDown, landscapeLeft, landscapeRight). Each screenFrame uses the portrait axes of the screen. Each windowFrame uses the axes of its window, which turn with the UI. If status is restart_required: follow the message (usually restart-app), then retry. If status is service_stale: the app is already injected, so restarting it cannot help — restart the tool-server (argent server stop && argent server start --detach) and retry. If the same status comes back after that restart, stop restarting: follow the message, which names the terminal fallback. If status is connect_pending: the app is injected and still connecting — do not restart it, wait a few seconds and retry. If status is init_failed: the simulator's native-devtools environment could not be initialised — follow the message (re-boot the simulator) rather than retrying this tool. A not-connected or not-running app comes back as one of those statuses rather than a failure. Failures are separate: an Apple system app is rejected outright (terminal — never retry it), and the hierarchy query itself can error or time out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidYesSimulator UDID
fieldsNoView fields to include. Use EXACT names: className, frame, hidden, alpha, identifier, label, nativeID, userInteractionEnabled, depth, pointer, tag, windowFrame, screenFrame, bounds, center, opaque, clipsToBounds, transform, contentMode, backgroundColor, tintColor, layerName. Defaults to all of the first group when omitted.
bundleIdYesBundle ID of the app
maxDepthNoMaximum recursion depth (default 8). Increase for deeper inspection, decrease to reduce output size.
skipClassesNoExact UIView class names whose entire subtree should be pruned (e.g. ["UIImageView"] to drop image leaf nodes)
skipClassPrefixesNoClass name prefixes to prune entire subtrees. For SwiftUI apps use ["_TtGC7SwiftUI"] to drop mangled SwiftUI generic type subtrees while keeping _UIHostingView and UIKit bridges. Avoid broad prefixes like "_UI" — they prune useful system views.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.26.0
    • changedInput schema / properties / fields / description
      Previous value: -"View fields to include. Use EXACT names: className, frame, hidden, alpha, identifier, label, nativeID, userInteractionEnabled, depth, pointer, tag, windowFrame, bounds, center, opaque, clipsToBounds, transform, contentMode, backgroundColor, tintColor, layerName. Defaults to all of the first group when omitted."New value: +"View fields to include. Use EXACT names: className, frame, hidden, alpha, identifier, label, nativeID, userInteractionEnabled, depth, pointer, tag, windowFrame, screenFrame, bounds, center, opaque, clipsToBounds, transform, contentMode, backgroundColor, tintColor, layerName. Defaults to all of the first group when omitted."
  2. First observedv0.15.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden. It discloses potentially huge output, statuses like restart_required/service_stale/connect_pending/init_failed, failure modes such as system app rejection and query timeouts, and the output shape including screen orientation and frame axes.

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?

Long but dense and well-structured. Purpose and the critical output-size warning are front-loaded, followed by pruning guidance, use cases, output shape, and status handling. Every sentence earns its place.

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?

For a complex tool with no annotations and no output schema, this description is remarkably complete. It covers output structure, statuses, failure handling, parameter usage, and when to prefer an alternative.

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. The description adds meaningful parameter guidance beyond the schema: exact field names, default maxDepth, and SwiftUI-specific pruning advice for skipClassPrefixes.

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?

States a specific verb and resource: 'Get the complete UIKit view tree for the running app.' It also distinguishes itself from native-find-views by warning against targeted queries and listing deep-layout use cases.

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 says 'Prefer native-find-views for targeted queries' and gives concrete use cases: deep layout debugging, finding views with no accessibility labels, and verifying structure not exposed through the accessibility tree. It also provides status-specific retry guidance.

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