get_wifi_radio

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

No annotations are provided, so the description carries the full behavioral burden. It does add one genuinely important disclosure — PSK is redacted unless reveal_secrets=True — which is exactly the kind of security-sensitive behavior an agent needs. Beyond that it says nothing about permissions, whether reading triggers router load, or error behavior on an invalid band, so the coverage is partial.

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: the first front-loads the resource and its field list, the second carries the only behavioral caveat. No filler, no restatement of the tool name.

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 shape needn't be explained, and both parameters are covered including the band enum. The remaining gap is relational: nothing tells the agent how this differs from wifi_info or get_wireless_advanced, which matters given a crowded read-only sibling set.

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 schema has no enum or defaults documented, yet the description supplies the complete set of valid band values ('2g','5g','5g_2','6g') and defines reveal_secrets by its effect on PSK output. Both parameters are fully compensated for, which is the maximum the description can do here.

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?

States a specific resource (full radio settings for a single band) and enumerates exactly which fields come back: ssid, channel, htmode, encryption, txpower, mu_mimo, airtime_fairness. It does not distinguish itself from sibling readers like wifi_info or get_wireless_advanced, so an agent can tell what it does but not precisely why it would pick this over those.

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?

Usage is only implied: the reader is for inspecting one band's radio configuration, and the presence of set_wifi_band / set_wifi_channel / set_wifi_security as siblings hints at read-vs-write pairing. No explicit when-to-use, when-not-to-use, or named alternative is given.

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