eda_pcb_drc_overwrite_net_rules

Does 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 does well by explicitly warning that all current PCB net rules will be overwritten and noting data-loss risk, and it states the boolean return value. It does not mention reversibility or undo behavior, but the destructive scope is clearly disclosed.

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 short and front-loaded with the signature, followed by a concise summary, a useful data-loss remark, and the return meaning. The Chinese summary '覆写网络规则' is somewhat redundant with the tool name, but the structure is otherwise efficient.

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 destructive, all-scope overwrite tool with no output schema and a generic args schema, the description is incomplete. It omits the detailed structure of netRules, does not reference companion tools like get_net_rules for obtaining the current rule format, and gives no guidance on how to restore previous rules.

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 uses a generic args array with no item schema, and the description only provides the type Array<Record<string, any>> for netRules. This gives the agent little concrete information about what fields or rule objects are required, so it cannot reliably construct valid arguments without external knowledge.

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 clearly identifies the operation as overwriting net rules and adds scope via the remarks: it overwrites ALL network rules of the current PCB. This distinguishes it from sibling overwrite tools like overwrite_net_by_net_rules and overwrite_region_rules, though it does not mention these alternatives explicitly.

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?

There is no guidance on when to use this tool versus its alternatives, such as overwrite_net_by_net_rules for per-net changes or get_net_rules for reading before overwriting. The data-loss warning implies caution but does not explain the appropriate use case or prerequisites.

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