iap_get_network_detail

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It conveys a read-only action by saying 'return detail,' but it does not explain how optional iap_ip_addr and cluster_name affect the request, what happens when the name is not found, or any authentication or rate-limit implications.

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 focused sentence of ten words. Every word earns its place, the verb and object are front-loaded, and there is no filler or redundant phrasing.

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?

An output schema exists, so return-value documentation is covered elsewhere. However, the tool description omits important invocation context: how the optional target parameters interact with the required name, when to prefer this tool over iap_get_networks, and any prerequisites. These gaps weaken completeness for an agent deciding whether and how to call the tool.

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 0%, and the description only adds meaning for 'name' by framing it as the network name. The optional parameters iap_ip_addr and cluster_name are left entirely unexplained; their titles give weak hints, but the description does not compensate for the lack of schema 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 uses a specific verb ('return') and clearly identifies the resource ('detail for one WLAN network') and lookup method ('by name'). It implicitly differentiates from iap_get_networks by specifying 'one' network, but it does not explicitly name or distinguish itself from sibling tools.

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 'one WLAN network by name' implies usage when a single named network's detail is needed, but there is no explicit guidance about when to use this tool versus iap_get_networks, iap_show_command, or other alternative tools. No exclusions or conditions are provided.

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