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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does add useful context: the tool activates a saved profile and supports forcing activation even when another profile is active. However, it does not explain what happens when override_active is False and another profile is active, whether network interfaces are restarted, or how the change is reflected in the system—material gaps for a state-changing 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 compact and front-loaded: the one-sentence summary states the core action immediately, followed by a minimal Args block. Every sentence contributes semantic value, and there is no filler or redundant boilerplate.

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 two-parameter tool with an output schema, the description is close to sufficient: it defines both inputs and the primary activation effect. Still, it omits edge-case behavior (e.g., failure when another profile is active and override_active is false) and side effects, and it does not connect to related sibling tools like get_network_config_status or deactivate_network_config. These are understandable but notable gaps.

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 input schema provides only types and titles, with 0% schema description coverage. The description compensates by explaining that id is the configuration profile ID to activate and that override_active forces activation despite another active profile. Both parameters receive meaningful semantics beyond their raw names, though id could specify where valid IDs come from (e.g., list_network_configs).

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: 'Activate a saved network configuration profile.' This clearly identifies the main action and target. It does not explicitly distinguish itself from sibling tools like deactivate_network_config or update_network_config, but the meaning is clear enough that an agent could tell activation apart from the lifecycle alternatives.

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 on when to use this tool versus its siblings, such as 'use after list_network_configs' or 'use instead of create/update if the profile already exists.' The phrase 'saved network configuration profile' implies a precondition, but no explicit workflow, prerequisites, or exclusions are provided.

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 full burden and does so thoroughly. It discloses read-only semantics, that the role is always 'subscriber', that it blocks for duration_s, that it includes the owner's config, and the raw pcapng path. The single-radio caveat is a valuable behavioral disclosure beyond basic function.

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 long but highly structured, with a purpose paragraph, an output/context paragraph, a caveat paragraph, and an Args list. Every sentence carries information; nothing is redundant. Front-loads the core purpose and scoping, then details parameters. Efficient for its depth.

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 the tool's complexity and the absence of schema descriptions and annotations, the description is complete. It explains what it returns (aps table, frames, pcap_path), how to retrieve the pcap, prerequisites, and caveats. The presence of an output schema (though not shown) means the return format is covered, and the description adds the needed context for selecting and calling 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%, so the description must compensate, and it does. Each parameter is explained: session_id (session to attach), interface (monitor-mode interface alternative), duration_s (1-60, blocks), and max_frames (cap behavior including 0 and negative values). This adds meaning well beyond the schema's bare titles.

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 tool watches an existing streaming capture read-only, never starts/reconfigures/stops it, and differentiates from capture_scan by explicitly saying 'Returns the same dissected summary as capture_scan' while emphasizing the subscriber role. The purpose is specific and distinguishes from siblings like list_capture_sessions and capture_scan.

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 provides explicit usage guidance: 'Use list_capture_sessions first if you want to see what is running,' explains the session_id vs interface alternatives, and mentions the blocking duration. It also implies the alternative capture_scan for starting a new capture. The single-radio caveat adds important context for when to expect incomplete coverage.

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 takes full responsibility for behavioral disclosure—and it excels. It states that the call blocks for duration_s, that the capture stops before returning, that the raw pcap is saved to device, that results may be partial if channel_issues occur, and how the owner/subscriber modes work. These are behavioral traits the agent could not infer from the schema, and they are clearly spelled out.

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 long but every sentence carries weight: differentiation, blocking behavior, result structure, ownership semantics, radio caveats, parameter guidance, and performance warnings. It is well-segmented with clear sections and front-loads the core purpose before diving into details. There is no filler or repetition of schema information.

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?

Despite having an output schema (which reduces the need to explain return values), the description still previews the result structure ('aps', 'frames', 'frame_types') and key fields, covering a busy capture scenario. It addresses all 7 parameters, caveats, and edge cases (subscriber mode, channel issues, long captures). For a tool of this complexity—streaming capture, multiple return bodies, external file artifact—this is 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 coverage is 0%, so the description compensates fully. Every parameter—interface, channels, width, dwell_ms, duration_s, pcap_filter, max_frames—gets meaningful context: allowed ranges, defaults, behavior (e.g., max_frames=0 skips per-frame records, negative means no cap), and relationships to other parameters. This is exactly the kind of semantic depth an agent needs to pick correct values.

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 pair: 'Run a live streaming Wi-Fi packet capture and return what was on the air.' It clearly distinguishes from sibling 'scan_wlan' by noting the difference between off-air capture and driver-requested scans. This precision leaves no ambiguity about what the tool does.

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?

Explicit guidance covers when to use this tool vs. scan_wlan (streaming vs. driver scan), when to switch to file-capture tools for captures longer than 60s, and when to use pcap_filter to avoid beacon dominance. It also warns about single-radio channel-change failures and explains the owner/subscriber behavior, giving the agent clear selection and invocation conditions.

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 must carry the behavioral disclosure burden. It adds useful context such as persistence ('saved'), creation of a new profile, and uniqueness restrictions on the id. However, it does not mention side effects (e.g., whether the profile auto-activates), error behavior on duplicate ids, or permission requirements. This is a moderate gap for a mutation 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 well-structured and every sentence earns its place. It front-loads the core purpose, then uses bullet lists for required fields and interface config requirements, followed by a concise Args section. Despite its length, it is information-dense without redundancy, appropriate for the complexity of the nested config object.

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 description provides sufficient guidance for constructing the config parameter, and an output schema exists so return value details are not required. It still lacks behavior notes about duplicate handling or activation side effects, but for the core task of invoking the tool with a valid config, it is complete enough. The presence of a nested schema would be ideal, but the prose covers it well.

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 input schema only declares an opaque 'config' object with additionalProperties true and 0% description coverage. The description fully compensates by enumerating required top-level keys (id, namespaces, roots), their optionality, and the nested structure for interface configs with modes and security details. This adds substantial meaning beyond the schema and gives the agent everything needed to construct a valid config.

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 tool creates a new saved network configuration profile, using a specific verb and resource. It distinguishes itself from sibling tools like update_network_config, activate_network_config, and delete_network_config by emphasizing 'new' and 'saved', so an agent can select the right operation without inspecting other definitions.

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 clear context: it is for creating a new saved profile and includes constraints like id cannot be 'root' or 'default'. However, it does not explicitly name alternatives or when to use update/activate instead, so while the context is clear, there are no exclusions or alternative routing instructions.

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 explicitly states the tool can replace an existing VLAN, and it discloses the constraint that interface cannot be 'all'. It does not mention side effects on existing addresses or permission requirements, but the replacement behavior is a key trait that is disclosed. This is a strong disclosure for a mutation 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 well-organized: a one-sentence purpose, followed by a clearly labeled Args section. It is concise and front-loaded. The Args section is necessary given zero schema coverage, so the length is justified. No filler.

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 description covers the essential parameters and the replacement behavior. It does not explain the return value, but an output schema exists, so that is not required. It also doesn't specify error handling or whether addresses are fully replaced or merged, which could matter, but overall it is complete enough for an agent to call it correctly.

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%, so the description must fully document parameters. It does: interface with an example and the 'all' constraint, vlan_id with range (1-4094), and addresses with a complete structure including family, local, prefixlen, and an example dict. This goes well beyond the schema's bare type definitions.

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 clear verb–resource pair: 'Create (or replace) a VLAN on an ethernet interface.' It also specifies the replacement behavior, distinguishing it from sibling tools like get_vlans and delete_vlan. This is specific and unambiguous.

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 usage—creating or replacing a VLAN—but does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or preconditions. The constraint 'Cannot be all' is given, but there is no guidance on when to use get_vlans or delete_vlan instead. This is adequate but leaves the agent to infer usage context.

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 must carry the behavioral disclosure burden. It does reveal that deactivation can be forced via override_active and that there is an 'active' flag that may otherwise block the operation. However, it does not state side effects (e.g., network disruption), prerequisites, or error conditions, leaving important behavioral aspects undisclosed.

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 concise and front-loaded: one clear action sentence followed by a compact Args block. Every sentence adds value, with no redundant or filler content.

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 simple two-parameter mutation with an existing output schema, the description covers the core purpose and parameters. However, it lacks context about consequences of deactivation (e.g., connectivity impact), prerequisites, and how this ties into the broader config lifecycle, leaving an agent to guess at operational impact.

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%, so the description's Args block is the sole documentation for parameters. It clearly defines id as the configuration profile ID to deactivate and explains the override_active behavior. This provides actionable meaning beyond the bare schema titles, though it could mention how to obtain the ID.

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 action ('Deactivate') and a specific resource ('currently active network configuration profile'), clearly distinguishing it from sibling tools like activate_network_config, create_network_config, or delete_network_config. The purpose is unambiguous and immediately actionable.

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 'currently active' and the override_active parameter imply when this tool should be used (on active profiles requiring deactivation), but there is no explicit guidance on when not to use it or how it relates to alternatives such as delete_network_config. The context is clear enough to infer the intended use, but exclusions are missing.

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 usefully reveals that force allows deletion of an active profile, which is a key destructive nuance. However, it does not state whether deletion is permanent, how it affects dependent configuration, or what happens when the ID does not exist.

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 core purpose, followed by a clear Args block. Every sentence adds useful information without repetition or fluff.

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 simple destructive tool with an output schema, the essential details for a basic call are present: the target id and the force behavior. A note on reversibility or error handling would improve completeness, but nothing critical is missing for correct invocation.

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%, but the description meaningfully documents both parameters: id as the profile identifier and force as allowing deletion of an active profile. This compensates for the bare schema titles, though the id format is left unspecified.

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 first sentence names a specific verb ('Delete') and resource ('saved network configuration profile'), making the tool's purpose immediately clear. It distinguishes itself from siblings like delete_vlan and deactivate_network_config without requiring schema inspection.

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 is given on when to use this tool versus siblings such as deactivate_network_config or update_network_config. The force parameter hint addresses a specific deletion scenario but does not route the agent to alternatives or explain when deletion is appropriate.

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 disclose the error behavior for missing VLANs via allow_missing and the interface constraint, but it does not mention potential failure modes (e.g., VLAN in use) or permissions. This is adequate but not comprehensive.

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, front-loaded with the action, and lists parameters in a clear Args block with no superfluous text. Every sentence contributes to understanding the tool's purpose and usage.

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 the tool's simplicity and the presence of an output schema (which handles return values), the description covers the essential behavior and parameter semantics. It does not address edge cases like non-existent interfaces, but these are less critical for a straightforward delete operation. The tool appears complete for its scope.

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%, so the description must explain parameters. It does so for all three: interface includes an example and a constraint, vlan_id is straightforwardly defined, and allow_missing explains its effect on error behavior. This adds meaning beyond the bare schema, though vlan_id's explanation is 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 states a clear verb+resource: 'Delete a VLAN from an ethernet interface.' This immediately distinguishes it from siblings like get_vlans (read) and create_vlan (add) based on the action. The resource is specific and the operation is unambiguous.

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 usage through the action verb and parameter constraints (e.g., interface cannot be 'all'), but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. Since the sibling names make the purpose obvious, it meets the 'implied usage' bar but not a higher one.

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 full burden of behavioral disclosure. It states the action but does not mention whether the change is persistent, whether it overrides existing timezone settings, requires special permissions, or can be reverted.

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 wasted words. The key action and target are front-loaded and immediately actionable.

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 simple zero-parameter enable action, the description is mostly adequate, and an output schema exists. However, it lacks context about side effects, persistence, or what success looks like, which an agent might need when deciding whether to invoke this 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?

The tool has zero parameters, so no parameter semantics are needed. The description correctly focuses on the action rather than redundant parameter 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 clearly states a specific verb ('Enable'), resource ('NTP automatic time synchronization'), and target ('WLAN Pi'). It is unambiguous and easily distinguished from sibling tools like set_timezone, which manually configures a timezone rather than enabling automatic synchronization.

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 is provided about when to use this tool versus alternatives such as set_timezone or get_timezone. The description implies usage for enabling NTP but does not state conditions, prerequisites, or 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, the description carries the full behavioral disclosure burden. It discloses the binary/mime type, the partial-data behavior when the capture is still running, and the safety restriction that only files under the managed capture directory are readable. It could also mention error behavior for missing captures, but the output schema likely covers the return format.

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 well-structured and front-loaded: the first sentence states exactly what the tool does, followed by return format, timing caveat, safety restriction, and an organized Args section. Every sentence adds operational value with no filler.

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 description covers the essential operational context: return type, when to call, partial results, path safety, and parameter sources. The main gap is that the schema marks all three parameters as optional, and the description does not explicitly state that exactly one of capture_id/path/session_id must be supplied, or what happens if multiple are provided.

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%, so the description must fully explain the parameters, and it does. It explains capture_id as coming from start_pcap_file/list_pcap_files, path as an alternative on-device path within the managed directory, and session_id as a deprecated alias. This adds substantial meaning beyond the bare schema properties.

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 precise verb and object: it fetches a non-streaming capture's pcapng file as a binary blob. It distinguishes itself from sibling tools like start_pcap_file, stop_pcap_file, and list_pcap_files by focusing on retrieving the raw capture file content rather than managing capture sessions.

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 clear usage context: fetch after the capture has stopped for a complete file, and note that fetching a running capture returns partial bytes. It also clarifies that capture_id is preferred over path. It does not explicitly name alternatives or exclusions, but the timing and parameter-preference guidance are clear enough for an agent to decide correctly.

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 explains the key conditional behavior (hardware without battery returns 'present': false) and the expected data (capacity percentage and charging status). It does not over-explain, but it is transparent about the core behavior.

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 sentences with no filler. It front-loads the main purpose, then succinctly adds the hardware behavior and return 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?

For a simple, parameterless getter with an output schema, the description is complete. It tells the agent the scope, the no-battery fallback, and what the returned values represent. Nothing needed to invoke the tool correctly 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?

The tool has zero parameters, so parameter documentation is not needed. The description still clarifies that no arguments are required and defines what the response covers, which aligns with the baseline for no-parameter tools.

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 and resource ('get battery status'), and further scopes it to WLAN Pi models with a battery. It clearly differentiates the tool's purpose from the many other getter tools by defining what hardware it applies to and what it returns.

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 clear usage context: it is for battery status on battery-capable WLAN Pi models)Skip, and it notes that on hardware without a battery it returns 'present': false. It does not explicitly contrast with alternatives, but the resource is so distinct that no alternative routing is necessary.

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 provided, so the description carries the burden. It states the tool checks status but does not explicitly disclose that it is a read-only operation or any side effects. The name 'get' and the wording imply a non-destructive read, but it is not stated.

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, concise sentence with no unnecessary words.

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 no parameters and an output schema present, the description covers the tool's purpose sufficiently. The output schema handles return value details.

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?

No parameters exist, so the description adds no parameter information beyond the empty schema. 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 action (check) and resource (Ethernet port blinker) and its state (running). It distinguishes from start_blinker and stop_blinker by focusing on status.

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 explicit guidance on when to use this tool versus alternatives, but the status-check nature implies usage when you need to know if the blinker is running. Does not mention alternatives or 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?

No annotations are provided, so the description carries the behavioral burden. The verb 'Get' and the list of returned fields clearly indicate this is a read-only operation with no apparent side effects. It could additionally mention that it does not modify state, but the description is sufficient for a getter.

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 concise sentences with no filler. The main action is front-loaded, and the output contents are listed efficiently without redundancy.

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 zero parameters, no annotations, and an output schema present, the description fully covers what an agent needs to select and invoke this tool. It names the resource, lists the key output fields, and leaves return-value formatting to the output schema.

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 zero parameters, so the description does not need to explain parameter semantics. The baseline for no-parameter tools is 4, and the description appropriately provides no parameter-related information.

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 and resource, 'Get Bluetooth adapter status,' and further specifies what is included: adapter name, address, power state, and paired devices. This clearly differentiates it from other status getters and Bluetooth-related siblings like set_bluetooth_power and start_bluetooth_pairing.

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 this tool is for reading current Bluetooth adapter state, but it does not explicitly state when to use it over alternatives or when not to use it. For a simple zero-parameter status getter, the intended use is reasonably inferable, but there is no direct usage routing.

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 explains that results are namespace-aware, come from the adapter's own radio, reflect the regulatory domain, and describes the output format including the 6 GHz channel-number caveat. This is strong, non-obvious behavioral context.

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: the first sentence states the core purpose, the second adds defining details, and the third gives usage guidance plus an output note. Every sentence earns its place, with 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?

For a zero-parameter query tool, the description is complete: it identifies the adapters, explains the regulatory/namespace behavior, describes the returned fields, and tells the agent how to use the results with capture_scan. An output schema exists, so detailed return-structure documentation is not the description's burden.

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 no parameters, so the baseline is 4 and there is nothing to document. The description adds value by mapping the output semantics to the 'interface' and 'channels' arguments of capture_scan, which helps an agent understand how the result will be used downstream.

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 ('List'), a specific resource ('channels each capture adapter can tune to'), and clarifies that capture adapters are monitor-mode interfaces named 'wlanpiN'. This clearly distinguishes it from sibling tools like capture_scan or get_wifi_regulatory by narrowing the exact scope.

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 says to use this tool to pick the 'interface' and 'channels' arguments for capture_scan, giving clear contextual guidance. It does not explicitly state when not to use it or name alternatives, but for a zero-parameter informational query this is sufficient context.

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 burden of behavioral disclosure. It states that the operation returns the current local date, time, and timezone, which is a read-only operation. It doesn't mention any side effects, but for a simple getter there are none. The description adequately conveys the expected behavior.

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?

A single, direct sentence with no filler. The core purpose is front-loaded and every word adds value. It is the ideal level of conciseness for a parameterless getter.

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 the tool has no parameters, an output schema exists (so return format is handled there), and the operation is straightforward, the description is complete. An agent has everything needed to invoke this tool correctly without additional 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?

The tool has zero parameters, so the description doesn't need to explain parameter usage. The baseline for a no-parameter tool is 4, and the description adds nothing beyond the schema, but there's nothing to add. The description is consistent with the empty 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 ('Get'), a specific resource ('WLAN Pi's current local date, time, and timezone'), and clearly enumerates the returned fields. It distinguishes itself from the sibling get_timezone by including date and time, so an agent can tell them apart without inspecting schemas.

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 clearly implies when to use it (when you need the full local date/time/timezone combination) but does not explicitly mention alternatives or when not to use it. Given the sibling get_timezone exists, explicit exclusion would be helpful, but the context is still clear enough for correct selection.

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 bears full responsibility for disclosing behavior. It states the operation is a 'Get' (implying read-only) but does not explicitly confirm no side effects, no special permissions, or any latency concerns. It also does not mention error handling or that it aggregates multiple sources, leaving behavioral traits unspecified.

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, front-loaded sentence that states the action and resource first, then lists the specific fields. There is no fluff or redundancy; every word contributes to the tool's 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 parameterless tool with an existing output schema, the description fully specifies what the agent can expect: model, hostname, software version, and operating mode. This covers the tool's intended scope without missing essential details. The output schema handles return formatting, so the description is 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?

There are zero parameters, so the schema trivially covers 100% of them. The description adds no parameter-specific information, but none is needed. The baseline for a 0-parameter tool is 4, which applies 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?

The description clearly states the action 'Get' and the resource 'WLAN Pi device identity', then enumerates the specific attributes returned (model, hostname, software version, operating mode). This distinguishes it from siblings like get_device_model and get_device_mode, which are more granular, making the purpose unambiguous.

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 is given on when to prefer this combined tool over the granular get_device_model or get_device_mode, nor any exclusion criteria. The description implies a one-stop query for identity, but it does not explicitly state when this is the better choice or when to use alternatives.

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. It states it returns a value (the current mode) and lists the valid values, which is useful. However, it doesn't disclose anything about side effects (likely none for a getter), return format details, or edge cases like what happens if the mode is unknown or unavailable. With no annotations, a bit more about the read-only nature could be stated, but the description is reasonably transparent for a simple getter.

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 sentence that is concise and front-loaded with the action ('Get'), the resource ('current WLAN Pi operating mode'), and the enumerable values. Every word earns its place; no fluff or redundancy.

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 getter with an output schema, the description is nearly complete. It names the exact values that can be returned, which is the main thing an agent needs to interpret the result. It could potentially mention whether the mode is retrieved from a config file or runtime state, but that's not necessary for a correct call. The output schema is present, but the description's enumeration of values adds enough 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?

The tool has zero parameters, so the schema is trivially complete. The description's mention of the possible return values ('classic, wconsole, hotspot, wiperf, server, bridge') adds semantic meaning about what the mode values mean, going beyond the empty schema. This is a case where the description compensates for the lack of parameter information by clarifying the result domain.

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 and resource: 'Get the current WLAN Pi operating mode' and enumerates the possible mode values. It distinguishes this from sibling tools like get_device_info or get_device_stats by focusing specifically on the operating mode. It could be more explicit about what a mode means operationally, but the core purpose is clear.

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 – when you need to know the current operating mode of the device. It doesn't explicitly state when not to use it or name alternatives, but among the large sibling list, get_device_info and get_device_model are candidates that could overlap; no exclusion is given. The context is adequate but not fully explicit.

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. It indicates a read-only 'Get' operation and gives example return values, which is helpful. However, it does not disclose potential error cases, return format, or any device-specific quirks beyond the examples.

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?

A single, focused sentence that front-loads the verb and resource and adds useful examples. There is no wasted text 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?

For a zero-parameter getter with an output schema present, the description is fully sufficient. It states exactly what is retrieved and gives representative values; nothing else is needed to call the tool correctly.

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 takes zero parameters, so the default baseline of 4 applies. There is nothing to explain about parameter semantics, and the schema coverage is trivially complete.

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 the specific verb 'Get' with a clear resource, 'WLAN Pi hardware model', and provides concrete examples ('WLAN Pi Pro, R4, M4'). This precisely identifies what the tool returns and distinguishes it from sibling getters like get_device_info or get_device_stats.

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 clearly implies the usage condition: use this tool when the WLAN Pi hardware model is needed. While it does not name alternative tools or explicitly exclude them, the purpose is so specific that selection among the many getter siblings is unambiguous.

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 behavioral disclosure. It communicates that this is a live read operation and lists what it returns, but it does not explicitly state side-effect-free behavior, permissions needed, or failure characteristics.

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, front-loaded sentence with no filler. Every clause contributes either the action, the scope, or a concrete returned metric.

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 with an output schema present, the description is complete: it names the resource and fully enumerates the metrics returned. There are no parameter or return-value ambiguities left for an agent to resolve.

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?

There are zero parameters, so the schema already fully covers this dimension. The description adds value by clarifying what data the tool returns, which is sufficient for an agent to invoke it correctly.

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 ('Get'), names the resource ('WLAN Pi live system metrics'), and enumerates the exact metrics returned. It is clear, though it does not explicitly distinguish itself from similar get_device_info or get_device_model siblings.

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 usage when live system metrics are needed, but it gives no explicit when-to-use guidance, exclusions, or alternatives. An agent must infer when this tool is more appropriate than other get_* 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?

With no annotations, the description carries the burden of behavioral disclosure. It does reveal that leases are parsed from local dhclient lease files, which is useful context beyond the tool name. It does not state side-effect-free behavior or edge cases, but for a simple read operation the source disclosure provides moderate 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?

The description is a single, efficient sentence with no filler. It front-loads the primary action and resource, then adds the source detail in a parenthetical. Every word 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?

The tool has no input parameters and an output schema is present, so the description does not need to explain return values or parameter usage. The source of the leases is stated, making the definition complete for an agent deciding to call this 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?

The tool has zero parameters, so the baseline is 4. The description adds context about where the data comes from, but no parameter-specific semantics are needed since the input schema is empty.

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 verb and resource: 'Get DHCP leases held by the WLAN Pi'. It also adds a distinguishing detail about the data source ('parsed from dhclient lease files'), which clearly separates it from sibling tools like renew_dhcp_lease.

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 intended use is implied by the tool name and description: use it to read currently held DHCP leases. However, it does not explicitly state when to use this instead of related tools such as renew_dhcp_lease, nor does it provide exclusions or alternatives.

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 itself must convey behavioral traits. 'Get' implies a read-only operation, and the special 'all' value is disclosed, which is useful. But the description does not explain error behavior, output shape, or what 'details' includes; the burden falls on the output schema.

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 short, front-loaded with the purpose, and adds only the essential parameter explanation. Every sentence contributes value, with no redundancy or filler.

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 one-parameter getter with an output schema, the description is largely complete: it explains the parameter and the special 'all' option. It could be more complete by noting how to distinguish this from get_network_interfaces or what happens for invalid interface names, but those are minor gaps.

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%, so the description fully compensates: it explains that 'interface' is an Ethernet interface name, provides a concrete example ('eth0'), and documents the special value 'all'. This is precisely the semantic content an agent needs 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 clearly states a verb and resource: 'Get ethernet interface details for a specific interface.' It is unambiguous about scope, but it does not explicitly distinguish itself from sibling tools such as get_network_interfaces or get_interface_link_stats, relying mostly on the tool name and the word 'specific.'

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 usage: use it to get details for a named interface, or pass 'all' for every interface. However, it gives no explicit when-to-use or when-not-to-use guidance, and it does not mention alternative tools that might serve overlapping purposes.

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 must carry behavioral disclosure. It discloses a key behavior—returning an error if not in hotspot mode—and 'Get' implies a read-only operation. However, it does not explicitly state side effects, permissions, or rate-limit implications, leaving some burden unmet.

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 lines of purpose plus a one-line argument explanation. It is front-loaded with the operational purpose and error condition, with no filler or repetition of schema details.

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 an output schema exists, the description need not explain return values. It covers purpose, the single optional parameter, and an important error condition. For a low-complexity tool, this is nearly complete; only a slightly clearer definition of 'client count' (e.g., current active vs. total associated) is absent.

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 for the single parameter. It does so by explaining 'iface' as an optional AP interface name and noting auto-detection when omitted, which gives meaning beyond the raw schema. It stops short of providing format examples or common values, so it is helpful but not exhaustive.

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 ('Get') and resource ('connected client count') with a clear context ('hotspot mode'). This makes the tool's purpose immediately distinguishable from the sibling get_hotspot_stations, which would provide station details rather than a count.

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 clear usage context: the tool is for hotspot mode and explicitly returns an error if the device is not in that mode. It does not name alternative tools or conditions for when the count would be less appropriate, but the error condition effectively communicates when not to call it.

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 disclosure burden and does disclose the key error condition (device must be in hotspot mode) plus what the tool reports. It does not add details on read-only behavior, but the name and wording make that inferable.

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, no filler; the purpose is first, followed by output details and the key limitation. Every sentence adds usable information.

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 tool with one optional parameter and an output schema, the description is complete. It covers scope, returned metrics, the failure mode, and parameter behavior, leaving no gap an agent needs before calling it.

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 single parameter iface is explained beyond the schema: it is an optional AP interface name and is auto-detected if omitted. This fully compensates for the 0% schema description 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?

States a specific verb 'Get' and resource 'per-station link statistics for hotspot AP clients,' and names the concrete data reported (signal, rates, retries). This clearly distinguishes it from generic interface-stat tools like get_interface_link_stats.

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?

Describes the intended scope: hotspot AP clients. The error-if-not-in-hotspot-mode statement tells the agent when the tool is not applicable, though it does not explicitly name a sibling alternative for non-hotspot cases.

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 states that the tool reads from hostapd configuration (indicating a read-only operation) and returns an error if the device is not in hotspot mode, which are the key behavioral traits an agent needs. It could go further by explicitly stating 'does not modify any settings,' but the read-from wording sufficiently conveys the non-destructive nature.

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 sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the second sentence adds an important behavioral constraint. 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 zero-parameter getter with an output schema, the description is complete. It states exactly what is returned, identifies the source, and covers the key error condition. An agent has everything needed to invoke this tool correctly, and the output schema covers return formatting details.

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?

There are zero parameters, so the schema complexity is minimal and schema coverage is trivially 100%. Per the rubric, a zero-parameter tool gets a baseline of 4. The description does not need to add parameter details because there are none, and it does not attempt to invent any.

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 ('Get') and resource ('hotspot SSID and WPA passphrase'), clearly stating what the tool returns. The second sentence adds the data source (hostapd configuration), which further differentiates it from sibling hotspot tools that fetch clients or link stats. This is precise and unambiguous.

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 clear context for when the tool is usable: it reads from the hostapd configuration and errors if the device is not in hotspot mode, implying this is the tool to use when hotspot credentials are needed. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full explicit guidance.

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 does disclose an important behavior: the tool errors when the device is not in hotspot mode, and it notes that iface is auto-detected when omitted. However, it leaves the read-only / no-side-effect nature implicit rather than stating it explicitly.

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 three short, purposeful sentences with the main action front-loaded. The parameter explanation is compact and useful, with no filler or redundancy.

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 simple getter with one optional parameter and an output schema, the description covers the purpose, the key error condition, and parameter behavior. The main remaining gap is the lack of positioning relative to the similarly named get_hotspot_clients, but this does not prevent a competent agent from invoking the tool correctly.

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 compensates well by defining iface as an optional AP interface name and explaining that it is auto-detected if omitted. This adds meaningful semantic information beyond the schema's generic string/null type and default null.

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 and resource ('List stations connected to the hotspot AP interface'), so the core purpose is clear. However, it does not differentiate itself from the sibling tool get_hotspot_clients, whose name suggests a very similar or overlapping function.

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 the intended context by stating that an error is returned when the device is not in hotspot mode, which tells the agent this tool is only relevant in hotspot mode. But it gives no explicit when-to-use guidance and does not mention any alternative such as get_hotspot_clients.

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 full burden of disclosing behavior. It does not explicitly state that the operation is read-only, require special permissions, or describe error behavior for invalid interfaces. The reference to ethtool hints at a system command but no concrete behavioral traits are disclosed.

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 extremely concise: one leading sentence states the purpose and expected output, followed by a one-line argument explanation. No redundant wording or extraneous information is present.

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 simple one-parameter read-only tool with an output schema, the description covers the core purpose and parameter adequately. However, it omits any error or edge-case context (e.g., invalid interface handling) and does not mention the output format, though an output schema exists. Overall, it is sufficient for a basic retrieval 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?

The schema provides only the parameter name 'interface' with no description (0% coverage). The description adds a helpful example ('eth0') and clarifies it is an interface name, but it does not specify constraints, format beyond an example, or behavior for nonexistent interfaces. This partially compensates for the schema gap.

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 tool gets per-interface link statistics via ethtool, listing specific metrics (speed, duplex, errors, drops). This verb-resource combination distinguishes it from siblings like get_hotspot_link_stats and get_network_interfaces.

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 is provided about when to use this tool versus alternatives. There is no mention of preferred conditions, exclusions, or related tools such as get_hotspot_link_stats for wireless links, leaving the agent to infer usage 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?

With no annotations, the description must carry behavioral disclosure. 'Get' implies a read-only operation and 'full details of a saved network configuration' clarifies scope. However, it does not explicitly state side-effect-free behavior, error cases, or other behavioral details, though the output schema likely covers return structure.

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 front-loaded sentence followed by a minimal parameter note. Every element adds value, with no redundant or filler 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?

For a one-parameter lookup tool with an output schema available, the description provides enough context: what the tool does, how to obtain the required ID, and what kind of result to expect. No critical information 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 0%, but the description fully compensates by explaining that 'id' is a configuration profile ID and directs the agent to list_network_configs to obtain valid values. This is complete and actionable for the only parameter.

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 operation ('Get'), the resource ('network configuration'), and the selection mechanism ('by ID'). It is distinct from siblings like list_network_configs and get_network_config_status by emphasizing 'full details of a saved network configuration.'

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 clear usage context: fetch a specific saved configuration using its ID. It also points to list_network_configs to discover valid IDs, which is useful routing information, though it does not explicitly discuss when not to use this tool versus specific sibling getters.

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 is the sole source of behavioral disclosure. It implies a read-only operation via 'Get' but does not explicitly state non-destructiveness, permissions, or return format. The minimal wording is adequate but lacks explicit safety or side-effect information.

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 redundant words. It front-loads the key action and adds the distinguishing detail about active status. Perfectly structured for quick comprehension.

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 the presence of an output schema and no parameters, the description covers all essential calling information. It does not need to explain return values because the output schema handles that. The description is complete for a parameterless status query.

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 zero parameters, so the schema already fully covers parameter needs. According to the rubric, 0 params yields a baseline of 4. The description adds no parameter-related value, which is appropriate 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?

The description clearly states the tool retrieves the status of all saved network configurations and highlights which is active. This is a specific verb-resource pair that distinguishes it from siblings like list_network_configs (which likely just lists) and get_network_config (which targets a single config).

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 usage for status checking but does not explicitly contrast with alternatives such as list_network_configs or get_network_config. No exclusions or conditions are given, leaving the agent to infer when this tool is the right choice.

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. As a read-only information getter, it has no side effects, but the description does not mention potential performance cost of gathering a 'full snapshot' or any permissions required. It accurately lists what data is returned but adds no extra behavioral context beyond that. Adequate but not rich.

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 sentences with zero fluff. The first sentence delivers the core purpose, the second lists the scope, and the third gives usage guidance. All information is front-loaded 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?

The tool is complex in scope but the description clearly enumerates the covered areas. An output schema exists, so return format is documented elsewhere. The only missing context is any mention of prerequisites or potential performance caveats, but that is minor for a read-only diagnostics snapshot. The description sufficiently equips an agent to decide when to call it.

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?

Tool has zero parameters, so schema description coverage is trivially 100%. There is nothing for the description to add about parameters. According to the baseline rule for 0 params, a score of 4 is appropriate, and the description correctly focuses on output content rather than input.

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 verb ('Get') and a specific resource ('full network snapshot'), then enumerates the exact content (interfaces, WLAN, ethernet IP, VLAN, LLDP/CDP, public IP). Clearly distinguishes itself from more granular siblings like get_network_interfaces and get_vlans by framing itself as the comprehensive umbrella tool.

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?

Explicitly says 'Best starting point for network diagnostics', which gives clear context for when to use this tool (initial broad assessment). It doesn't explicitly name alternatives or when not to use it, but the 'best starting point' phrasing strongly implies that more specific tools are for follow-up queries, so usage guidance is present though not exhaustive.

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 full burden. It communicates the optional-interface behavior and the kind of data returned, but it does not explicitly state that the operation is read-only or that it has no side effects. For a simple getter, this is a modest gap rather than a severe one.

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 short, front-loaded with the main purpose, and every sentence earns its place. The Args section adds useful parameter context without unnecessary 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 tool with one optional parameter and an output schema present, the description is largely complete: it covers the parameter, default behavior, and the kind of payload returned. It is only missing explicit read-only assurance and sibling differentiation, which are partially captured in other dimensions.

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 schema has 0% description coverage and only a bare 'interface' property, but the description compensates well by naming the parameter, giving an example ('eth0'), and explaining the omission behavior. This is meaningful semantic value beyond the structured 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 clearly states the action ('Get') and resource ('network interface details'), and it enumerates actual content: IP addresses, flags, MTU, and link state. It is specific enough to distinguish from many siblings, though it does not explicitly name differentiating 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 description gives parameter-level guidance (optional interface name; omission returns all interfaces) but provides no guidance about when to use this tool versus closely related siblings like get_ethernet_interface, get_network_info, or get_interface_link_stats. No exclusions or alternative routing 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?

With no annotations, the description carries the full burden, and it does disclose the key behavior: it is a read-only status query reporting whether the profiler is running plus SSID, channel, and interface. It does not explicitly state 'no side effects,' but the 'Get'/'Returns' language makes the non-mutating nature clear.

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 sentences: the first states the action, the second lists the returned values. There is no filler or redundancy, and the most important information is front-loaded.

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 status getter with an output schema available, the description covers everything an agent needs to know to call it correctly. The lack of usage guidance is the only gap, but it does not undermine completeness for this simple 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?

The tool has zero parameters and the input schema fully documents that, which is the baseline-4 case. No parameter description is needed, and the description adds no irrelevant parameter detail.

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 ('Get') and a clear resource ('current status of wlanpi-profiler'), then enumerates exactly what is returned: running state, SSID, channel, and interface. This clearly distinguishes it from sibling tools like start_profiler and stop_profiler.

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 alternatives such as get_service_status or the profiler start/stop tools. It neither states preferred contexts nor rules out any sibling, leaving the choice entirely to inference.

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 present, so the description itself must signal behavior. The verb 'Get' clearly implies a read-only operation, which is useful, but the description does not disclose potential network dependency or what 'related details' includes. Since this is a simple getter with no mutation risk, the lack of further disclosure is a modest gap rather than a serious one.

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 front-loaded sentence with no filler or redundancy. Every word contributes to stating what the tool does.

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 parameterless getter with an output schema, the description is nearly complete: it names the exact data being retrieved. The only missing context is situational guidance (e.g., when the device may not have a public IPv6 address), which is a minor gap.

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 zero parameters and 100% schema description coverage, so there is nothing for the description to add about arguments. The baseline of 4 applies because no parameter semantics are needed.

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 specific resource (WLAN Pi's public IPv6 address) and the operation (get), making the core purpose clear. 'And related details' is vague but does not obscure the primary function. It is distinct enough from sibling getters like get_network_info, though it does not explicitly distinguish itself.

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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. An agent must infer from the tool name and the sibling list when this is the correct getter to invoke.

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 full burden of behavioral disclosure. It details the concrete operations performed (ping, DNS check, internet verification) and implies a read-only diagnostic nature, going well beyond a vague label.

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 front-load the core purpose, enumerate behavioral details, and close with an explicit use case. Every sentence earns its place with no redundancy.

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 no-parameter diagnostic tool with an output schema, the description covers what the tool does, how it does it, and when to use it. Nothing necessary for correct invocation 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?

There are zero parameters, so there is nothing for the description to explain beyond the schema. Per the baseline for 0-param tools, this is appropriately handled.

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 action ('Test') on a specific resource ('WLAN Pi network reachability') and immediately lists what the test covers: gateway ping, DNS resolution, and internet access. This makes it easily distinguishable from sibling network diagnostic 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?

Explicitly says to use it 'to diagnose connectivity problems,' giving the agent clear context for when to invoke it. It doesn't name alternatives or exclusions, but the use case is stated directly enough for selection.

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 present, the description carries the behavioral burden. It usefully discloses that the result contains a 'country' value formatted as an ISO alpha-2 code, which aids parsing. However, it does not explicitly state read-only behavior, missing-value behavior, errors, or platform-specific caveats.

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 concise sentences with no filler. The action, target, and return format are presented directly and the most important information appears first.

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 parameterless getter, the description is minimally sufficient: it states the purpose and the format of the returned country code. However, the existence of closely related sibling tools creates selection ambiguity that the description does not resolve, and the output schema alone does not compensate for that gap.

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 takes zero parameters and the schema is empty, so there are no parameter semantics to explain. The baseline of 4 applies because nothing about parameters remains undocumented.

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 a specific action ('get') and resource ('current Wi-Fi regulatory domain'), and it specifies the return value as an ISO 3166-1 alpha-2 country code. It does not, however, distinguish this tool from the similarly named sibling get_wifi_regulatory.

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 alternatives such as get_wifi_regulatory or set_regulatory_domain. The phrase 'get current' weakly implies a read operation, but no exclusions or selection criteria are provided.

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 must carry the full burden of behavioral disclosure. It only states the basic action and does not mention side effects, permission requirements, error behavior, or whether the namespace parameter affects output in a surprising way. The word 'structured' hints at output format but is not a 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?

The description is extremely concise, front-loaded with the main purpose, and contains no filler. The Args section is compact and provides the essential parameter detail in a clear format.

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 output schema exists, so return values do not need to be described. However, the description lacks any context about when to use this tool and gives no behavioral safety cues (e.g., explicitly confirming it is read-only). For a simple getter with one optional parameter, it is mostly adequate but still leaves gaps in usage and 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 0%, so the description must compensate. It does: 'namespace: Optional network namespace to query (default: root namespace)' explains the parameter's purpose, optionality, and default value. This is sufficient for the single parameter, though it could add format examples or validation rules.

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 a specific verb ('Get') and a specific resource ('structured IP routing table'). This distinguishes it from sibling tools like get_network_info or get_tcp_connections, which target different data, even without explicitly naming them.

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, nor any exclusions or prerequisites. An agent must infer usage purely from the tool name, since no context is given about scenarios where this tool is the right choice.

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 says 'Get the running status,' which implies a read but does not explicitly state that the operation has no side effects or what states the status can take. It does not contradict annotations, but adds minimal behavioral context beyond the tool name itself.

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 sentences, front-loads the purpose, and adds one parameter note, with no wasted words. 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 simple one-parameter tool with an output schema, the description covers the essential selection and invocation needs. It could be slightly more complete by describing possible status values or confirming no side effects, but the provided context is mostly 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 0%, so the description must compensate, and it does. It clearly defines 'name' as a service name and, crucially, tells the agent to use list_allowed_services to obtain valid values, which is exactly the information needed to call the tool correctly.

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 and resource: 'Get the running status of a WLAN Pi service.' This is specific enough to distinguish it from service-management siblings like start_service and stop_service, though it does not explicitly differentiate it from other status-style getters such as get_profiler_status or get_blinker_status.

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 useful parameter guidance by telling the agent to 'use list_allowed_services to see valid names,' but it does not explicitly state when to use this tool over alternative tools or state any exclusions. Usage context is implied by the getter semantics 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?

No annotations are provided, so the description carries some burden for behavioral disclosure. The verb 'Get' and the qualifier 'active' imply a read-only snapshot of current TCP connections, and the namespace default is stated. However, it does not disclose error behavior for invalid namespaces, permission requirements, or whether listening sockets are included.

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 concise sentences with the core action front-loaded and the parameter explanation kept to a single useful line. Every element earns its place with 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?

Given the tool's low complexity, one optional parameter, and an existing output schema, the description is mostly complete: it names the resource, the protocol, the scope, and the parameter semantics. It could add a brief caveat about namespace validity or output interpretation, but nothing essential 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?

The input schema has 0% description coverage, but the description clarifies the sole parameter as an 'Optional network namespace to query' and states the default behavior ('default: root namespace'). For a one-parameter tool, this meaningfully compensates for the schema gap.

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 ('Get') and a precise resource ('active TCP sockets/connections on the WLAN Pi'). It distinguishes itself from sibling tools like get_udp_connections by explicitly scoping to TCP, so an agent can identify the correct operation without opening schemas.

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 about when to use this tool versus alternatives such as get_udp_connections, get_dhcp_leases, or get_routing_table. It also gives no context on prerequisites, expected conditions, or when not to use it.

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 clearly indicates a read-only operation that retrieves the current system timezone, implying no destructive side effects. Though it does not specify the return format, the presence of an output schema mitigates this gap.

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 that immediately states the tool's purpose. It contains no filler, repetition, or unnecessary detail, earning its place efficiently.

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 parameterless getter, the description is fully adequate to invoke the tool correctly. The presence of an output schema covers return-value details, and no prerequisites or side effects need explanation for such a simple read operation.

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 zero parameters, so there is nothing for the description to explain beyond what the schema already shows. Baseline 4 is appropriate as the description adds no parameter-specific detail because none is needed.

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 verb ('Get'), the resource ('WLAN Pi's current system timezone'), and the scope ('current system timezone'), making its purpose unambiguous. It distinguishes itself from siblings like list_timezones, set_timezone, and get_datetime without further explanation.

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 clear context for use: retrieving the current system timezone from the WLAN Pi. It does not explicitly mention when not to use it or list alternative tools, but the specific phrasing makes the intended use obvious for a tool with zero parameters.

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 burden of behavioral disclosure. It clearly indicates a read-only operation ('Get') and explains the namespace parameter's effect (query a specific namespace, default root). It does not mention potential errors, permissions, or limitations, but for a simple getter this is adequate and adds value beyond the schema.

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 concise: one sentence stating the purpose, followed by a clear Args section. It is front-loaded with the core action and avoids redundancy. Every element contributes to understanding.

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 one optional parameter, and the description adequately explains it. An output schema exists, so return-value details are not required in the description. The description is sufficient for correct invocation, though it does not mention edge cases like invalid namespace values or whether the operation requires special privileges.

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 description explains the sole parameter 'namespace' beyond the schema, clarifying its purpose (network namespace to query) and default behavior (root namespace). The schema itself provides no descriptions (0% coverage), so the description fully compensates and adds meaningful context.

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 a specific action ('Get active UDP sockets') on a defined resource (the WLAN Pi). It is distinct from sibling tools like get_tcp_connections, making its purpose unambiguous.

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 usage when UDP socket information is needed, but it does not explicitly contrast with alternatives (e.g., get_tcp_connections) or provide conditions for when to choose this tool over others. No when-not-to-use guidance is given, so it relies on the agent to infer context.

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 must carry the behavioral burden. It states that it gets status and rules, implying a read-only operation, but it does not explicitly disclose safety (no side effects), permissions required, or any potential impact. For a simple status query this is a minor gap, but the description is minimal.

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?

A single, focused sentence that directly states what the tool does. There is no fluff, and it is front-loaded with the action and resource. Perfectly concise for the tool's simplicity.

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 the tool has no parameters and an output schema exists, the description does not need to explain return values. It fully covers the purpose for a simple status query. It might optionally mention the output format, but the output schema handles that, 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?

The tool has zero parameters, and the schema coverage is 100% (trivially, since there are no properties). The baseline for zero parameters is 4, and the description correctly implies no arguments are needed. There is nothing more to add.

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 ('Get') and resource ('UFW firewall status and active rules'). It clearly distinguishes this from sibling tools like get_service_status or get_device_info by naming the exact firewall component being queried. No ambiguity.

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 context is clear: it's a read-only status query for UFW. There is no explicit alternative mentioned, but among the siblings there is no other UFW-specific tool, so the intended usage is self-evident. It doesn't state exclusions, but for a simple status getter that is acceptable.

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 behavioral disclosure burden. 'List' and 'currently plugged into' signal a read-only, live enumeration, which is helpful. However, it does not describe what happens when no USB adapters are present, whether root is required, or any other runtime behavior beyond the basic listing action.

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, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the tool's action and scope.

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 listing tool with an output schema present, the one-line description is nearly complete. The main shortfall is lack of sibling differentiation, but that is more a usage-guidance gap than a call-completeness gap.

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 zero parameters, so there is no parameter documentation burden on the description. The empty input schema is trivially covered, and the description's focus on the returned resource is sufficient for parameter-related understanding.

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 ('List') and a specific resource ('USB network adapters currently plugged into the WLAN Pi'), making the tool's function clear. It does not explicitly contrast itself with sibling tools like get_network_interfaces or get_wlan_usb_drivers, but the resource scope is specific enough to avoid major ambiguity.

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 alternatives such as get_network_interfaces, get_ethernet_interface, or get_wlan_usb_drivers. The phrase 'currently plugged into' implies live hardware enumeration, but no exclusions or use-case conditions are 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?

No annotations are provided, so the description carries the behavioral burden. It does disclose useful behavior: filtering by interface and VLAN ID, and the default behavior when each parameter is omitted. It does not discuss output format, but an output schema exists to cover that.

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 short, front-loaded with the main purpose, and uses a clean Args section. Every sentence adds useful information with no repetition or padding.

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 simple read-only listing tool with two optional parameters and an output schema, the description is complete. It covers both parameters, their filter semantics, and the fallback behavior when omitted, so an agent has enough to invoke it correctly.

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 fully compensates by explaining both parameters: interface is an Ethernet interface with an example ('eth0'), and vlan_id is a VLAN ID filter. It also clarifies default behavior for each, adding meaning beyond the raw 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 clearly states it gets VLAN interfaces on the WLAN Pi, using a specific verb and resource. It is understandable in isolation, but it does not explicitly differentiate itself from siblings like get_network_interfaces or create_vlan/delete_vlan.

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 on when to use this tool versus sibling tools such as get_network_interfaces or how it relates to create_vlan/delete_vlan. The intended use is only implied by the tool name and parameter descriptions.

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 burden. It discloses that the tool returns 'iw phy' dumps per PHY, which implies a read-only information-gathering behavior, but it does not explicitly state that nothing is modified, mention any permissions/privileges required, or describe error behavior.

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, front-loaded with the action, and no filler. Every phrase adds meaning, especially the concrete list of what the capability dump includes.

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-oriented tool with an output schema, the description covers the key decision-relevant facts: what is returned and from what source. It leaves only minor gaps around side effects and permissions, which are not explicitly disclosed.

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 zero parameters, so there is nothing for the description to add beyond the schema. The baseline 4 applies because parameter semantics are trivially satisfied.

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 ('Get ... capabilities') and names the exact resource ('Wi-Fi adapter'), then enumerates the returned content (bands, channels, HT/VHT/HE features, interface modes). This differentiates it from sibling getters such as get_wifi_regulatory or get_wlan_usb_drivers.

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 intended use is implied by 'Get Wi-Fi adapter capabilities' and the listed return content, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternative siblings. An agent must infer that this is the right tool for capability inspection.

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 transparency burden. 'Get' signals a read operation and 'reported by the kernel' identifies the data source, but permissions, side effects, and limitations are not discussed. For a no-argument read tool, this is adequate but not rich.

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 front-loaded sentence with no filler. Every word contributes: 'Get' states the action, 'Wi-Fi regulatory domain information' states the resource, and 'reported by the kernel' adds a necessary source qualifier.

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 no-parameter getter with an output schema, the description covers the invocation basics. However, it does not differentiate this tool from the similarly named sibling get_regulatory_domain, and the 'kernel' qualifier only partially resolves that ambiguity.

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?

There are zero parameters and schema description coverage is 100%, so there is nothing the description needs to add about inputs. The baseline for a 0-parameter tool is 4, and the description satisfies that 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 names a specific verb ('Get'), resource ('Wi-Fi regulatory domain information'), and source ('reported by the kernel'), so an agent knows what the tool returns. It does not explicitly contrast with the sibling get_regulatory_domain, but the resource and source qualifier make the core purpose clear.

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 statement about when to prefer this tool over get_regulatory_domain, get_wifi_capabilities, or other Wi-Fi-related siblings. No exclusions or alternatives are mentioned, so an agent facing overlapping regulatory-domain tools must infer the intended use.

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 full burden. It adds useful behavioral context by naming the source (lspci) and scope (built-in Wi-Fi radios), and 'List' implies a read-only operation. However, it does not explicitly disclose read-only/no-side-effect behavior or any privileges needed.

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 sentences with no filler. The primary action is front-loaded, and the source/scope clarification earns its place without redundancy.

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 list tool with an output schema, the description is complete. It names the data source, defines the scope, and needs no further elaboration on return values or parameters.

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 zero parameters, so the baseline of 4 applies. The description correctly omits parameter details because there is nothing to document; the empty schema already covers this fully.

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 ('List') with a precise resource ('PCI/platform wireless devices and their bound WLAN drivers'). It clearly distinguishes itself from the sibling get_wlan_usb_drivers by scoping to PCI/platform and built-in radios.

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 clear context ('Comes from lspci, covering built-in Wi-Fi radios') that implies when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the PCI vs USB distinction from sibling naming provides enough guidance.

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, and it does well: it discloses that the output contains an 'adapters' field and an 'interfaces_scanned' field, and it explains the meaning of the empty-adapters case (PCI/on-board radios). The verb 'List' implies read-only behavior)Skip 4 rather than 5 because it does not address failure modes, privilege needs, or the fully-empty case (interfaces_scanned == 0), but the key behavioral nuance is covered.

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, zero filler. The primary purpose is front-loaded, and the second sentence earns its place by teaching the agent how to interpret an edge case and route to the correct sibling. Every word contributes.

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 listing tool with an output schema already documenting return values, the description covers everything an agent needs: what is listed, which radio classes it applies to, and how to interpret the empty-adapters result. Nothing material 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?

The tool has zero parameters)Skip the baseline 4 applies because there is nothing for the description to document. Schema coverage is trivially 100%. The description mentions output fields ('adapters', 'interfaces_scanned') rather than parameters, which is appropriate 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?

Opens with a specific verb ('List') plus the resource ('USB-attached WLAN adapters') and the delivered information ('their bound drivers'). The scoping to USB clearly distinguishes it from its sibling get_wlan_pci_drivers, so an agent can tell them apart from the first sentence 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?

Explicitly names the alternative tool and gives a concrete condition for switching: if 'adapters' is empty while interfaces_scanned > 0, the radios are PCI/on-board and the agent should call get_wlan_pci_drivers instead. This is direct, actionable routing logic with no inference required.

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. The verb 'List' and the qualifier 'can be managed' clearly signal a read-only enumeration with no mutation, though it does not explicitly state side-effect guarantees or response-shape behavior.

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?

A single sentence that front-loads the action and scope, with a parenthetical clarifying the meaning of 'managed.' Every word contributes; there is no filler or redundancy.

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 zero-parameter enumeration tool with an output schema available. The description fully identifies the resource being listed and the operations those services support, which is sufficient for an agent to call it correctly.

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 input schema has zero properties and 100% coverage, so there are no parameters requiring explanation. The baseline of 4 applies since there is nothing for the description to add at the parameter level.

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 and resource: 'List all services that can be managed on this WLAN Pi' and clarifies the relevant operations: 'started, stopped, or queried.' This clearly distinguishes it from service-control siblings like start_service, stop_service, and get_service_status.

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 'services that can be managed... started, stopped, or queried' implies this tool is the discovery step before service-control/status tools, but it does not explicitly name those siblings or state when not to use it. Context is clear, but explicit exclusions and alternatives are missing.

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 behavioral disclosure burden. It reveals meaningful state: each session includes owner, interfaces, namespace, and config, and that a session's interface is exclusive to its owner. It also mentions the read-only alternative. It could have explicitly stated that listing itself has no side effects, but the verb 'List' plus the detail given is strong.

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 sentences with no filler. The main action is front-loaded, the return content is summarized in one compact sentence, and the ownership caveat plus sibling alternative is saved for the final sentence. Every clause 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 zero-argument read-only list tool with an output schema, this description is complete. It says what is listed, what fields are reported, and provides the key behavioral constraint plus the obvious sibling alternative. Nothing essential is missing for an agent to invoke it correctly.

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 zero parameters sensitive_bucket, and schema description coverage is 100%, so the baseline is 4. The description adds value by describing what each returned session contains, which helps the agent interpret results even though no parameter semantics are needed.

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 pairing: 'List the packet captures currently running on this WLAN Pi.' It clearly distinguishes the tool from siblings like list_pcap_files (file listing) and capture_observe (watch a session) by emphasizing active capture sessions in the present tense.

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 establishes clear context: it lists currently running captures, not saved files or scans. It also explicitly routes the agent to capture_observe for read-only observation of a session. It stops short of a full when-to-use/when-not-to-use matrix, so it misses the top score.

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 burden of behavioral disclosure. It usefully states that the return is a dict mapping config ID to active state, but it does not mention edge cases like empty results, error behavior, or whether any implicit filtering or ordering applies.

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 sentences with no wasted words. The primary purpose is front-loaded, and the return format is stated in a concise, useful second sentence.

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 parameterless list tool with an output schema, the description covers the essential behavior and return shape. It is complete enough for an agent to call the tool correctly without needing additional 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?

The tool has zero parameters, and the schema has no properties, so parameter semantics are trivially satisfied. The baseline of 4 applies because there are no parameter details requiring explanation.

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 a specific verb and resource: 'List all saved network configuration profiles.' It distinguishes this tool from siblings like get_network_config or get_network_config_status by emphasizing the 'list all saved profiles' scope.

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 usage: call it when you need to enumerate all saved network profiles. However, it does not explicitly contrast with alternatives such as get_network_config or get_network_config_status, nor does it state when not to use this tool.

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 behavioral burden. It discloses that the list includes captures from an earlier server run with an 'on_disk' status, and enumerates the status values and per-entry fields. This goes well beyond a bare 'list captures' statement and gives the agent useful expectations about behavior.

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 core purpose before adding supporting detail. Each sentence adds value: the first defines scope, the second describes entry contents and related operations, and the third covers edge-case behavior for on-disk files. There is no redundant 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 has no parameters and an output schema, so the description need not explain return values. It provides everything an agent needs to decide when to call it and what the results mean, including statuses, related sibling tools, and the significant on-disk behavior. Nothing essential 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?

The tool takes zero parameters, so the input schema already fully covers parameter semantics. The description adds no parameter details because none are needed. This matches the baseline for a parameterless tool.

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 and resource: 'List the non-streaming, file-backed captures this server has started.' It clearly distinguishes this from streaming capture tools such as list_capture_sessions by explicitly scoping to non-streaming, file-backed captures. It also enumerates exactly what each entry contains.

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 clear context for when the tool is appropriate: enumerating non-streaming, file-backed captures, including active, completed, and on-disk captures. It also names the related sibling tools stop_pcap_file and fetch_pcap_file as follow-ups, which helps an agent choose the correct next action. It does not explicitly state when not to use it, but the differentiation from streaming captures is implied.

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 must carry the full burden. 'List all timezones available' clearly communicates a read-only, non-destructive operation. It does not add details about output ordering or format, but the output schema is present and the behavior is predictable for a listing operation.

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, well-structured sentence that front-loads the verb and resource. Every word contributes either to scope ('available on the WLAN Pi') or to downstream usage ('for use with set_timezone').

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 listing tool with an output schema, the description is fully sufficient. It tells the agent what the tool does, the scope of the result, and how it fits into a broader workflow with set_timezone. Nothing essential 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?

The tool has zero parameters, so the baseline of 4 applies. The description correctly implies that no inputs are needed; mentioning parameters would add no value.

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 ('List') and a specific resource ('all timezones available on the WLAN Pi'). It also distinguishes itself from the sibling get_timezone and set_timezone by focusing on the full set of options rather than the current value or assignment.

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 'for use with set_timezone' gives a clear usage context: call this when you need to select a timezone to pass to set_timezone. It does not explicitly mention when not to use it or name alternatives, but the intended use case is evident from the pointer.

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?

The description discloses that active sessions and captures will be interruptedcompress and that the operation can be disabled via ALLOW_POWER_CONTROL=false. Since no annotations are provided, the description carries the full burden, and it reasonably addresses the most important behavioral impacts of a reboot.

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 three short sentences, with the primary action and immediate consequences stated upfrontлекс, followed by a critical configuration caveat. Every sentence adds meaningful information without excess.

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 the zero-parameter input and simple action, the description covers the essential behavioral context, but could mention whether the reboot is graceful or forcedlint. The output schema exists, so return values are not the main gap.

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?

There are no parameters to document, and the schema is empty. The description properly conveys the tool's command, so the agent does not need parameter explanations. A baseline of 4 for zero-parameter tools is appropriate 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?

The description clearly states the action ('Reboot the WLAN Pi immediately') with a specific verb and resource, making it easy to distinguish from sibling tools like shutdown_device and restart_service. The immediacy is communicated, and the tool's destructive nature is implied effectively.

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?

While the description does not explicitly name alternatives, it implies use when an immediate reboot is required and warns that active sessions and captures will be interrupted. It also mentions the ALLOW_POWER_CONTROL=false config as a precondition/disable mechanism, which is useful context for deciding whether this tool will work.

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 behavioral disclosure burden. It usefully reveals that the renewal occurs in the interface's current namespace and that the IP address may change, which is important side-effect information. It does not mention broader risks like temporary connectivity loss, but it covers the most critical behavioral traits.

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 short, front-loaded with the core purpose, and contains no filler. The key side effect is stated immediately after the purpose, and the parameter documentation is compact and useful.

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 single-parameter tool with an output schema, the description is largely complete: it names the action, describes where it happens, notes a possible IP change, and defines the parameter. It could be improved by noting prerequisites or failure modes, but nothing essential is missing for a basic invocation.

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 for the parameter. It defines 'interface' as an interface name and gives a concrete example ('eth0'), which is sufficient for an agent to understand the expected value. It does not enumerate constraints like DHCP-enabled interfaces, but the example and name provide adequate guidance.

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 specifies the verb ('Renew') and resource ('DHCP lease for an interface'), making the tool's purpose immediately obvious. It is distinct from sibling getters like get_dhcp_leases because it describes an action, not a query.

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 usage is implied by the action: use this when you want to renew an interface's DHCP lease. However, it does not explicitly state when to prefer this over alternatives or note exclusions, such as not using it for static interfaces.

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 says 'Restart' but doesn't disclose side effects like brief service interruption, required permissions, or whether the operation is reversible. For a mutating control operation, this lack of transparency is a significant omission.

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—one sentence plus a parameter explanation. The action is front-loaded and there's no fluff. It could slightly improve by adding a usage note, but as-is it's efficient.

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 it's a state-changing operation with no annotations, the description lacks important context such as what happens on success (return value), whether it requires elevated privileges, or whether it causes downtime. The output schema exists but is not referenced, and the description doesn't prepare the agent for the operation's impact.

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 schema provides zero description coverage, so the description must compensate. It does: 'Service name (use list_allowed_services to see valid names)' explains the only parameter and directs the agent to a validation source. This adds real meaning beyond the bare type string.

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 action ('Restart') and the resource ('a WLAN Pi service'), making the purpose unambiguous. It distinguishes itself from siblings like start_service and stop_service through the verb. However, it doesn't explicitly contrast with those siblings, so it's not a perfect 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?

The description only tells the agent to use list_allowed_services to find valid names, which is parameter guidance rather than usage guidance. It doesn't explain when to prefer restart over start or stop, nor any conditions or prerequisites. This is a clear gap for an operational tool.

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 must carry the transparency burden. It does state the main mutation (moving the interface back to root) and the optional namespace deletion timing ('after reverting'). However, it does not explain side effects of deleting the namespace, irreversibility, or error/failure behavior, which leaves gaps for a mutation 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 compact and front-loaded with the core purpose, followed by a minimal Args section that covers exactly the parameters needing explanation. There is no filler or redundant 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?

For a tool with only three simple parameters and an output schema present, the description covers the essential purpose and all parameter semantics. It could still state prerequisites or failure conditions, but given the low complexity and structured schema, it is reasonably 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?

The input schema has 0% description coverage, and the description compensates fully: interface gets a concrete example, namespace gets its role and default clarified, and delete_namespace is explained with its timing. This adds meaningful detail beyond the bare schema property names and defaults.

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 ('Revert') and a precise resource ('WLAN interface from its namespace back to the root namespace'), making the operation unambiguous. It is clearly distinguishable from the sibling tools, none of which perform this exact namespace-revert action.

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 purpose statement implies when the tool should be used (when a WLAN interface needs to be returned to the root namespace), but it does not explicitly state prerequisites, exclusions, or when to choose an alternative. With no obvious sibling alternative, the guidance remains implicit rather than explicit.

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 burden of behavioral disclosure. It discloses the use of LibreSpeed CLIaine, the time cost (30-90 seconds), and the specific data returned. This goes beyond a simple restatement and informs the agent of latency and performance implications. It lacks explicit side-effect information, but the behavior is sufficiently transparent for a diagnostic speed test.

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 three sentence-equivalents, each earning its place: purpose, performance caveat, and return values. It is front-loaded with the core function and contains no filler or repetition. This is an ideal length for a zero-parameter tool.

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 tool with a valid output schema, the description covers the essential operational context: what it does, how long it takes, and what it returns. It does not mention dependence on internet connectivity or potential failure modes, but these are reasonably inferred from 'internet speed test.' The description is complete enough for an agent to invoke this tool confidently.

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 accepts zero parametersholiday, so there is no parameter semantics to explain. Per the calibration, zero parameters receive a baseline of 4. The description does not need to compensate for schema gaps because there are no gaps.

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 and resource: 'Run an internet speed test from the WLAN Pi.' This is unambiguous and clearly distinguishes the tool from sibling diagnostics like get_device_stats or get_reachability. The tool's identity is fully captured in the first sentence.

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 clear context by noting that the test is slow and typically takes 30-90 seconds, which helps an agent decide whether this tool is appropriate for a task that expects quick results. It does not explicitly name alternatives or provide when-not-to-use guidance, but none are obvious among the siblings. This is clear context without formal 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, the description carries the full burden. It discloses the non-trivial behavior of returning 'needsSelection' with candidates instead of scanning, and the namespace-awareness and auto-selection of monitor adapter. It also explains the detail parameter values. It doesn't explicitly state it's non-destructive, but 'scan' implies read-only; the key behavioral quirks are covered.

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 moderately sized but well-structured: a one-line purpose, then the selection behavior, follow-up, and a clean Args list. Each sentence adds value, and the critical selection quirk is front-loaded. It's slightly verbose but not wasteful.

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 the tool's complexity (non-trivial selection flow, 4 optional params) and the presence of an output schema, the description covers the essential context: what triggers 'needsSelection', how to proceed, and parameter meanings. It doesn't describe the normal return structure, but that's covered by the output schema. It's complete enough for an agent to call it correctly.

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%, so the description must compensate, and it does thoroughly. The 'Args' section explains all four parameters: interface (with auto-selection), namespace (optional), include_hidden (purpose), and detail (enum meanings). It adds meaning well beyond the bare schema, including default behavior and example value for interface.

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 'Scan for Wi-Fi networks.' with a clear verb and resource. It distinguishes itself from siblings by emphasizing namespace awareness and monitor adapter selection, and the follow-up to create/activate network configs ties it to a distinct workflow. No other sibling does a raw scan; capture_scan is for capture sessions, so purpose is unambiguous.

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 provides explicit instructions for the multi-adapter scenario: if multiple monitor adapters exist and no interface is given, it returns 'needsSelection' and instructs to call again with a candidate interface. It also names the follow-up tools (create_network_config / activate_network_config) for connecting. It doesn't explicitly contrast with alternatives like get_wifi_capabilities, but the usage context is clear for when to use this scan.

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 states the action and the parameter values, but it does not mention any side effects, prerequisites (e.g., Bluetooth hardware availability), or potential failures. While the operation is simple, the lack of any behavioral context beyond the action is a gap, though not fatal.

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 extremely concise, using just two sentences, and it is front-loaded with the purpose. It is appropriately sized for a simple toggle tool, with no unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.