Delete a specified equal-length net group from the PCB design to clear DRC constraints. Removes the named group, returning success status.
pcb_Drc.deleteEqualLengthNetGroup(equalLengthNetGroupName: string) -> Promise 删除等长网络组 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, the description must disclose behavioral traits. It reveals the return type Promise<boolean> and that the return indicates success, but it does not mention that deletion is irreversible, what happens if the named group does not exist, or whether deleting the group affects the nets it contains. For a destructive operation, this is a significant transparency 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 and front-loaded with the function signature, followed by a short Chinese action phrase and return semantics. Every line conveys relevant information with no fluff, though it is sparse enough that a bit more behavioral context would be welcome.
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 invocation details: the parameter to pass and the boolean return meaning. However, with no output schema and no annotations, it omits context such as how to obtain valid group names, error behavior, and the full consequences of deletion. It is minimally viable but not complete for a destructive operation.
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 schema only describes args as a JSON array in official signature order, without naming the items. The description compensates by providing the full signature equalLengthNetGroupName: string, telling the agent exactly what value belongs in the args array. This adds essential meaning beyond the generic schema.
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 verb 'delete' and the resource 'equal length net group' both in the signature and in Chinese (删除等长网络组), making the operation unmistakable. It also includes the parameter name equalLengthNetGroupName, which distinguishes it from sibling tools that create, modify, get, or add nets to equal-length net groups.
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 gives no guidance on when to use this tool versus alternatives. Sibling tools such as eda_pcb_drc_create_equal_length_net_group, eda_pcb_drc_modify_equal_length_net_group_name, or eda_pcb_drc_remove_net_from_equal_length_net_group exist, but the description does not mention how delete differs from them or when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.