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

Annotations only say this is a non-destructive mutation; the description goes much further by disclosing the 30-per-call cap, the 5 MB/font/non-image exclusions, that paths are preserved, and that the resulting copies are left unsaved. The only thing not spelled out is permission or workspace requirements, so this is strong but not exhaustive.

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 destination, then the defaults, limits, exclusions and escape hatches in a logical order. It is dense but nearly every clause carries operational information; the Lottie sentence is slightly tangential yet saves a failed call, so it earns its place.

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?

With no output schema, the description still tells the agent what the response conveys (whether more images remain, what the owner must upload manually). Combined with the batch limit, exclusions and unsaved-state note, nothing needed to call it correctly or interpret the result 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 coverage is 100% and each of the three parameters is documented, so the baseline is 3; the description still adds real meaning by explaining what omitting paths does (copy everything not already present, in batches of 30) and that the paths mirror the imported project's layout.

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 (copies) and resource (images from an imported site under public/) and disambiguates the two projects involved — the source with IMPORTED.md and the destination rebuild — plus the reason (keeping /assets/... URLs working). An agent can distinguish it from move_file, write_file or create_items without opening the 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?

Explicitly routes around itself: Lottie .json files should be handled with read_file on the imported project and write_file to the same path, and continued copying is triggered by re-calling while the answer reports leftovers. It also names the fallback workflow (owner uploads excluded files in the Assets panel), leaving little to inference.

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