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

Annotations already declare the safe read-only, idempotent, non-destructive profile, and the description adds rich context beyond them: the default page-source fetch, the device-tap coordinate space with no scaling required, and the performance trade-off versus the MJPEG stream. It also explains that includeElements=false skips the page-source fetch, which is behavioral detail not present in the annotations.

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 core purpose and return are front-loaded, and every subsequent sentence carries distinct routing, fallback, or parameter-effect information. Despite its length, there is no filler, and each sentence helps the agent choose correctly.

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?

For a tool with no output schema and several close siblings, the description is complete: it explains the return payload, coordinate space, default behavior, token-saving option, and all relevant alternatives. Nothing needed to invoke it correctly is missing.

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?

With 100% schema description coverage, the baseline is 3, but the description adds meaningful semantics for includeElements by explaining that setting it false skips the page-source fetch and returns only the image, and that the default bundles the labeled element list. The udid parameter is not further explained, but it is self-evident and fully documented in the schema.

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 and resource ('Take a screenshot of a device') and immediately clarifies scope ('one frame') plus the dual return (JPEG image + labeled UI elements). It explicitly distinguishes itself from siblings like device_tap_by_text, android_video_stream, and android_mjpeg_screenshot, so an agent can route correctly without opening the schema.

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?

Gives explicit when-to-use and when-not-to-use guidance: prefer device_tap_by_text for labeled elements, use returned bounds only as fallback, use android_video_stream for continuous observation, and reserve this tool for labeled-element or full-fidelity needs rather than routine checks. It also names the alternative android_mjpeg_screenshot for routine per-action checks.

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