Renames a PCB and, if linked to a reuse module, also updates the module symbol and related schematic name.
dmt_Pcb.modifyPcbName(pcbUuid: string, pcbName: string) -> Promise 修改 PCB 名称 remarks: 如若 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 the full burden of behavioral disclosure. It discloses a meaningful side effect: if the PCB is associated with a reuse module symbol, renaming will also rename the reuse module symbol and the associated schematic name. It also states the return type (Promise<boolean>) and the return meaning ('是否修改成功'), which is useful. It does not discuss reversibility or permissions, but the key non-obvious side effect is covered.
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: signature, one-line purpose, a focused remark about side effects, and the return meaning. Every sentence earns its place, and the core purpose is front-loaded before the side-effect note.
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?
For a two-parameter rename with no annotations and no output schema, the description covers the purpose, side effect, and return. However, it lacks guidance on how to discover the pcbUuid, whether a specific window must be active, and any constraints on the new name. These are not fully compensated by the schema, which only describes the generic args array and windowId.
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 exposes generic `args` and `windowId`, but the description provides the exact function signature with parameter names and types: `(pcbUuid: string, pcbName: string)`. This adds meaning beyond the opaque schema and establishes the required order for the args array. The parameter names are self-explanatory, though deeper semantic detail (e.g., where to find pcbUuid, name constraints) is not included.
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 a clear verb and resource: '修改 PCB 名称' (modify PCB name), and the signature `modifyPcbName(pcbUuid, pcbName)` reinforces the operation. The resource (PCB) is distinct from the many sibling modifiers like board_name, panel_name, project_name, and schematic_name, so an agent can tell it apart without opening sibling 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?
No guidance is given about when to use this tool versus alternatives such as modify_board_name or modify_panel_name. It does not mention prerequisites, how to obtain the pcbUuid, or whether a specific window/document must be active. The distinction is left entirely to the tool name and implicit resource understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.