Read the current Android accessibility tree, screenshot, or both to inspect UI state and get display-pixel coordinates for accurate taps and interactions.
Read a current accessibility tree and/or screenshot. Coordinates are Android display pixels; image pixels multiplied by pixel_to_device give action coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | tree | |
| max_nodes | No |
Changes observed during successful MCP inspections.
v0.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, openWorld=true, so safety intent is covered. The description adds a genuinely useful behavioral note that action coordinates must be derived from image pixels via pixel_to_device, but it does not say where that value comes from or explain the max_nodes truncation behavior implied by the 500 cap.
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?
Two short sentences with the core action front-loaded and no filler. The coordinate sentence is dense but earns its place, though 'pixel_to_device' is used without saying where it is obtained.
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?
With no output schema and 0% parameter documentation, the definition should describe what comes back (tree node fields, screenshot payload, how pixel_to_device is delivered). Instead it leaves the return shape and the parameter choices unexplained, which is a substantial gap for the observation primitive of an automation toolkit.
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?
Schema description coverage is 0%, so the description carries the full burden and largely fails: neither the mode enum values (tree/screenshot/both) nor max_nodes are explained. Only the coordinate convention is clarified, and that is about interpreting output rather than configuring these two parameters.
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?
States a specific verb (Read) and resource (current accessibility tree and/or screenshot), and the 'and/or' matches the mode enum. It does not differentiate itself from siblings like aua_screen, aua_screen_frame, or aua_find, so an agent must infer which read path to pick.
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?
No when-to-use or when-not-to-use guidance and no named alternatives among the many siblings. In particular, the description never says when to prefer mode=tree vs screenshot vs both, which is the main decision the caller must make.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.