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

With no annotations, the description carries the burden. It explains the strict threshold logic, output tiers (CRITICAL, WARNING, OK), and return format (Markdown). It does not mention side effects, but as a read-only aggregate, no destructive behavior is expected. Missing explicit read-only declaration, but sufficient 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 well-structured with clear sections for args and output tiers. It is front-loaded with purpose and provides necessary detail without excess. Every sentence adds value.

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 (one parameter, output schema present), the description covers purpose, parameter semantics, output tiers, and return format. It is complete for effective use.

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 description must explain the parameter. It does so thoroughly: defines offline_threshold, default 10.0, explains the '>' comparison, and gives example 0.0. No other parameters exist, so full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a morning AP health check across all sites, specifying verb and resource. It distinguishes from siblings like 'health_check' (likely broader) and 'list_aps' (no aggregation). Output tiers further clarify purpose.

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 use for routine health checks, but lacks explicit instructions on when to use versus siblings. However, the context of 'morning health check' and aggregated output provides clear 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?

No annotations provided, so description bears full burden. It details return fields (OS, manufacturer, VLAN, connection status) and performance characteristic (direct lookup). Lacks discussion of errors or side effects.

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?

Extremely concise: three lines plus a single-param args section. No wasted 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?

For a simple single-lookup tool with output schema, description covers input format, return details, and performance. Lacks error handling info but 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?

Only one parameter with schema showing type string and title. Description provides example format 'aa:bb:cc:dd:ee:ff', adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Look up a single client by MAC address', specifying verb and resource. Differentiates from siblings like list_clients and get_client_mobility_trail.

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 mentions 'direct API lookup (no full-list scan)', implying efficiency for single client lookups. Could add when not to use or alternatives, but enough 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, the description carries the whole burden and does: it declares read-only, a ~48s bounded call with partial data surfaced under Notes, per-group caching of Classic data, and graceful degradation when Classic fails. It also discloses ordering behavior (Classic-only swarms appended when unfiltered) — behavior an agent could not infer from 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?

Front-loaded with the one-line purpose and a usage sentence, then detail. It runs long across several paragraphs and repeats the Classic/group interaction (in prose and again under Args), so a little tightening is possible, but no sentence is truly idle.

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 three-filter, no-required-param reporting tool with an output schema, this covers purpose, filters, degraded-mode behavior, caching, and cross-system (Classic vs New Central) semantics. An agent has everything needed to call it and interpret 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 coverage is 0%, yet the description fully compensates: exact-name, case-insensitive matching, AND-combination across filters, empty-string meaning no filter, and the non-obvious rule that group resolves via Classic when New Central reports none. This is meaning an agent cannot get from the bare string 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?

Opens with a specific verb+resource: firmware of every AP swarm, with running versions, upgrade status, group and site. This is clearly differentiated from siblings like list_swarms (which enumerates swarms rather than firmware posture) and get_ap_status (per-AP rather than per-swarm).

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?

'Use this to see which swarms still need a firmware upgrade and what Central will do next' gives the selecting condition explicitly. It does not name an alternative tool or state exclusions, so it stops short of full when/when-not 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, and the description only states a read operation. It lacks disclosure of potential side effects, permissions, rate limits, or error handling (e.g., if AP not found).

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 with a one-line summary and a minimal Args section. Every sentence adds value, and the structure is clean.

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 simplicity of the tool (one parameter, output schema exists), the description is adequate but omits details like what fields are returned in the detailed status or behavior for invalid names.

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 Args section adds the detail that ap_name is case-insensitive, which goes beyond the schema's type-only definition. This is valuable context for correct invocation.

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 'Get detailed status of a specific access point by name,' specifying a distinct verb and resource. While it implicitly differs from sibling tools like list_aps and get_ap_throughput, it does not explicitly differentiate 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. It does not mention prerequisites, when not to use, or comparisons with sibling tools such as list_aps or get_ap_throughput.

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

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

With no annotations, the description carries full behavioral burden. It states it returns timestamped throughput in bps and defaults to last 3 hours, but does not mention error handling, auth requirements, or impact. 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?

Description is concise with a clear function statement followed by structured args. Every sentence provides useful information 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?

Given the presence of an output schema, the description need not detail return values, but it does mention timestamped TX/RX throughput. It covers all parameters and defaults. Lacks error case handling but overall complete for a read-only data 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?

Despite 0% schema description coverage, the description adds detailed semantics for each parameter: serial_number lookup guidance, interface_type enum values, and start_at/end_at defaults (schema shows empty strings). Adds significant value beyond 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 tool retrieves throughput trend for a specific AP as a time-series table with TX/RX throughput in bps. It distinguishes from sibling tools like get_clients_trend or get_ap_status by focusing on AP throughput.

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 use for AP throughput data and gives prerequisite guidance (use list_aps or get_ap_status for serial number), but does not explicitly state when to use this tool versus alternatives or exclude other scenarios.

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, but the description clarifies behavior: returns time-series table with APs, times, SSIDs; defaults to last 3 hours. Does not mention errors or limits, but is reasonably transparent for a read 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?

Concise with a clear heading, brief summary, and structured Args section. A minor redundancy in the first two sentences, but overall efficient and well-organized.

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, the description adequately covers purpose, usage, and parameters. It lacks mention of error handling or client existence, but is sufficient 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%, so the description carries full burden. The Args section provides clear, format-specific explanations for each parameter (MAC address format, RFC 3339 for times, and defaults), adding significant value 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?

Clearly states it retrieves roaming history for a wireless client as a time-series table, specifying AP, time, and SSID. Distinct from sibling tools like find_client_by_mac (current location) or get_clients_trend (aggregate trends).

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 states it is useful for troubleshooting connectivity issues or tracking movement, providing context. Does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent.

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

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

With no annotations, the description carries full burden. It explains constraints (max 1 month range, no future dates), dependencies between group_by and client_type, and that the API returns 400 on mismatch. No contradictions.

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 with a clear first sentence, a usage note, and detailed parameter list. It's not overly concise but each part serves a purpose and is easy to parse.

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 an output schema, return values are not needed. The description covers all input parameters, constraints, and error conditions (API 400). It is complete for agent decision-making.

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%, but the description fully explains all 6 parameters: filter semantics, time format, group_by options, client_type constraints, and default values. This significantly adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get client count trend over time, grouped by a chosen dimension' which is a specific verb+resource. It distinguishes from sibling tools like list_clients or get_top_clients_by_usage by focusing on trends over time.

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 mentions it's 'Useful for capacity planning and usage pattern analysis', giving context for when to use. It does not explicitly exclude alternatives, but the purpose is clear enough.

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

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

With no annotations, the description carries full burden. It discloses that data is aggregated across all APs and clients, grouped by site, and shows specific counts. However, it does not mention auth needs, rate limits, or return format (but output schema exists). No contradictions.

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, all essential. The first sentence immediately conveys the purpose, making it front-loaded and 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 zero parameters, output schema, and a clear description of aggregation and counts, the description is largely complete. It could mention that all sites are returned (no filtering), but that is implicit.

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 for this dimension is 4. The description adds no additional param info, which is acceptable since none exist.

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 returns a summary of all sites with AP and client counts. It uses specific verbs ('Get', 'aggregates', 'shows') and distinguishes from sibling tools like list_aps by focusing on site-level aggregation.

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 use for high-level site overview, but does not explicitly state when to use it vs. siblings like list_aps or daily_brief. No exclusions or alternatives are mentioned.

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, description discloses ranking behavior, time window constraints, and defaults. Does not mention output format but output schema exists. No contradictions.

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?

Front-loaded with purpose, then clear bullet points for each parameter. No redundant sentences; efficient and readable.

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 5 params, no required ones, and output schema present, description covers all key aspects: sorting, time constraints, defaults, filtering. Complete for selection and 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 has 0% description coverage; description explains all 5 parameters with details (enum options for usage_type, range for limit, format for dates). Adds significant value beyond 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?

Clear statement 'Get top access points ranked by bandwidth usage over a time range' with specific verb+resource. Distinguishes from siblings like list_aps (all APs) and get_top_clients_by_usage (clients).

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?

Description provides usage context (time range, ranking by bandwidth) and parameter guidance, but lacks explicit when-to-use vs alternatives. Implicit differentiation from sibling tools is adequate.

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?

Discloses constraints like max 1-month range for start_at and limit range (1-100). However, no annotations exist, so description should also note idempotency, performance, or side effects; it only covers parameter 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?

Structure is clean with an Args list. Each parameter is explained briefly. No unnecessary words, though the first line could be more concise.

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 no annotations, the description covers all 5 parameters with constraints. Output exists but not described, though not required. Sufficient for a ranking tool with moderate complexity.

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 has 0% description coverage, but the description provides clear explanations for each parameter (filtering, time format, default limit). Adds value beyond schema structure.

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?

Clearly states the tool gets top clients ranked by bandwidth usage. Distinguishes from siblings like list_clients (general listing) and get_clients_trend (trend analysis).

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 vs alternatives like list_clients or get_clients_trend. The description only explains parameters but lacks when/not 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 carries the full burden and does so: it discloses cost (lightweight, no data endpoints), mechanism (builds client, obtains OAuth2 token via GreenLake SSO, reuses cached token), and failure semantics (degraded/error status, detail field, New Central reason first). This is unusually rich behavioral context for a mutation-free diagnostic.

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?

Information is front-loaded: purpose, then invocation timing, then cost/mechanism, then return contract. The enumeration of return keys is long but justified in the absence of an output schema, though a few parentheticals could be trimmed.

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?

Since no output schema exists, the description must document the return contract, and it does completely — every status key, its possible values, and the meaning of the degraded/misconfigured states. Paired with explicit invocation guidance, an agent has everything needed to call and interpret 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 takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly spends its space on outputs instead of inventing parameter 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 opening sentence names a specific verb and two concrete resources (server version, Aruba Central backend authentication), which no sibling tool covers. It also explicitly negates scope ('does NOT fetch APs, switches, clients, or any other data endpoint'), making it unmistakable against the data-listing 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?

It states exactly when to call it ('at session start (or after a tool-call timeout)') and why, plus what alternatives it is not meant to replace. The when/when-not pair is explicit rather than inferred.

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 exist, so description carries the burden. It describes the tool as listing APs with an overview, implying a read-only operation. While not explicitly stating safety, the nature of a list operation is transparent enough. Could add explicit 'read-only' but not required for this case.

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: three clearly separated paragraphs covering purpose, usage guideline, and parameter details. Every sentence earns its place with no 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?

The tool is simple with 2 optional parameters and an existing output schema. The description covers purpose, usage context, and parameter semantics sufficiently for correct agent 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 has 0% description coverage, but the description fully covers both parameters: 'site' (exact match, server-side, empty for all) and 'status' (examples like ONLINE/OFFLINE, empty for all). This adds significant meaning beyond the schema field 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 clearly states it lists access points with a device-level overview. It distinguishes itself from the sibling 'list_radios' by specifying that 'list_aps' is for inventory and availability, while 'list_radios' covers RF details.

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 tells when to use ('AP inventory and availability checks') and when not to use, directing to 'list_radios' for RF details. This provides unambiguous guidance for agent 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?

No annotations are provided, so the description carries the full burden. It describes a read-only listing operation with no side effects, and the filtering behavior is transparent. However, it does not explicitly state that it is non-destructive, which would be helpful.

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: two sentences for the purpose and one sentence for the parameter. It is front-loaded with the key purpose and no redundant 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?

Given the simple tool with only one parameter and an output schema (presumably covering return values), the description is fairly complete. It explains the resource and filtering. However, it does not detail the response fields, though that may be acceptable with an 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?

With 0% schema description coverage, the description fully compensates by explaining the 'site' parameter: 'Filter by site name (exact match, server-side). Empty for all.' This adds clear meaning beyond the schema's type and default.

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 'List all BSSIDs (per-radio, per-SSID broadcast identifiers)', which is specific and distinguishes it from sibling tools like list_radios or list_wlans. It explains the purpose and the relationship to radios and WLANs.

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 a use case ('useful for identifying which radio on which AP is broadcasting a specific SSID') but does not explicitly mention when not to use it or alternatives. Agents could infer usage, but explicit guidance is 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?

No annotations provided, so description carries full burden. It states it lists connected wireless clients with details but lacks information on pagination, rate limits, or whether it returns real-time data. Adequate for a read operation 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?

Description is brief and front-loaded with purpose, then lists returned fields and parameters. Somewhat sparse but no wasted words. Could benefit from a bit more structure, but effective.

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 (2 optional parameters, output schema exists), the description covers purpose, return fields, filters, and sibling alternative. Missing details like result ordering or scope, but sufficient for selection and 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 description adds full meaning: each parameter's purpose (filter by SSID/band), match type (exact match, server-side), and default behavior (empty for all). Compensates completely.

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 lists connected wireless clients with connection details, using specific verb 'List' and resource 'clients'. It distinguishes from sibling 'find_client_by_mac' by noting that tool is for full details of a single client.

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 tells when to use this tool (list all clients with filters) and when not (for single client full details, use find_client_by_mac). Also explains behavior of empty filter 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 full burden. It discloses only basic behavior: listing radios with RF details and filtering. No mention of pagination, rate limits, authentication, or error handling.

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?

Description is efficient: 4 lines of main text and 3 lines for Args. No redundant words, and key 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?

Covers purpose and parameters well. Output schema exists, so return values don't need detail. Behavioral transparency is lacking, but for a list tool with two optional params, the description is mostly 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 Args block explains both parameters (site: exact match, server-side; band: e.g., '2.4 GHz', '5 GHz'), adding meaning beyond the schema which has no descriptions. This 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?

The description clearly states 'List AP radios with RF details' and specifies the RF details (channel assignment, utilization, noise floor, TX power). It distinguishes this tool from siblings like list_aps by focusing on radio-level data, but does not explicitly contrast with 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 says 'Use this for RF troubleshooting', providing a clear use case. However, it does not specify when to avoid this tool or suggest alternatives (e.g., list_aps for AP-level info).

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?

Discloses that it is a listing operation, returns specific fields, and describes the site filter as exact match and server-side. No annotation coverage, so description carries the burden well.

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 concise sentences plus an Args line, no wasted words, front-loaded with purpose.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description covers operation, parameter, and return fields adequately for a simple list 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 description explains the 'site' parameter's default and behavior (exact match, server-side, empty for all), adding value beyond the bare schema definition.

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 'List all AP swarms (clusters) from Aruba Central', specifying the verb, resource, and scope. It also lists return fields, distinguishing it from sibling tools like list_aps.

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 like list_aps. The purpose is implied but not explicitly contrasted.

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 exist, so the description must fully disclose behavior. It states it returns specific fields but omits any behavioral traits such as pagination, rate limits, authentication requirements, or potential error conditions. This leaves significant gaps in understanding.

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 only two sentences without any wasted words. It directly states the action and key returned fields, efficiently communicating the tool's core 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?

Given the tool's simplicity (no parameters, straightforward list operation) and the existence of an output schema, the description is nearly complete. However, it could briefly mention that it returns all switches without filters, which is implied but not explicit.

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, and schema coverage is 100%, so the baseline is 3. The description does not need to add parameter information, but it also does not discuss the absence of parameters (e.g., no filters). This is adequate.

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 lists all switches from Aruba Central, explicitly identifying the resource and system. It distinguishes itself from sibling list tools (e.g., list_aps, list_clients) by specifying 'switches'.

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. With many sibling tools like list_aps, list_clients, etc., the absence of any usage context or exclusions limits its helpfulness 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?

No annotations provided, so description carries full burden. Describes it as a read-only list operation and explicitly names output fields. Does not mention potential side effects or limitations, but for a simple list tool this is sufficient.

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?

Description is concise: one sentence for purpose, one for output fields, then a clean Args section. No redundant information; every part earns its place.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers the core functionality and parameter usage adequately. Minor omission: could mention that it returns a list, but the purpose implies this.

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 descriptions are absent (0% coverage), but the description fully explains each parameter's meaning and behavior (empty string as 'all'). This adds significant value beyond the bare 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?

Description clearly states the tool lists configured WLANs (SSIDs) and specifies the fields shown (name, band, status, security, VLAN). It distinguishes from sibling tools like list_aps or list_bssids by focusing on WLAN configuration details.

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?

Provides parameter usage instructions (site_id and serial_number filters) but lacks explicit when-to-use or when-not-to-use guidance relative to alternatives. Relies on implicit context from the tool name.

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