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

With no annotations, the description carries the full burden, and it does well: it reveals that the image is captured at physical resolution, never downscaled, and pixel positions match device_tap coords, plus image-only returns to keep the call fast. It also implies the prerequisite that the stream must already be running. However, it does not explicitly state what happens if the stream is not running or the output encoding, but it covers the key behavioral tradeoffs.

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 moderately sized but front-loaded with 'PREFERRED fast screenshot' and every sentence adds distinct value: performance rationale, resolution invariance, and alternative guidance. It is not overly verbose, though it could be slightly tightened. It earns a 4, not a 5, because there is some redundancy around 'faster' and 'fast' and the 'PREFERRED' emphasis is repeated thematically.

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?

Given the tool has only one parameter, no output schema, and no annotations, the description effectively covers the essential context: what it returns (a JPEG frame), the resolution guarantee, and when to use the alternative. It does not specify the exact return representation (e.g., base64 vs binary) or error behavior if the stream is not running, which would make it fully complete, but it is quite thorough for a simple screenshot tool.

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 already fully documents the single parameter 'udid' with 'Device serial number (UDID)' (100% coverage). The description does not add any extra meaning beyond that, so the baseline of 3 is appropriate; the schema is sufficient.

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 explicitly says 'PREFERRED fast screenshot of an Android device via the ALREADY-RUNNING shared video stream' and 'Returns a single JPEG frame decoded from the live video stream — no fresh full-resolution screen grab is spawned.' This clearly identifies the specific verb (screenshot), resource (Android device), and mechanism (video stream), and distinguishes it from device_screenshot. The purpose is 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?

It gives direct usage direction: 'Use this for routine per-action screen checks; it is much faster than device_screenshot, so make it your default for iterating on a flow.' It also explicitly reserves device_screenshot for cases needing 'the bundled labeled-elements list or a full-fidelity image.' This is an explicit when-to-use and when-not-to-use with a named alternative.

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