uci_delete

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 only restates the inherent destructive action ('Delete') and fails to mention that UCI changes are typically staged until a commit, or that deletions might be reversible via uci_revert. It also does not note potential side effects or validation behavior, leaving the agent without critical operational context.

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 a single, front-loaded sentence with zero redundant words. It efficiently states the purpose without any padding, making it easy for an agent to parse quickly.

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?

This is a destructive mutation tool with no annotations, no output schema, and a minimal description. The agent lacks critical context about the UCI commit/rollback lifecycle (e.g., that changes require uci_commit to persist, or that uci_revert can undo them). For a tool that deletes configuration, this is a significant gap that could lead to incorrect assumptions about immediacy and reversibility.

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 already provides a 100% description for the single 'path' parameter, including examples ('network.wan2', 'network.lan.dns'). The description adds no additional parameter semantics beyond what the schema already covers, so the baseline score of 3 is appropriate.

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 ('Delete') and the resource ('UCI section or option'), which is specific to the UCI configuration system. However, it does not differentiate from sibling tools like uci_del_list or uci_revert, which also delete or revert UCI entries. A stronger description might specify it deletes a whole section or a single option, unlike list-item removal.

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 provided on when to use this tool versus alternatives such as uci_del_list (for list entries) or uci_revert (for rolling back changes). The description gives no context about prerequisites, typical use cases, or exclusions, leaving the agent to infer the tool's role from the name and sibling list.

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