capture

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

Goes far beyond the annotations: never overwrites, default destination folder, masking behavior per mode (screenshots masked, videos never masked), FLAG_SECURE screens come out black, videos are discarded if a banking/payment/identity app foregrounds, only one video at a time, and fixed encoding (MP4, 720p, 4 Mbit/s, no sound). The description is consistent with the structured hints (write operation, non-destructive because it never overwrites).

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?

Dense but front-loaded: the core purpose and default destination come first, then per-action semantics, then safety preconditions. A few clauses are run-on (the parenthetical seconds rules for record vs start repeat similar numbers), costing a little clarity, but almost every sentence carries operational information.

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?

Covers everything an agent needs for a 6-parameter, zero-required-parameter tool with no output schema: all parameter meanings, the four modes, masking and privacy edge cases, and even the return value ('the response gives the path'). No significant gap remains.

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 coverage is 0%, so the description must carry all parameter meaning, and it does: dest (default ~\Downloads\Telephone plus folder rules), name (optional file name, no folder), all four action enum values with their semantics, seconds (default 30/max 180 for record, default and max 180 for start), confirm and unmasked with their exact preconditions. This fully compensates for the empty schema descriptions.

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?

Opens with a specific verb and resource ('Save the phone screen as a file on the PC') and then defines each of the four action modes (screenshot, record, start, stop) distinctly. It also implicitly separates itself from siblings by referencing 'the same folder rules as files pull' and 'as on look images', so an agent knows this writes a file rather than viewing the screen.

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 concrete usage context ('to show a problem to a support service') and explicit gating conditions for the risky flags: confirm=true only on the user's explicit order for unusual folders or banking/identity screenshots, unmasked=true only when the user accepts unmasked codes and the UI tree is unreadable. It stops short of naming an alternative tool to use instead when capture is inappropriate (e.g. look for on-screen inspection), so no true when-not guidance.

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