lb_delete_forwarding_rule

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

Annotations are absent, so the description carries the full disclosure burden. While it mentions a success message is returned, it does not communicate that deletion is destructive and irreversible, that permissions are required, or that traffic may be disrupted. These are the kinds of behaviors an agent should be told for a delete operation, and the description does not add enough value beyond what the name already implies.

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 well-structured with clear Args and Returns sections, and it avoids unnecessary prose. The main structural flaw is the doctext param `ctx` appearing in the Args list while the schema only defines two parameters, which is a small but notable inconsistency for model invocation.

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 is a straightforward deletion, and an output schema exists, so return format may be covered elsewhere. Still, the description lacks contextual warnings about irreversible effects, the parent load balancer's membership requirements, or what happens when the specified forwarding rule is already absent. For a destructive action, this is slightly below what an agent would benefit from, and it does not leverage any annotations since none are provided.

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?

Because schema description coverage is 0%, the description must clarify parameter meanings. It adds useful detail for load_balancer_id, noting it can be a label or UUID with examples. However, forwarding_rule_id is only restated as 'the forwarding rule ID' with no format or provenance hint, and a 'ctx' argument is listed in the docstring but is completely absent from the input schema, creating potential confusion.

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 a clear, specific action: 'Delete a forwarding rule from a load balancer.' The verb and resource are precise, and the tool is clearly distinguishable from siblings like lb_create_forwarding_rule, lb_list_forwarding_rules, and lb_get_forwarding_rule without requiring the schema.

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 is provided on when to use this tool versus sibling tools such as lb_create_forwarding_rule, lb_list_forwarding_rules, or lb_get_forwarding_rule. The description gives no alternative tool references, no exclusions, and no conditions like 'use only when a forwarding rule needs to be removed.' The agent must infer usage solely from the tool name.

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