Delete screenshots

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, yet the description still adds material context beyond them: the two-step dry-run confirmation workflow, the ASC_WRITE=1 authorization requirement, and the fact that surviving screenshots retain their relative order. That is exactly the extra behavioral payload the rubric credits.

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 paragraphs with zero filler: the operation and its addressing modes come first, then the destructive/confirmation protocol. Every sentence carries information an agent needs.

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 7-parameter destructive mutation with no output schema, the definition covers what an agent needs: what is deleted, how targets are addressed, that it is destructive, the required confirmation loop, and the auth gate. Nothing essential 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?

Schema description coverage is 100%, so the schema already documents app, locale, version, platform, dry_run, screenshots and display_type. The description adds only the '1-based' indexing detail for positions, which is genuinely absent from the schema, but otherwise restates what is already structured (e.g. the dry_run default). Baseline 3 is the right level.

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 ('Deletes screenshots') plus the two addressing modes (1-based position or ID), and the ordering side effect on remaining items. An agent can distinguish this immediately from replace_screenshot, reorder_screenshots, upload_screenshots and list_screenshots without opening any 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 a concrete operational protocol: dry_run defaults to true, show the plan to the user, then re-call with dry_run: false, and notes the ASC_WRITE=1 prerequisite. It does not explicitly route between this tool and its nearest siblings (replace_screenshot / reorder_screenshots), so it stops short of full alternative selection guidance.

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