Copy an existing panel by UUID to create a duplicate. Returns the new panel's UUID on success, undefined on failure.
dmt_Panel.copyPanel(panelUuid: string) -> Promise<string | undefined>
复制面板
returns: 新面板 UUID，如若为 undefined 则复制失败
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns the new panel's UUID, and that 'undefined' indicates failure. This is useful behavioral information, but it doesn't mention side effects, permissions, or whether it operates on the active panel vs. a specified one. With no annotations provided, the description carries the full burden, and this is minimal but not misleading.
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 very concise, consisting of a signature line, a short Chinese label, and a return note. It's front-loaded with the core action and parameter. No wasted words, though it mixes English and Chinese, which could be slightly confusing.
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?
The description covers the core aspects: what it does, the parameter, and the return value. However, it lacks usage context, examples, or any note about side effects or failure conditions beyond 'undefined'. For a simple copy operation, this is adequate but could be more helpful with an example or note on how to retrieve the panelUuid.
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 input schema only shows a generic 'args' array, but the description provides the actual signature: 'panelUuid: string'. This adds meaning by specifying the parameter name and type, which the schema lacks. It clarifies how to construct the args array, going beyond the generic schema description.
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 the action clearly: '复制面板' (copy panel) with a function signature showing the parameter and return type. It's specific about what it does, and the name eda_dmt_panel_copy_panel matches. It doesn't explicitly differentiate from sibling copy tools (e.g., eda_dmt_board_copy_board) but the purpose is unambiguous.
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 on when to use this tool versus alternatives. There's no mention of prerequisites, when copying is appropriate, or how it differs from creating a panel. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.