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

There are no annotations, so the description carries the full burden of behavioral disclosure. It says 'Manage' but does not disclose staging/apply semantics, destructive operations, confirmation requirements, or return behavior. The schema hints at apply and confirm, but the description itself is silent.

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?

Two sentences, front-loaded with purpose and a direct next-step instruction. There is no filler, and the help guidance earns its place.

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 10-parameter, multi-action tool with no output schema and no annotations, the description is thin. However, the explicit 'call action=help' hand-off mitigates some gaps. It still omits staging/apply behavior, deletion confirmation, and return-value expectations, so it is adequate but not complete.

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 even without parameter details in the description. The 'action=help' hint is a useful addition, but the description does not explain individual parameters beyond what the schema already provides.

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 names a specific resource ('firewall aliases') and clarifies that these are the named address and port groups that rules reference. This distinguishes it from siblings like fw_rule, though the verb 'Manage' is broad and does not enumerate the concrete actions.

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 instruction to call action='help' is actionable and gives the agent a path to discover each action's fields and rules. However, it does not explicitly contrast with sibling tools or state when this tool should be preferred over them; the context implies alias management but not exclusions.

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

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 states 'Show', implying a read-only operation, but does not explicitly confirm safety, describe output format, or mention any side effects or prerequisites. This is minimal disclosure for a tool with no annotation support.

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 concise sentence with no filler or redundant details. It is appropriately sized for a simple show command and front-loads the core purpose effectively.

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 has no output schema and no annotations, yet the description provides only the barest functionality statement. It does not explain what the returned table looks like, how filters behave, or any limitations. For a tool with filters, this is incomplete context.

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 all three parameters (ip, mac, search) are already documented in the schema. The description adds no extra meaning about these filters, such as syntax or interaction between them, so it stays at the baseline score of 3.

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 action ('Show') and a specific resource ('ARP/NDP table'), which is distinct from the sibling tools. It is not a tautology and communicates the tool's core function immediately, though it does not explicitly contrast with siblings like 'diagnostics' or 'ipv6'.

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 no guidance on when to use this tool versus alternatives. It does not mention any conditions, use cases, or exclusions, leaving the agent to infer from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful trait: an empty result often means FRR has not been enabled. However, it omits that this tool can mutate system state (configure, create/delete/toggle_neighbor), presumably requires confirmation and staging in some actions, and may have irreversible effects. The description leans on the schema and the help action rather than disclosing these behaviors.

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, only two sentences, and front-loads the domain before the critical empty-result caveat. No sentence is wasted. The first sentence is a fragment and could be a bit more explicit, but it does not bloate the text.

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 complex – 15 parameters, 7 actions, no output schema, and no annotations – yet the description provides only the domain, one environment caveat, and a help-action instructon. The rich input schema compensates significantly, and the help action fills gaps. Still, the description does not cover side effects, when to use confirmed/staged flows, or relationship to siblings like 'routing', so it is not fully complete.

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 parameters are already well-documented in the input schema. The description's pointer to action='help' adds a meta-layer for discovering per-action fields and rules, but it does not directly clarify individual parameter meanings. This matches the baseline of 3 for high schema coverage.

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 'FRR BGP: peering state and neighbours' identifies the resource (FRR BGP) but lacks a verb; it reads like a label rather than a full statement of function. It does not explicitly say the tool can configure BGP or manage neighbors, which the action enum reveals. It is distinguishable from siblings like 'routing' by name, but the description itself is telegraphic.

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 alternatives or exclusion conditions are mentioned, and no sibling tools are referenced. The FRR-disabled caveat and the instruction to call action='help' provide operational context but do not tell an agent when to choose this tool over 'routing' or other siblings. Usage is implied by the resource name and scope rather than stated.

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

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

With no annotations, the description must carry the behavioral disclosure burden, but it only names resource areas and points to help. It does not reveal which actions are mutating, whether snapshots affect the boot environment, any side effects, or return behavior. There is no contradiction with annotations because none are provided.

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 two short front-loaded sentences with no filler, and the second sentence gives a concrete next step. It is concise, though the first sentence is a noun fragment rather than a complete purpose statement.

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 complex with 7 parameters and no output schema, and the description is not self-contained. However, the explicit action='help' instruction provides a viable discovery path for action-level rules, and the schema documents every parameter. It still lacks return shapes and side-effect warnings, making it adequate but not complete.

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 schema already documents each parameter with action-scoped tags such as [list], [diff], and [download]. The description adds only the pointer to action='help' for action-specific fields and rules, which is a discovery aid rather than new parameter semantics; baseline 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 identifies the domain—configuration backups, revision history, and boot environment snapshots—and distinguishes it from sibling config-editing tools by resource type. However, it provides no verb: it never states what the tool does with these resources (e.g., create, diff, download, list), so the purpose must be inferred from the action enum in 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?

It gives an explicit entry strategy: call action='help' to get each action's fields and rules, which is useful for an agent unsure of sub-action semantics. It does not, however, explain when to choose config_backup over sibling tools or which scenarios call for backups/revisions versus live configuration changes.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says to call action='help' for rules, but it does not mention that many actions mutate state, that changes may be staged rather than applied, that some actions require a confirm token,, or that delete actions exist. The schema hints at these behaviors via 'apply' and 'confirm' params, but the description itself gives no behavioral transparency.

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?

Two short sentences: the first states scope, the second gives an actionable pointer for details. No filler. For a tool with 31 params, this concise front-loaded structure is appropriate and every sentence earns its place.

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 31-parameter, 17-action tool with no output schema and no annotations, this description is not complete enough. It does give a useful help hook, but it fails to convey the breadth of actions, the mutation vs read distinction, the staging/confirmation model, or any guidance on choosing among sibling network tools. An agent can begin but cannot safely invoke correctly without extra calls and risky inference.

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 documents all 31 parameters and their action-specific scoping. The description adds nothing about parameter semantics, only directing the user to action='help' for per-action field rules. It doesn't add value beyond schema but also doesn't mislead.

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 names the resource domain clearly ('DHCP: leases, static reservations, ranges, options and per-subnet DNS') and distinguishes it from sibling tools by domain and resource types. It does not use a single specific verb, but for a multi-action dispatcher tool this is acceptable. The pointer to action='help' adds practical clarity about how to learn the available operations.

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 scope statement implies 'use this for DHCP management', which is reasonable given sibling names like bgp, alias, and dns_override. It does not explicitly say when not to use this tool or name alternatives. The instruction to call action='help' for field and rules is useful usage guidance, but only within the tool, not between tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It explicitly declares 'Read-only views', which is the key safety trait. However, it does not surface nuances such as packet_capture's start/stop/fetch lifecycle or ping's active network probes, which a fully transparent description for a 9-action tool would mention.

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?

Two sentences, front-loaded with a concrete scope list and followed by a single high-value self-help instruction. No filler or redundant elaboration.

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 31-parameter, 9-action tool with no output schema and no annotations, this description is deliberately broad and routes the agent to action='help' for per-action details. The schema's per-parameter action tags compensate for missing prose, but return semantics and per-action behavioral differences are not covered in the tool description itself.

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 100% and every parameter already has an action-tagged description, so the schema does the heavy lifting. The description only adds a meta-instruction to call action='help' for per-action fields and rules, which is useful but does not explain individual parameters. Baseline 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 states a specific purpose: read-only views of the firewall's current state, listing six concrete domains (neighbours, interfaces, state table, logs, captures, reachability). This makes the tool's scope clear and distinguishes it from config-oriented siblings by the 'read-only' framing, though it does not explicitly name an alternative.

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 'Read-only views' qualifier gives clear context: use this for inspecting current firewall state rather than modifying configuration. The explicit instruction to call action='help' for each action's fields and rules is actionable entry-point guidance. It does not state exclusions or name sibling tools, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It only says 'call action=help' and reveals nothing about side effects, whether changes are staged or applied immediately, restart/flush semantics, or other behavioral traits. The schema has hints, but the description itself is very thin.

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?

Two short sentences with no filler. The purpose is front-loaded and the help pointer is actionable, making this efficient and well-structured.

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?

With 10 parameters, no annotations, and no output schema, the description is minimal. The action='help' escape hatch mitigates missing details, but the description alone doesn't explain behavior, prerequisites, or when to use this tool versus alternatives. It is barely sufficient.

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 schema already documents all parameters. The description's tip to use action='help' adds a meta-level way to get per-action rules, which is helpful but does not add meaning beyond the schema's built-in documentation.

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 identifies a specific resource ('Unbound host overrides') and a verb ('Manage'), making the tool's domain clear. It doesn't enumerate the specific actions, but the schema's action enum covers that. The resource name distinguishes it from sibling tools like alias, bgp, or dhcp.

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 explicitly tells the agent to call action='help' for each action's fields and rules, which is a concrete usage directive. It doesn't contrast with sibling tools, but the specific resource makes the intended context clear and no exclusions are needed.

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

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 does not mention that changes can be staged, that apply/confirm may be required, that delete/toggle are destructive, or that set_group replaces membership rather than appending.

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 very concise and front-loaded with the domain. The pointer to action='help' earns its place, though the overall terseness leaves behavioral aspects unaddressed.

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 complex tool with 24 parameters, 9 actions, no annotations, and no output schema. The description gives only a high-level domain and a help pointer, which is insufficient orientation for correct selection and invocation of all these operations.

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 schema does the heavy lifting for parameter semantics. The description's mention of interface groups adds mild context for group-related parameters, but it does not add meaningful meaning 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 identifies the resource domain clearly: firewall filter rules and interface groups. However, it lacks a specific verb or action statement, leaving the actual operations to be inferred from the schema's action enum.

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 only usage guidance is to call action='help' for field-level details. There is no statement about when to use fw_rule versus sibling tools like nat_outbound or alias, and no exclusions or alternatives are given.

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

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

No annotations are provided, so the description carries the burden of explaining side effects and operational behavior. It only says resources are created and directs users to action='help'; it does not disclose deletion behavior, staging versus applying changes, failure modes, or consequences of actions despite some hints existing in parameter descriptions.

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-loads the core purpose in the first sentence. The second sentence provides a useful pointer to action='help' without cluttering the main description, though the phrasing 'devices interfaces are built on' is grammatically awkward.

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 multi-action tool with 15 parameters and no output schema or annotations, so a complete description would need to at least outline the main action categories and their effects. Instead, it mentions only creation and defers to dynamic help, leaving significant context for the agent to discover on its own.

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%, and the individual parameter descriptions are rich, including refusal cases and action-specific context. The tool description itself adds little parameter meaning, but with full schema coverage, 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 identifies a specific resource—VLANs and loopbacks—and a create action, which gives some clarity. However, the action enum includes set_address, delete, and list operations that the description never mentions, so it understates the tool's actual scope and could mislead an agent into thinking it only creates resources.

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 gives no guidance on when to use this tool versus sibling tools such as ipv6, routing, or fw_rule. The instruction to call action='help' is a fallback for field details, not a usage guideline that helps an agent choose this tool appropriately.

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

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

With no annotations, the description must carry the behavioral burden. It names the feature areas but does not mention that many actions mutate state, that some changes are staged until apply, that confirmation tokens may be required, or that delete/toggle/apply actions exist. The help pointer is useful but not a substitute for behavioral disclosure.

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?

Two sentences with no filler; the scope is front-loaded and the help pointer is useful. It is slightly too terse for such a complex multi-action tool, but as a concise overview it earns a 4.

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 22-parameter, 12-action tool with no output schema and no annotations. The description only gives a high-level feature list and defers to an action='help' call, so an agent still lacks context about which action to choose, what each returns, prerequisites, and staged-vs-applied behavior.

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%, and the schema already adds per-parameter context such as [create_npt], [create_vip], and defaults like dry_run defaulting to true. The description itself contributes no parameter meaning beyond directing users to the help action, so the baseline 3 applies.

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 identifies the domain and resources: NPTv6 prefix translation, virtual IPs, router advertisements, and ULA conversion. It is clear about the tool's scope but does not use a single specific verb or contrast it with sibling tools, so it falls short of a 5.

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?

There is no guidance about when to use this tool instead of siblings such as routing, interface_device, or nat_outbound. The only usage note is to call action='help' for each action's fields and rules, which helps within the tool but does not establish selection criteria.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior, but it does not mention staged changes, apply semantics, confirm tokens, or that actions mutate state. Saying rules are 'generated' hints at behavior but remains vague for a stateful multi-action tool.

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 compact sentence with no filler and front-loads the resource name and the help directive. It earns its place, though its brevity contributes to the lack of behavioral context.

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?

With 13 parameters, six actions, no annotations, and no output schema, a one-sentence description is insufficient for safe invocation. The schema covers parameter syntax, but the operational context—staging, apply behavior, confirm flow, and sibling differentiation—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%, and parameter descriptions already include bracketed action contexts like [create] and [mode], so the schema does the heavy lifting. The description adds only the pointer to action='help' for per-action details, which is useful but minimal.

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 names a specific resource, 'Outbound source NAT rules,' and mentions how they are generated, which distinguishes it from general routing or firewall tools. However, it lacks an explicit operation verb; the actual actions only appear in the input schema enum.

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?

There is no guidance about when to use this tool versus sibling tools such as fw_rule or routing. The only use instruction, 'Call action=help', explains how to explore fields but not when this tool should be selected.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses a genuinely important quirk: routes use 'enabled' while gateways use 'disabled,' so toggling means the opposite thing on each. However, it does not warn that delete/toggle operations are mutating, that changes may be staged, or that confirmation tokens are needed, so the behavioral picture remains incomplete.

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?

Three short sentences, each earning its place: the first states scope, the second warns about a non-obvious toggling asymmetry, and the third tells the agent how to get action-specific rules. There is no filler or repetition.

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 complex: 13 parameters, 10 actions, and no output schema, so the description alone is light. The action='help' directive mitigates this by pointing to authoritative per-action rules, but the description does not cover overall workflows like list-then-confirm or whether changes apply immediately. It is adequate as a pointer but not fully self-sufficient.

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 description adds crucial parameter semantics by explaining that 'enabled' vs 'disabled' has inverted meaning for routes vs gateways, which is not obvious from the schema's 'Target state, set explicitly rather than flipped.' It also directs the agent to action='help' for per-action field details.

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 identifies the resource domain as 'Static routes and gateways,' which clearly distinguishes it from dynamic routing siblings like bgp. It lacks an explicit verb like 'manage' or 'configure,' but the action enum in the schema supplies the operation vocabulary.

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 phrase 'Static routes and gateways' implies when this tool should be used, but it never names an alternative or states when not to use it. The instruction to call action='help' for each action's fields and rules is useful for learning the tool, but it is not guidance about selecting between sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions applying and auditing, but does not disclose important behaviors like staged changes, snapshot/restore effects, confirm tokens, destructive operations, or the side effects of any of the many actions.

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 two compact clauses with no filler: it states the domain and provides a concrete self-service mechanism for deeper details. Every sentence earns its place.

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?

Given 31 parameters, 26 actions, no annotations, no output schema, and complex operations like snapshots and audits, this one-sentence definition is not complete. Pointing to action='help' mitigates the gap, but the description still leaves selection, behavioral, and side-effect context entirely undisclosed.

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 schema itself documents all parameters, including action-name prefixes. The description adds no parameter meaning beyond pointing to the help action, which is useful but does not elevate it above the baseline.

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 identifies the tool as a traffic shaper operating on pipes, queues, and rules, and mentions applying/auditing. This is understandable and domain-specific, though it does not differentiate it from siblings beyond the domain label.

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 gives operational guidance by telling the agent to call action='help' for fields and rules, which is useful. However, it does not specify when to use this tool versus its siblings or when a particular action should be chosen.

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

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

With no annotations, the description carries full burden. 'Show' correctly indicates read-only behavior, but no additional traits (e.g., authentication needs) are disclosed. It's minimal but accurate.

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?

Single, clear sentence. No wasted words; front-loaded with purpose.

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 zero-parameter, read-only tool, the description fully covers what the agent needs. Sibling tools are all more specific, so 'system status' is adequately contextualized.

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 tool has 0 parameters, and schema coverage is 100%. Per guidelines, no parameter info is needed, so the baseline of 4 applies.

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 verb 'Show' and the resource 'system status information', which is distinct from sibling tools like arp or dns. However, it lacks specificity about what constitutes system status (e.g., uptime, load), so it's not a 5.

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 on when to use this tool versus alternatives. While it's implied for general status checks, explicit context or exclusions are missing.

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