eda_pcb_drc_modify_differential_pair_name

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does state the return type Promise<boolean> and that the return indicates success, but it does not disclose side effects, error behavior when the original name is not found, or any impact on other DRC data. For a mutation tool, this is insufficient disclosure.

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 signature line, a one-line purpose in Chinese, and a return-value note. There is mild redundancy between the signature and the Chinese purpose statement, but the information density is high and the key details are front-loaded.

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 the tool's simplicity (two string parameters), the description covers the core action and return value. However, it omits operational context such as the target window default behavior (left to schema), and it does not mention what happens if the original differential pair does not exist. With no annotations and no output schema, a fuller note on failure conditions would make this complete.

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 an opaque 'args' array and optional windowId. The description adds meaningful parameter semantics by exposing the official signature with names and types: originalDifferentialPairName and differentialPairName. This clarifies the order and purpose of the two string parameters, going beyond what the schema provides.

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 explicitly states '修改差分对的名称' (modify differential pair name) and provides a precise function signature with both parameter names, so an agent knows this renames an existing differential pair. It is distinguishable from siblings such as create/delete differential pair or modify positive/negative net, though it does not explicitly call out those alternatives.

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, nor any prerequisites (e.g., the differential pair must already exist). The only implied usage is that it renames a differential pair, but the description lacks explicit when-to-use or when-not-to-use instructions.

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