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

Annotations only declare the generic mutation profile; the description adds what actually matters here: the picker is user-driven, no path/size/format need be supplied, chat attachments do not reach aicut, size/format limits, cost (free within daily allowance), and the required follow-up behavior (no polling, no `upload_media`/`confirm_upload`, read newest URL from `list_uploads`). Nothing contradicts 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?

Front-loaded: trigger, timing, exclusions, same-reply protocol, limits, then output handling. It is dense and uses heavy capitalization, and a few clauses (e.g. repeating the 'no polling' instruction) could be tightened, but essentially 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?

Complete for a zero-parameter UI tool with no output schema: it covers invocation timing, what the user must do, what to say in the same reply, how to retrieve the result afterwards, and failure handling. An agent could call it correctly without consulting any other field.

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 tool takes zero parameters, so the baseline is 4. The description usefully explains that the file is chosen in the UI rather than passed as an argument, which prevents an agent from inventing a path/URL parameter.

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 action and resource in the first clause: 'OPENS A FILE PICKER IN THIS CONVERSATION', and clarifies where files land ('their aicut account for every tool'). It is clearly distinguishable from the sibling `upload_media`, which is named as the non-UI path.

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 trigger phrases ('upscale the clip in my Downloads'), explicit prohibitions (when the file is already a URL, when a shell command is possible, when no card renders), and a named alternative for each case (`upload_media`). It also covers the failure branch: if the user cannot see a picker, fall back to `upload_media` and do not retry.

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