fgui_duplicate_package_item

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

With no annotations present, the description carries the full burden and does real work: it states the copy gets a new id, that on-disk files are duplicated, and that the original is unaffected — the key non-destructiveness fact for a mutation. It still omits whether changes persist only after saving (the save flag), what verify does, and how references/dependencies of the original are handled.

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?

Three short sentences with no filler; the core guarantee (new id, files copied, original untouched) is front-loaded, followed by naming then conflict behavior. Nothing is redundant.

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 described. Combined with the disclosed copy semantics, naming default, and conflict policy, the description covers enough for correct invocation of this duplication tool.

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 0%, so the description must compensate, and it does partially: it defines the default naming rule for new_name and, critically, enumerates the two legal conflict_policy values (error / auto_rename) that the schema leaves as an unconstrained string with no enum. However url, save, verify, and the item_name/item_path/package_name addressing trio are left completely unexplained.

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 names a specific verb and resource (复制包资源) and immediately clarifies the outcome: a new resource with a new id, with disk files copied. This distinguishes it in substance from fgui_duplicate_object and from fgui_rename/move_package_item, though it never names those siblings explicitly.

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: the conflict_policy sentence tells the agent how to behave when a name collides, which is a form of situational guidance. But there is no statement of when to prefer this over fgui_duplicate_object, fgui_import_image, or create-from-scratch, and no prerequisites (open document, package selected).

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