delete_nat_rule

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

The description discloses irreversible consequences, immediate traffic translation stoppage, and potential DNAT/SNAT connectivity breakage, which is rich behavioral context beyond the destructiveHint and idempotentHint annotations. It also clarifies the return format ('confirmation string, or an Error string — not a dict'), a useful trait not present in any annotation.

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 front-loaded with the action marker '[WRITE]' and the primary verb. Each sentence earns its place: scope, irreversibility, prerequisite steps, user confirmation, and return type. There is no redundant wording or restatement of the schema.

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 mutation tool, the description covers what is deleted, why it is dangerous, how to verify before deleting, what to do before calling, and what the response looks like. The output schema is indicated as present, and the description itself communicates the return behavior, so nothing critical is missing.

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?

Schema description coverage is 100%, so the baseline is 3. The schema already explains rule_id and tier1_id, and the description reinforces the relationship between them by advising to run list_nat_rules on the same tier1_id. The optional target parameter is not elaborated, but the schema documents its default. Thus the description adds only marginal value beyond the schema.

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 specific verb and resource: 'Permanently delete a NAT rule from a Tier-1 gateway's USER NAT section.' This clearly distinguishes the tool from siblings like create_nat_rule and list_nat_rules, and the qualifier 'USER NAT section' adds precision beyond the name alone.

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?

The description provides explicit sequential guidance: run list_nat_rules on the same tier1_id first, confirm the rule_id, review its action and networks, and confirm with the user before deleting. This goes beyond vague context to actionable when-to-use instructions that reduce the risk of accidental deletions.

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