eda_lib_device_copy

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation and return value; it doesn't clarify whether the original device is modified, whether a new device is always created, what happens on conflict, or any side effects. For a copy (mutation) operation, this is a significant gap.

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 description is compact: a single signature line, a short Chinese label, and a returns note. Every component adds information, and the signature is front-loaded. Minor redundancy exists between the Chinese phrase and the signature's 'copy', and the mixed-language format is slightly awkward, but overall it is efficient.

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?

While the return type (new device UUID) is covered, there is no output schema, no annotations, and no behavioral/usage context. The description omits important details such as whether the source device remains untouched, whether the target library must differ from the source, and what the `undefined` return case means. For a mutation tool with five parameters, this is incomplete.

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?

The description's signature exposes parameter names, types, order, and optionality for all five actual parameters (deviceUuid, libraryUuid, targetLibraryUuid, targetClassification, newDeviceName), which the generic `args` array schema lacks. This is valuable for constructing the arguments, even though it doesn't explain the meaning of ILIB_ClassificationIndex or the exact behavior of newDeviceName.

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 provides the full function signature `lib_Device.copy(deviceUuid, libraryUuid, targetLibraryUuid, ...)` which clearly identifies the operation as copying a device between libraries, and the Chinese phrase '复制器件' (copy device) reinforces this. It is specific enough to distinguish from sibling copy tools like eda_lib_symbol_copy or eda_lib_footprint_copy, though it relies on the signature rather than a concise prose statement.

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?

No guidance is given on when to use this tool versus alternatives. The description doesn't mention conditions, prerequisites (e.g., source library must be accessible), or cases where another tool like eda_lib_device_create or eda_lib_device_modify would be more appropriate. Usage context is only implicitly conveyed by the name and signature.

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