eda_pcb_drc_save_rule_configuration

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

The description includes a meaningful constraint: only custom configurations can be overwritten, and system configurations cannot be modified. This discloses a behavioral rule beyond what annotations would provide (none are present). However, it doesn't state side effects like whether it creates a new config or overwrites an existing one, or any prerequisites like an open PCB document. As a mutation tool without annotations, more disclosure is expected.

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, including the signature, purpose, a key constraint, and return type. It's not verbose and the signature is front-loaded. The Chinese phrase is somewhat redundant with the signature, but overall it's 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?

The tool saves a complex rule configuration, but the description lacks essential details: the structure of ruleConfiguration, the behavior when allowOverwrite is false and the name already exists, prerequisites (e.g., an open PCB document), and how this differs from overwrite_current_rule_configuration. Without an output schema, the agent lacks enough context to call it correctly.

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 signature provides parameter names and types: ruleConfiguration (Record<string, any>), configurationName (string), allowOverwrite (boolean, optional). This adds meaning beyond the generic args array in the schema. However, it doesn't explain the structure or allowed keys of ruleConfiguration, nor the effect of allowOverwrite beyond the overwrite constraint. It adds some semantics but not full parameter meaning.

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 states the action via the function name and the Chinese phrase '保存设计规则配置' (save design rule configuration). It indicates the resource (rule configuration) and the verb (save). However, it does not differentiate from sibling tools like eda_pcb_drc_overwrite_current_rule_configuration, so it's clear but not fully distinguishing.

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 explicit guidance on when to use this tool versus alternatives. The remarks about overwrite constraints are behavioral, not usage guidance. It doesn't mention when to prefer save over overwrite_current_rule_configuration or other DRC tools. The agent has to infer usage from the name.

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