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

The description honestly discloses that 'mirror' deletes extra files on the target and that 'update' overwrites changed files, plus that auto_retry requires a paid plan and the job runs in the background. That directly conflicts with the supplied destructiveHint=false, so an agent trusting the annotation alone could invoke mirror mode without warning the user; the disclosure is correct, the annotation is not.

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?

A single dense paragraph, front-loaded with the operation and its background nature, then parameter guidance in the order an agent needs it. The uppercase warning on mirror deletion is well placed and no sentence is filler.

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 an 8-parameter asynchronous job with a nested `entries` object and no output schema, the description covers the essential call mechanics and the async hand-off to get_transfer. It is only incomplete on the unmentioned `exclude` filter and the unexplained 'new' sync mode.

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?

With 0% schema description coverage the description carries the full burden and mostly succeeds: it explains `paths` (relative, empty/[''] = whole storage), `entries` (dict shape with is_dir/key/size/mime_type), `target_path` ('' = root), `sync_mode` values, and `auto_retry`. Gaps: `exclude` is never mentioned, and the enum value 'new' is left undefined while 'copy' is described as new-only.

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: 'Запустить перенос файлов между двумя облаками (server-to-server, фоном)'. It also names the follow-up tool (get_transfer) so the agent can tell it apart from list_transfers/cancel_transfer in the sibling set.

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 context: use `entries` for key-based clouds such as Google Drive, obtain them from list_files, and monitor progress via get_transfer. It has no explicit exclusion against the other transfer/upload siblings (remote_upload, list_transfers), so it falls short of a full when/when-not statement.

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