Inspect Layout

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

With no annotations, the description carries the full burden of explaining behavior. It usefully states that the tool returns computed layout data with bounds, not raw structure, and that interactive_only filters to touchable nodes. However, it overstates by claiming 'every node' while the schema's max_nodes defaults to 400, and it does not mention xml_path side effects or output limits.

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

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

The description is three concise sentences with the core behavior front-loaded. The Android/getBoundingClientRect analogy adds context without bloat, and the final sentence briefly ties the only discussed parameter to a concrete use case. No sentence is wasted.

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

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

The tool has four optional parameters and zero schema descriptions, yet only interactive_only is addressed. Output limits, device selection, and xml_path behavior remain undocumented, and the 'every node' phrasing conflicts with the default max_nodes. The output schema reduces the need to document return shapes, but it cannot compensate for these gaps.

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

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

The schema has 0% description coverage, so the description must compensate for parameter semantics, but it only explains interactive_only. device, xml_path, and max_nodes receive no meaningful guidance, and the interaction between max_nodes and the claim of 'every node' is left unclear. This is partial compensation at best.

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

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

The description opens with a specific result — the full computed layout of the current screen with every node's bounds — making the tool's function immediately clear. This also distinguishes it from sibling tools like element_context and accessibility_spatial, which concern individual elements or accessibility rather than the whole layout tree. Although the verb is implicit, the resource and scope are unmistakable.

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

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

The getBoundingClientRect() analogy provides a concrete, recognizable use case, signaling this tool is for computed geometry of the entire screen. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to guide invocation.

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