router_set_dmz

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

With no annotations, the description carries the full load, and it does usefully disclose that `force` bypasses a 'Network Guard' safety check and that `confirm` is needed to modify DMZ. However, it doesn't state the security implication of enabling DMZ (the internal host is fully exposed to unmapped inbound traffic), whether confirm must be true for changes to apply, or what happens if ip_address is omitted.

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?

Purpose is front-loaded in one sentence, followed by a compact Args block with no filler. The Args formatting is slightly verbose but every line conveys parameter meaning.

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 mutation tool with no annotations and no schema field descriptions, the description covers the essentials but omits key behavioral facts: DMZ exposure risk, the role of the confirm gate, and the relationship to router_get_dmz. An output schema exists, so return values need not be described.

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 coverage is 0%, so the description must compensate, and it does define all four parameters. Gaps remain: the semantics of `confirm` (is it mandatory? what does it gate?) are ambiguous, and the behavior of the default-empty `ip_address` when disabling is not explained.

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 opens with a specific verb+resource: it enables or disables DMZ host forwarding to an internal IP. That clearly distinguishes it from the read counterpart router_get_dmz, but the description never names the sibling or that router_get_dmz shows current state.

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 implies when to use it (to route all unmapped inbound traffic to one host), but it gives no explicit guidance on when to use this versus port forwarding (router_add_port_forwarding) or when to check state first with router_get_dmz. The `force` note hints at a precondition but doesn't state the normal path.

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