copy-drive-file

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful cross-drive capability note but omits key behavioral facts for a copy operation: whether an existing destination file is overwritten, what the response contains (e.g., the new file ID), and any permission/auth requirements implied by openWorldHint.

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?

The leading sentence is front-loaded and clear, and the compact example is genuinely useful for a tool with four ID parameters. The 'Required' bullet list largely duplicates the schema, costing some efficiency but not much space.

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 mutation tool with no output schema, the description should say something about the result (e.g., the copied file's new ID) and about overwrite behavior at the destination. The cross-drive note and example help, but these two gaps keep it at minimum-viable.

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 all four parameters; the baseline is 3. The description repeats the schema text nearly verbatim, adding only the clarification that destinationDriveId may equal driveId, which is a marginal but genuine addition.

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?

The description states a specific verb and resource (copy a file) and names the domain (Dooray drive) plus the destination concept. It does not explicitly differentiate itself from sibling 'move-drive-file', which is the closest alternative, but the verb 'copy' is distinct enough that an agent can infer the difference.

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?

Usage is only implied by the word 'copy' — no explicit statement of when to pick this over move-drive-file, update-drive-file, or upload-drive-file. The note that the destination drive can be the same or different adds a useful scoping hint but is not real when/when-not guidance.

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