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

Annotations establish this is a non-read-only, open-world, non-idempotent but non-destructive operation. The description adds useful behavior beyond that: it consumes no free file quota yet, returns a job id rather than the content, and can return a `pick_required` status with file listings for multi-file shares. That's meaningful outcome disclosure for a write-like async job starter.

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 with the core action and followed immediately by the return/poll semantics and the pick_required caveat. Three tight sentences with no filler, though the phrasing is slightly dense and could read more cleanly.

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?

An output schema exists, so return values need not be restated. The description still covers the key non-obvious outcome (job id to poll, pick_required branch) and quota implications, making it complete enough for an agent to call and follow up correctly; only minor details like authentication or failure modes are absent.

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 baseline is 3, but the description adds real meaning above the schema by explaining that `share_id` and `file_id` come from a `pick_required` answer and that they identify one file within a share. This clarifies the coupling between the optional parameters better than the per-field schema text alone.

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 (start fetching a link or a single file of a share) and immediately clarifies the scope difference from a full share download. The mention of the `get_job` follow-up and the `pick_required` outcome makes the tool's identity unambiguous against siblings like `download` and `get_job`.

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?

Explicitly says to poll the returned job id with `get_job`, and explains the important exception: Quark/PikPak shares with folders or multiple files start no job and instead return status `pick_required` with file listings, mirroring `download`. It does not state clear when-not conditions for the other sibling tools (e.g. check_link, get_download_link), but the primary routing context is given.

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