Delete a PCB from the active design window, with linked schematic and reuse module symbols also removed when possible.
dmt_Pcb.deletePcb(pcbUuid: string) -> Promise 删除 PCB remarks: 如若 PCB 已关联复用模块（在工程库内存在同名的复用模块符号），则删除 PCB 时将同步删除关联的原理图和复用模块符号，复用模块符号不可删除则跳过 returns: 操作是否成功
| 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly states that if the PCB is linked to a reused module symbol, deleting the PCB will also delete the associated schematic and reused module symbol, and that if the symbol cannot be deleted, it is skipped. This is critical side-effect information that an agent needs to know before invoking the tool.
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 concise, with a one-line signature, a one-line purpose, and a single remark about side effects. It is front-loaded with the signature and purpose before the remark. However, the remark is a bit verbose and could be slightly simplified, but it is efficient overall.
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?
Given that the tool has no output schema and no annotations, the description covers the key behavioral side effects (deleting associated schematic and symbol) and return type (boolean). It doesn't specify any error conditions or what happens if the PCB doesn't exist, but overall it is complete enough for an agent to use it correctly in most cases.
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 has 100% description coverage for parameters (args array and windowId), but the descriptions are generic ('按官方签名顺序排列的JSON参数数组'). The main description adds the signature 'pcbUuid: string', which clarifies the actual parameter, but it doesn't explain the exact format or required fields beyond that. Baseline 3 is appropriate as schema does most of the work, and the description adds marginal value.
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 opens with a clear signature showing the verb 'deletePcb' and the resource 'PCB', and the Chinese line '删除 PCB' translates to 'Delete PCB', making the purpose explicit. It is easily distinguishable from sibling tools like copy, create, or modify PCB tools.
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?
The description implies the tool is used for deleting a PCB but does not state when to use it versus other delete tools (e.g., eda_dmt_board_delete_board) or when not to use it. It does not mention any prerequisites, such as needing to be in a project context or having the PCB open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.