Ruckus Virtual SmartZone MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools are clearly separated by resource type and action (e.g., vsz_list_aps vs vsz_get_ap vs vsz_update_ap). Minor potential confusion exists between vsz_get_system_info, vsz_get_system_summary, and vsz_get_system_inventory, which all provide overlapping system-level overview data, but descriptions help differentiate them.
Naming Consistency5/5All tools follow a consistent vsz_verb_noun pattern (e.g., vsz_list_zones, vsz_create_wlan, vsz_delete_ap). Verb choices are predictable (list/get/create/update/delete/reboot/block/unblock), making the API easy to navigate.
Tool Count3/553 tools is a large surface for a network management server, stretching beyond the typical 15-tool range. However, the domain is broad (APs, WLANs, zones, clients, alarms, AAA, DHCP, etc.), so the count is defensible, but it feels heavy and may overwhelm agents.
Completeness4/5The server covers major CRUD operations for zones, WLANs, APs, and domains, plus operational actions like reboot, block, and acknowledge. Notable gaps include missing update/delete for DHCP pools and auth servers, and no create/update for AP groups or VLAN pools, but the core workflows are well covered.
Average 3.6/5 across 53 of 53 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full disclosure burden. It only says 'clear (dismiss)' without explaining what happens to the alarm (e.g., irreversible, requires specific permissions, or changes alarm state). This is minimal and does not clarify side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an Args block, with no fluff or repetition. It is front-loaded and efficient, though the brevity borders on under-specification. It earns a 4 because every part is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is incomplete. It does not mention what the tool returns (despite an output schema existing), any side effects on the alarm, or how it differs from the similar vsz_acknowledge_alarm. Given the lack of annotations, this is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for host or alarm_id (0% coverage). The description partially compensates by explaining host as 'vSZ controller IP or hostname' and alarm_id as 'Alarm UUID' with an example. This adds meaning beyond the schema but is still sparse and lacks format constraints or additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear (dismiss) an alarm.' The verb 'clear' and resource 'alarm' are specific. However, it does not differentiate from the sibling tool vsz_acknowledge_alarm, which likely performs a similar action, so it loses a point for missing sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternatives such as vsz_acknowledge_alarm or vsz_get_alarm. The description does not mention prerequisites, typical use cases, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavioral traits. It only states that a zone is created, with no mention of side effects, persistence, permission requirements, idempotency, or failure behavior. This is a significant 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear one-line purpose followed by a well-organized Args list. Each parameter entry is short but informative. However, the Args list somewhat duplicates the schema, though it adds value through explanatory notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are not the main issue, but the description lacks usage context, behavioral implications, and any sense of when this tool is appropriate. For a creation operation with no annotations, this is incomplete: it doesn't mention host connectivity prerequisites, potential errors, or relationship to domains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block adds useful meaning beyond the raw schema: 'host' is clarified as 'vSZ controller IP or hostname', 'country_code' is described as 'two-letter country code (e.g. "FR")', and optional flags are indicated. All five parameters receive at least some semantic explanation, though schema coverage is 0% and the description does not provide exhaustive format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new zone on the vSZ controller' with a specific verb ('Create') and resource ('zone'), clearly distinguishing it from sibling tools like vsz_update_zone or vsz_list_zones. The additional Args block reinforces the purpose by identifying the key parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vsz_update_zone or vsz_create_domain. The description simply states what the tool does, with no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 'Delete a zone' without warning about permanence, potential cascading effects on associated objects, or required permissions. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—a single sentence plus parameter explanations—with no unnecessary words. It earns high marks for efficiency, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is minimally complete but omits important contextual information such as error handling, idempotency, or a pointer to list_zones for finding zone_ids. The presence of an output schema offsets the need to describe return values, but behavioral context is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema labels the parameters as 'Host' and 'Zone Id' without descriptions; the tool description supplements this by specifying host is the vSZ controller IP/hostname and zone_id is a Zone UUID. This adds basic semantic value, but lacks details on how to obtain zone_id or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a zone from the vSZ controller, using a specific verb and resource. This distinguishes it from sibling delete tools for other resources (e.g., vsz_delete_ap, vsz_delete_wlan) and from zone creation/update/get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., zone must exist) or when deletion is appropriate, such as when a zone is no longer needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 what state is retrieved, but does not disclose whether the operation is read-only, any required permissions, or potential side effects. This lack of detail is a gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one line for the action and a clear 'Args' block for parameters. It avoids fluff but is still minimal; there is no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter nature and presence of an output schema, the description is adequate but not rich. It explains what the tool does and the parameter format, but does not provide additional context like usage scenarios, limitations, or required access levels, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics to the 'host' parameter by stating it is a vSZ controller IP or hostname. The input schema only specifies 'string', so this explanation compensates for the 0% schema description coverage and clarifies the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get cluster state, specifically node status and roles. This is a specific verb+resource combination that distinguishes it from other tools in the sibling list, which target different resources like zones, APs, or WLANs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context where this tool should be preferred, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 says 'Get configuration details', implying a read-only operation, but does not mention permissions, return format, or potential side effects. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The main purpose is stated in one sentence, followed by a clear argument list. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists, so return values need not be described. However, the description lacks any guidance on error handling, prerequisites, or the scope of 'configuration details'. It is minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 so effectively by explaining both parameters: 'host' as 'vSZ controller IP or hostname' and 'ap_mac' with an example format. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get configuration details of a specific access point', using a specific verb and resource. It implicitly differentiates from sibling tools like vsz_get_ap_operational and vsz_get_ap_radio via the word 'configuration', but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as vsz_get_ap_operational or vsz_list_aps. It simply states what it does without mentioning exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only states the purpose, with no additional context about side effects, permissions, data granularity, or potential errors. It's not misleading, but it's minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short lines plus an Args block. It's front-loaded and contains no filler. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema. The description covers the purpose and parameter semantics but lacks usage context or differentiation from sibling statistics tools like vsz_get_wlan_statistics. It's adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters: host is the vSZ controller IP or hostname, ap_mac is the AP MAC address. This adds meaningful detail beyond the schema, which has no descriptions. Since both parameters are covered, this is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving traffic statistics for a specific AP. It uses a specific verb ('Get') and resource ('traffic statistics' for a specific AP), which distinguishes it from sibling tools like vsz_get_ap (AP configuration) or vsz_get_ap_operational (operational status). However, it doesn't explicitly name alternatives, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 doesn't mention any prerequisites, expected use cases, or exclusions. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 of disclosing behavioral traits. It only says 'Get' and does not mention whether this is a read-only operation, any authentication requirements, rate limits, error behavior, or what the response contains. The word 'Get' implies a read operation, but beyond that, the behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact Args block, with no redundant phrasing or filler. It is front-loaded with the purpose and lists parameters efficiently. Every word earns its place, making it very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the output schema and parameter list, gives enough information for basic invocation. However, it lacks usage guidance and behavioral context, and with no annotations, an agent may be uncertain about side effects or response format. It is minimally viable but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining each parameter: host is 'vSZ controller IP or hostname', and the IDs are clearly marked as UUIDs. This adds meaning beyond the bare schema property names, which lack descriptions. It provides enough context for an agent to understand what values to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('WLAN configuration details'), which effectively distinguishes it from sibling tools like vsz_get_wlan_statistics. However, it does not explicitly call out this distinction, and the phrase 'configuration details' could be slightly ambiguous compared to other WLAN-related getters. Overall, it is specific but not as rich as a fully differentiating description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as when to prefer it over vsz_get_wlan_statistics or vsz_list_wlans. There is no mention of prerequisites, exclusions, or suggested contexts. It simply states the function, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'acknowledge an active alarm', which implies a state change but leaves unclear whether the alarm becomes inactive, whether the action is reversible, or any authorization requirements. This is insufficient 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one action sentence plus a structured Args block. It front-loads the purpose and clearly labels each parameter. No redundant text or filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-explained parameters and an output schema present, but the description lacks any usage context or side-effect disclosure. It is enough for a minimal invocation but leaves the agent uncertain about when to choose it over the similar vsz_clear_alarm tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), but the description compensates by explaining 'host' as the vSZ controller IP or hostname and 'alarm_id' as the Alarm UUID with a format example. This fully covers both parameters and adds meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'Acknowledge' and the target 'active alarm', clearly identifying the tool's function. However, it doesn't explicitly differentiate from the sibling tool 'vsz_clear_alarm', though the distinction is implied by the verb choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use acknowledge versus clear_alarm or other alarm tools, nor any prerequisites or context. It simply states the action without any usage exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It fails to mention prerequisites (e.g., admin privileges), whether the block is persistent, whether the client is also disconnected, or the possibility of reversal via unblock_client. The term 'blacklist' implies permanence but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, leading with a one-line purpose and then listing parameters. The 'Args:' block adds necessary semantic information. It is not verbose, though the indentation and repetition of parameter names could be slightly tighter, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 parameters, no enums) and has an output schema, so basic invocation is possible. However, the absence of annotations and lack of details about side effects, prerequisites, or relationship to sibling tools leave gaps. It is minimally viable but not fully complete for an agent to understand all implications of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides meaningful explanations for all three parameters: host (vSZ controller IP/hostname), mac (client MAC address), and description (reason). This adds value beyond the bare schema, though it lacks format examples like MAC address formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear action verb and resource: 'Block (blacklist) a wireless client by MAC address.' This immediately distinguishes it from sibling tools like unblock_client or disconnect_client by using the term 'blacklist'. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is a permanent block versus a temporary disconnect, nor does it reference the reverse operation (unblock_client). The description simply states the action without contextual usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only operation, mention any required permissions, or describe side effects. The verb 'Get' implies read-only, but the description lacks any safety-related context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences plus an Args section. Every part contributes to understanding the tool's purpose and parameter, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the output schema covers return values. However, the description lacks any guidance on usage context or safety semantics, which is notable given the absence of annotations. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the host parameter (0% coverage), but the description compensates by explaining it as 'vSZ controller IP or hostname'. This adds meaningful semantic value beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets vSZ controller system information and specifies the fields (version, model, uptime), making it distinguishable from siblings like vsz_get_system_summary and vsz_get_system_inventory. However, it does not explicitly contrast with these alternatives, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need system-level details like version, model, and uptime, but it does not explicitly state when to prefer this over sibling tools or provide exclusions. The context is clear 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Get,' which implies a read operation, but it does not mention authentication requirements, pagination, return format, or any side effects. This is minimal transparency for a production tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence plus an Args block, with no fluff. It is easy to scan, but the Args block lacks structure such as types, defaults, or formatting, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description is sufficient in length but lacking in context. It does not explain mesh topology behavior, contrast with LLDP neighbors, or any operational caveats. The output schema covers return values, but the missing usage guidance and behavioral details make this only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate. It provides short definitions for both parameters: 'vSZ controller IP or hostname' for host and 'AP MAC address' for ap_mac. This adds some clarity beyond the schema property names, but the definitions are not rich enough to specify formats, constraints, or examples, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('mesh neighbor APs discovered by an AP'). The parenthetical '(mesh topology)' and the contrast with sibling tool vsz_list_ap_lldp_neighbors make the purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description — an agent would use this when needing mesh neighbors of an AP — but there is no explicit guidance about when to choose this over alternatives like vsz_list_ap_lldp_neighbors or vsz_list_aps. No exclusions or criteria are provided, so it stops short of a fuller guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. However, it only states the action 'List' and offers no details on authentication, pagination, output format, or potential side effects. The read-only nature is implied but not explicit, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The Args section adds necessary parameter semantics without unnecessary fluff, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers the core purpose but lacks guidance on pagination, permissions, or related sibling tools. It is minimally sufficient but not comprehensive given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by specifying 'host' as the 'vSZ controller IP or hostname', which the schema's 'Host' field does not convey. This compensates for the schema gap, though it does not mention protocol or port requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'blocked (blacklisted) clients'. This distinguishes it from sibling tools like vsz_list_clients (all clients) and vsz_get_client (single client), so the 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to view blocked clients, but it does not explicitly mention when to use it vs alternatives such as vsz_list_clients or vsz_query_clients. There is no exclusion criteria or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Update access point configuration' and lists parameters, but does not explain side effects (e.g., whether changes are immediately applied), authentication requirements, or any other behavioral traits. This is a significant 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary followed by an Args block. Each parameter has a concise, non-redundant description. It is slightly long due to 9 parameters, but every line serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 9 parameters with semantics and there is an output schema available, but it lacks usage context and behavioral side effects. For an update tool, the description is minimally viable but not comprehensive, as the agent must infer operational considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explicitly describing each parameter's role (e.g., 'Move AP to a different zone (UUID)', 'Assign AP to a different AP group (UUID)'). This adds meaningful context beyond the raw schema, though minor details like GPS units are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update access point configuration,' which clearly states the verb and resource. The name vsz_update_ap and the sibling list (vsz_get_ap, vsz_delete_ap, vsz_reboot_ap) further confirm this tool's specific role, distinguishing it from related AP operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites such as the AP needing to exist, nor does it contrast with vsz_get_ap, vsz_delete_ap, or vsz_update_zone. The usage context must be inferred entirely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Create' but discloses no behavioral traits such as whether the operation is idempotent, required permissions, effects of duplicate names, or return value. This is minimal beyond the inherent mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The Args block is efficient and every sentence earns its place, providing useful parameter explanations without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the operation's complexity, the output schema covers return values, and parameter explanations are present. However, it lacks broader context like when to create a domain vs updating one, hierarchical implications, or success/failure behaviors. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter: host as IP/hostname, name as domain name, description, and parent_domain_id for sub-domains. This adds meaning beyond bare property names, though it could include more constraints or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new administration domain' with a specific verb and resource. It distinguishes from sibling tools like vsz_list_domains and vsz_get_domain, which read domains, whereas this tool creates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, prerequisites, or scenarios like creating sub-domains. It only states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 merely restates the action implied by the name ('remove') and does not mention side effects, reversibility, prerequisites, or what happens to the AP after removal, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a single clear sentence followed by a compact Args block that exposes both parameters. Every word 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation, the description covers the core purpose and parameter meanings, and an output schema exists so return values need not be described. However, it omits usage guidelines and behavioral effects, which are crucial for a mutation tool lacking annotations, leaving the description minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptions for its two parameters, but the description's Args section compensates by defining host as 'vSZ controller IP or hostname' and ap_mac as 'AP MAC address'. This adds meaningful semantics beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Remove an access point from vSZ management' with a clear verb and resource, making the tool's purpose unambiguous. It also distinguishes it from sibling delete tools like vsz_delete_zone and vsz_delete_wlan by specifying 'access point'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It only describes the action itself without contextualizing its appropriate use among the many sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states the action 'Delete' but does not reveal important traits such as destructive implications, reversibility, authentication requirements, or behavior when the WLAN does not exist. The parameter listing adds no behavioral context beyond names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point: a single action sentence followed by a compact Args list. Each sentence serves a purpose, and there is no filler. The structural format is clean and front-loaded, making it easy for an agent to quickly parse the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with an output schema, the description covers the core purpose and all parameters. However, it lacks usage guidance and behavioral transparency, which are important for a mutation tool. The presence of an output schema means return values need not be described, but the overall description leaves gaps in when/how to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the parameters (0% coverage), so the description must compensate. It does so by explaining each parameter: host as 'vSZ controller IP or hostname', zone_id as 'Zone UUID', and wlan_id as 'WLAN UUID'. This adds meaningful semantic meaning beyond the bare schema titles, although it does not cover any constraints or dependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Delete a WLAN from a zone.' This uses a specific verb (delete), identifies the resource (WLAN), and specifies the context (from a zone). It distinguishes itself from sibling tools like vsz_delete_ap and vsz_delete_zone by naming the WLAN resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, exclusions, or preferred use cases. The usage is only implied by the action itself, which is not enough to differentiate from other delete operations like vsz_delete_ap or vsz_delete_zone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 states it lists all APs but does not reveal whether the operation might be heavy (e.g., paginated, large result), if it requires specific privileges, or if there are any side effects. The description essentially restates the obvious function without adding behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the main purpose in a single sentence, followed by a clearly labeled Args block. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an output schema, the description covers the basic 'what' and the parameter. However, it lacks usage context (e.g., when to use vs. vsz_query_aps) and does not mention any behavioral caveats like output size or permissions. It is minimally viable but leaves clear gaps in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explicitly explains the host parameter as 'vSZ controller IP or hostname.' This adds meaningful semantic context beyond the raw string type, and since it is the only parameter, it fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List all access points managed by the vSZ controller.' This provides a specific verb ('List'), a resource ('access points'), and a scope ('all managed by vSZ'), which distinguishes it from sibling tools like vsz_get_ap (which retrieves a specific AP) and vsz_query_aps (which implies querying with filters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit usage context or alternatives. It does not mention when to prefer this over vsz_query_aps or vsz_get_ap, nor does it state any exclusions or prerequisites. The 'Args' section only explains the host parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states 'List all' without mentioning whether the operation is read-only, requires special permissions, or has any side effects. For a simple listing tool, this might be acceptable, but the description adds no transparency beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose plus an Args line for the parameter. It is front-loaded with the key action and resource, with no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list operation with an output schema available, the description is minimally adequate but leaves gaps. It does not mention any usage context (e.g., when to list all servers vs. getting one), nor does it disclose any potential edge cases like unreachable host. The presence of an output schema covers return values, but the description alone feels slightly thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'host' parameter with no description (0% schema coverage). The description compensates by clarifying that 'host' is the 'vSZ controller IP or hostname', adding meaningful semantic information that the schema lacks. While it doesn't provide examples or formats, it sufficiently explains the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with a clear resource 'all authentication (AAA) servers', which precisely states the tool's action and scope. It distinguishes itself from siblings like 'vsz_get_auth_server' (which implies fetching a single server) and 'vsz_test_aaa' (which tests AAA).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or suggest using 'vsz_get_auth_server' for detailed information on a specific server. There is no contextual hint beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, permissions, or response behavior. It only states the basic action and arguments, omitting any details about filtering semantics, pagination, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a single-purpose sentence followed by a clean Args block. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description lacks usage context and alternative differentiation. It covers the basics but would benefit from specifying when to use it and what filter options exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block adds meaningful semantics to both parameters: 'host' is defined as the controller IP/hostname, and 'filters' as a JSON string. This compensates for the schema's lack of descriptions, though it remains terse without examples or supported filter keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear action-verb phrase 'List detected rogue access points', which precisely states the resource and distinguishes it from sibling tools like vsz_list_aps (all APs) and vsz_mark_rogue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vsz_query_aps or vsz_list_aps. The description only states what it does without any contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 'mark or classify' but does not clarify side effects, such as whether the existing classification is overwritten, if the AP moves between lists, or if there are any irreversible consequences. This is a mutation tool, and the absence of behavioral details is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a one-line purpose followed by a labeled Args section. Every sentence provides useful information without redundancy or fluff. The format is immediately scannable and appropriate for an API docstring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return values are not required in the description. However, the description omits important contextual details, such as the significance of the classification labels (e.g., what 'Known' or 'Malicious' implies for the system) and whether this action is reversible. For a security-sensitive tool, this leaves the agent without enough context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes an Args section that explains all three parameters: host as controller IP/hostname, rogue_mac as the AP MAC, and classification with valid values (Rogue, Known, Malicious, Ignore). This adds meaning beyond the schema's bare titles and provides allowed values, which is helpful. However, the explanations are minimal and could be more descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Mark or classify a rogue AP,' which clearly states the action and the target resource. It is specific enough to distinguish this tool from siblings like vsz_list_rogue_aps (listing) and vsz_delete_ap (deleting). The verb 'mark/classify' is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as after listing rogue APs or before other actions. It lacks explicit context like prerequisites, exclusions, or references to sibling tools. The only implied usage is that this tool is for changing classification, which is not enough for an agent to decide confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses pagination behavior (page 1-indexed, limit max 1000) and filter format (JSON string), which are useful behavioral constraints. However, it does not explicitly state that the operation is read-only, or describe error handling, rate limits, or what happens with invalid query types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, a list of supported types, and an Args block. It is not overly long, but repeats the query type list twice and ends with 'etc.', which is vague. Each sentence earns its place, though it could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and parameter details, and an output schema exists so return values are defined. However, it lacks important context such as when to use this generic query versus the specialized sibling tools, and it does not provide examples or structure for the JSON filters, leaving the description adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning to every parameter beyond the schema: host is an IP/hostname, query_type is enumerated, filters is a JSON string, page is 1-indexed, limit has a maximum of 1000, and full_text_search is free-text. Since schema descriptions are 0% covered, this compensation is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Run' and resource 'generic vSZ query', and lists supported query types (ap, client, wlan, dpsk, roguesInfoList). It does not explicitly distinguish from sibling tools like vsz_query_aps or vsz_query_clients, but the word 'generic' implies broader scope, which is a partial distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic tool versus the many specialized sibling tools (e.g., vsz_list_aps, vsz_query_clients). The description lists supported query types but does not state when to prefer this tool over alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it only lists parameters and the word 'Query', without disclosing whether it is read-only, returns a specific structure, pagination behavior, or any limitations. As a query tool, it likely has no side effects, but this is not stated, and no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight docstring with a clear purpose statement and a compact arg list. Every sentence adds value, no fluff, and the most important information is front-loaded. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a moderate parameter count, no nested objects, and an output schema present, the description does not need to explain return values. However, given the absence of annotations, the description lacks guidance on edge cases, response handling, or usage nuances. It is minimally viable but not fully complete for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides a one-line explanation for each parameter (host: controller address, filters: JSON string of filter criteria, full_text_search: free-text search). This adds basic meaning beyond the schema, but does not detail the filter criteria format or supported fields, leaving the semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Query wireless clients with advanced filters' which clearly identifies the verb (query), resource (wireless clients), and differentiates it from simpler listing tools like vsz_list_clients. This explicitly distinguishes it from siblings by mentioning 'advanced filters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'advanced filters' implies the tool is for more complex queries, but it does not explicitly mention when to use it versus alternatives like vsz_list_clients or vsz_get_client. No exclusions or specific scenarios are given, only an implied context of needing filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure, but it only says 'Reboot an access point.' It fails to mention the disruptive nature (clients will disconnect, AP goes offline), permission requirements, or any side effects. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for the purpose plus a clean Args block for parameters. Every word earns its place, and the main verb is front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and parameters, and an output schema is present, reducing the need to explain return values. However, it lacks critical context: it does not mention the operational impact (disruptive action) or any prerequisites, making it minimally complete but not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the lack of param documentation. It does so by explicitly defining 'host' as 'vSZ controller IP or hostname' and 'ap_mac' as 'AP MAC address', which fully clarifies both parameters beyond the bare schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reboot an access point' using a specific verb and resource. This distinguishes it from sibling tools like vsz_delete_ap, vsz_get_ap, and vsz_update_ap, 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.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any caveats (e.g., 'use when AP is unresponsive'). The only hint is the verb 'reboot', leaving usage entirely implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It says 'update' but does not explain whether unspecified fields are left unchanged, what happens if the zone_id does not exist, or any required permissions. This is minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose statement. The Args list is structured and provides essential information without redundancy, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with 4 parameters and an output schema. The description covers the action and parameter meanings, but lacks usage guidance and behavioral context. It is minimally adequate for a straightforward update operation, but not rich enough to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the Args list in the description compensates by explaining each parameter: host is the controller IP/hostname, zone_id is the UUID, and name/description are the new values. This adds clear meaning, though it does not explicitly note that name and description are optional or that null means no change.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update an existing zone's configuration', which is a specific verb and resource. This clearly distinguishes it from sibling tools like vsz_create_zone, vsz_delete_zone, and vsz_get_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or alternatives. It merely states the action, leaving the agent to infer that this is the tool for updating a zone, but does not mention when not to use it or compare to other zone operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 of behavioral disclosure. However, it merely states 'Create a new WLAN in a zone' and lists parameters. It does not explain side effects (e.g., immediate broadcast), prerequisites (e.g., zone existence, permissions), or behavior on duplicate SSID/name. The only behavioral note is that passphrase is required for WPA security, which is more of a parameter dependency than an operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a docstring with a single-sentence summary followed by an Args list. It is concise, front-loaded with the action, and does not waste words, though the formatting could be more compact. The Args list provides necessary parameter explanations without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, schema with no descriptions), the description covers parameter meanings but omits contextual details such as prerequisites (e.g., zone must exist), error conditions, and operational consequences. The existence of an output schema covers return values, but the description is still somewhat sparse for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds a meaningful semantic for each of the 9 parameters. For instance, 'security_type: Security type (Open, WPA2, WPA3, WPA23_Mixed, WEP)' enumerates allowed values, and 'passphrase: PSK passphrase (required for WPA security)' clarifies a dependency. These meanings are absent from the schema, which only provides titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new WLAN in a zone.' This uses a specific verb (Create), resource (WLAN), and scope (in a zone), clearly distinguishing it from sibling tools like vsz_update_wlan, vsz_delete_wlan, vsz_list_wlans, and vsz_enable_disable_wlan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over alternatives, nor does it list exclusions. Usage is implied by the action itself—creating a new WLAN—but it does not mention prerequisites like zone existence or name uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 discloses that the tool disconnects/deauthenticates a client, but does not mention permission requirements, reversibility, or side effects on the client's session. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded with the action. The 'Requires both' sentence adds essential context, and the Args section is necessary given the schema's lack of descriptions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values need not be described. However, the description omits important operational context such as what happens after disconnection, whether reconnection is possible, and error conditions. It is minimally viable for invoking the tool but incomplete for understanding its full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 each parameter: host (vSZ controller IP/hostname), client_mac, and ap_mac (AP the client is associated with), adding meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Disconnect (deauthenticate) a wireless client.' This distinguishes it from related tools like block/unblock, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key prerequisite: 'Requires both the client MAC and the AP MAC it is connected to.' This implies the context of use but offers no explicit guidance on when to choose this over sibling tools like vsz_block_client.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the toggle action and parameter semantics, but does not disclose side effects, permissions, whether changes are immediate, or any other 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear action sentence followed by a structured Args list. There is no redundant text, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle operation, the action and parameters are covered, but with no annotations the description lacks contextual details like permissions, immediate effects, or validation requirements. An output schema exists, so return value documentation is unnecessary, yet minimal usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and titles with 0% description coverage. The description compensates fully by explaining each argument: host as controller IP/hostname, zone_id and wlan_id as UUIDs, and enabled as True/False for enabling/disabling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Enable or disable a WLAN,' clearly identifying the specific action on a specific resource. This distinguishes it from sibling tools like create/update/delete/list/get WLAN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as vsz_update_wlan or vsz_get_wlan. No prerequisites, conditions, or exclusions are mentioned, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It only states 'Get details' without disclosing the return format, error behavior when the client is not found, or whether it applies to currently connected clients. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a structured Args block. No unnecessary words; every line serves to explain the parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While a simple getter with an output schema, the description omits behavior when the client is not found and does not place the tool among its siblings. It is adequate for basic use but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 defining both parameters: host as 'vSZ controller IP or hostname' and client_mac with an example format. This adds meaning beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific wireless client by MAC address,' which distinguishes it from sibling list/query/action tools like vsz_list_clients or vsz_disconnect_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no explicit context, and no exclusion criteria. The need for a MAC address is implied but not framed as a prerequisite or as a distinction from listing all clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List all controllers' and does not disclose any behavioral traits such as read-only nature, response format, pagination, or lack of side effects. The implied read-only nature is minimal and not explicitly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence for purpose and one for the parameter. It is front-loaded with the key action and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one parameter and an output schema present, the description covers the essentials. It could benefit from clarifying how this differs from similar list tools, but the combination of purpose, parameter explanation, and schema makes it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section explaining 'host: vSZ controller IP or hostname', which adds meaningful semantics beyond the schema's bare 'Host' property. Schema coverage is 0%, but the description compensates well for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all controllers in the cluster' clearly states the verb (list), resource (controllers), and scope (in the cluster). This is specific and distinguishes it from sibling tools like get_system_info or get_cluster_state, which concern different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 conditions. It simply states the action without context for selection among the many list/get tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only states 'Get details' and does not disclose read-only nature, error behavior, or any side effects. For a getter, it would be helpful to explicitly state it is a safe 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The first sentence states the purpose, and the Args block clearly maps parameters to meanings. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with an output schema, so the description need not explain return values. The two parameters are documented, and the lack of nested objects keeps it simple. However, it could mention how to obtain a domain_id or that it complements vsz_list_domains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond the schema by explaining host as 'vSZ controller IP or hostname' and domain_id as 'Domain UUID'. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific domain' with a specific verb and resource. It distinguishes from sibling tools like vsz_list_domains and vsz_create_domain, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that domain_id can be obtained from vsz_list_domains, nor does it contrast with other getters with different scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 mentions the HTTP endpoint (POST /vlanpoolings) but does not disclose read-only status, authentication requirements, pagination, or any side effects. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded with the main purpose 'List VLAN pooling profiles.' The additional lines about the endpoint and argument are focused and add necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter list tool with an output schema available. The description covers the core function and the host parameter. However, given the lack of annotations, it would benefit from a brief note on expected behavior (e.g., safe read-only operation), but overall it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare 'host' string property with no description. The description compensates by explaining that host is the 'vSZ controller IP or hostname,' adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'VLAN pooling profiles,' using a specific verb and resource. This distinguishes it from sibling tools like vsz_get_vlan_pool, which targets a single pool. It is not a tautology and conveys 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.
Usage Guidelines2/5Does 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 such as vsz_get_vlan_pool or vsz_list_dhcp_pools. It only states the tool's function, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get details,' which implies a read operation, but it does not mention authentication requirements, potential errors, or any side effects. This leaves a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single purpose sentence followed by an Args list. Every element is necessary, no redundancy, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be described. However, with no annotations, the description omits error behavior, prerequisites (e.g., zone must exist), and authorization details. For a simple get operation, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by listing each parameter with a brief meaning: host is 'vSZ controller IP or hostname,' zone_id is 'Zone UUID,' pool_id is 'DHCP pool UUID.' This adds value beyond the schema's bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Get details of a specific DHCP pool.' This distinguishes it from sibling tools like list_dhcp_pools or get_vlan_pool, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you need details of a single pool by ID), but it does not explicitly mention when to use this over alternatives like list_dhcp_pools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 does indicate a read-only retrieve action ('retrieve the client table') and adds a scope qualifier ('currently connected'), but it does not address permissions, pagination, or other behavioral traits. A middle score reflects this partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an Args block. The purpose is front-loaded, and every sentence adds value without redundancy. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, the description covers purpose and parameter adequately, especially given that an output schema exists to define return values. It lacks comparison to similar tools, but that is more of a usage-guideline issue. Overall, the description is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for the 'host' parameter (0% coverage), but the description's Args section fully defines it as 'vSZ controller IP or hostname.' This directly adds meaning beyond the schema and compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List currently connected wireless clients') with a specific resource and scope. It is not as strong as a 5 because it does not explicitly differentiate from sibling tools like vsz_query_clients or vsz_get_client, but the verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as vsz_query_clients or vsz_get_client. It does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Unblock (remove from blacklist)') without mentioning side effects, idempotency, permission requirements, or impact on active sessions. This is a minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one action sentence and two parameter lines. Every word earns its place, and no unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core action and parameter meanings. However, it does not provide context on how to find the client_id or mention any error conditions, leaving some gaps for an agent to infer from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: 'host: vSZ controller IP or hostname' and 'client_id: Blocked client entry UUID'. This adds format and semantic meaning beyond the plain schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Unblock' with an explicit clarification 'remove from blacklist' and names the resource 'client'. This clearly distinguishes it from siblings like vsz_block_client and vsz_list_blocked_clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for clients that are currently blacklisted by referencing 'Blocked client entry UUID'. However, it does not explicitly state when to use it versus alternatives or provide any prerequisites, such as needing to obtain the client_id via vsz_list_blocked_clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists parameters and says 'Update WLAN configuration' without disclosing side effects, whether omitted fields are preserved, required permissions, or error behavior. It lacks behavioral details beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single action line followed by a clean, front-loaded parameter list. Every line earns its place, providing necessary semantics with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple update tool, but it lacks prerequisites, behavior on partial updates, and any note about return values (though output schema exists). It doesn't fully cover what the agent needs to anticipate when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It does so by explaining each parameter (e.g., host as controller IP, zone_id as UUID, name as New WLAN name). The 'New' prefix clarifies that these are updated values, but it doesn't discuss optionality or default null behavior beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update WLAN configuration' with a specific verb and resource. It differentiates from siblings like create_wlan, delete_wlan, and get_wlan by implying modification of an existing WLAN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when modifying an existing WLAN but provides no explicit guidance on prerequisites (e.g., zone_id and wlan_id must exist) or when not to use it. It doesn't name any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It clearly indicates a read operation ('Get', 'Returns') with no side effects disclosed, but does not cover error cases or authentication. This is adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an Args list, front-loaded with the primary purpose and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description sufficiently covers purpose, return section, and parameter semantics. It does not discuss error handling, but that is not essential for a simple read tool with a pre-defined output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaning by defining 'host' as 'vSZ controller IP or hostname' and 'ap_mac' as 'AP MAC address', supplementing the empty schema descriptions. However, it lacks format validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get radio configuration of an AP (2.4G / 5G / 6G)' and clarifies it returns the 'radioConfig section', which clearly defines the tool's purpose and distinguishes it from sibling tools like vsz_get_ap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it retrieves the radioConfig section, implying use when radio configuration is needed, but does not explicitly contrast with alternatives such as vsz_get_ap or vsz_get_ap_operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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. The verb 'Get' implies a read-only operation, but the description does not elaborate on error behavior, required permissions, or any side effects. It is not misleading, but it adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: a single purpose sentence followed by a concise Args block. It is front-loaded with the core action and every line serves a purpose, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation, the description covers the essential context: what the tool does, what each parameter means, and the output schema is already present externally. The only gap is the lack of usage guidelines, but given the low complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types (0% description coverage), but the description's Args section adds meaningful definitions: 'vSZ controller IP or hostname' for host and 'VLAN pool UUID' for pool_id. This clearly compensates for the schema's lack of descriptions and clarifies parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('details of a specific VLAN pool'), clearly distinguishing it from sibling tools like vsz_list_vlan_pools (listing all) or vsz_get_dhcp_pool (different resource type). The scope is explicit: a single pool identified by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives. It does not mention that vsz_list_vlan_pools should be used to discover pool IDs or that the tool requires an existing pool UUID. There is no indication of prerequisites or exclusions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. 'List active alarms' implies a read-only operation and the 'active' filter is a behavioral trait. However, it does not disclose return formatting, pagination, authentication needs, or any side-effect-free commitment beyond the verb choice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the core purpose, followed by a minimal Args block. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with an output schema, the description adequately covers the essential information. It lacks usage guidance and alternative references, but given the low complexity, these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents the only parameter: 'host: vSZ controller IP or hostname.' This adds meaningful semantics beyond the schema's bare 'Host' title, fully compensating for the lack of property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('active alarms'), and scopes it to the vSZ controller. This distinguishes it from sibling tools like vsz_get_alarm (single alarm) and acknowledge/clear (mutating operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as vsz_get_alarm, vsz_acknowledge_alarm, or vsz_clear_alarm. It simply states what it does without indicating context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 of behavioral disclosure. It only states the action 'List' and gives parameter definitions, but omits any information about pagination, error handling, authentication requirements, or safety guarantees. Even for a read-only operation, some behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with a single purpose sentence and a compact Args block. Every word earns its place, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the presence of an output schema (so return values are documented externally), and a clear purpose with parameter definitions, the description is quite complete. It leaves only minor gaps such as explicit usage alternatives, but overall suffices for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero descriptive coverage for parameters, but the description compensates by explaining 'host: vSZ controller IP or hostname' and 'zone_id: Zone UUID', giving essential meaning beyond the bare field names. This fully covers both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List DHCP pools configured in a zone' with a specific verb and resource, clearly distinguishing it from the sibling tool vsz_get_dhcp_pool that retrieves a single pool. The scope (zone) is also specified, 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need all DHCP pools in a zone, but it does not explicitly mention when not to use it, such as for a single pool, nor does it reference any alternative tool like vsz_get_dhcp_pool. The guidance is 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only states 'List all' which implies a read-only operation, but it does not mention potential large result sets, pagination, authentication requirements, or any other behavioral nuances. This is minimal coverage for a description that carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for purpose and a minimal Args block. It is front-loaded and every element serves a purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the description covers the essential purpose and parameter semantics. An output schema exists, so return values are presumably documented elsewhere. The description could mention that it returns domain object details, but the output schema covers this, so the description is adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'host' as a string, but the description adds meaning by clarifying it as 'vSZ controller IP or hostname.' This extra context goes beyond the schema and helps the agent understand what value to supply. With only one parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 administration domains'), which clearly distinguishes it from sibling tools like vsz_get_domain (retrieves a single domain) and vsz_create_domain (creates a domain). The scope 'all' adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list all domains, but it provides no explicit guidance on when to use this tool versus alternatives like vsz_get_domain, nor any exclusions or prerequisites. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only states the action and arguments, without addressing return format, read-only nature, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact, front-loaded with the action, and the Args block is minimal. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema present, the description adequately covers purpose and parameters. It lacks usage guidance, but the low complexity and schema availability keep it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description meaningfully clarifies parameters: host is 'vSZ controller IP or hostname' and zone_id is 'Zone UUID,' going beyond the bare schema titles. It does not add detail beyond these types, but it compensates adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('AP groups configured in a specific zone'), which clearly distinguishes it from sibling tools like vsz_list_aps or vsz_list_zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrase 'in a specific zone' and the required zone_id argument, but the description does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states a benign 'get' operation. It adds no context about error conditions (e.g., 404 for unknown server_id), authentication requirements, or rate limits. The behavior is simple and largely self-evident, but the description does not go beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a clear purpose statement and parameter explanations. The format is slightly boilerplate (with 'Args:' block), but every sentence is informative with no fluff. It could be slightly more polished, but it's appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not explain return values. It fully describes both required parameters with context. The only minor omission is a pointer to list_auth_servers for discovering server IDs, but this is not essential for using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types with no descriptions. The description compensates by explaining that 'host' is the vSZ controller IP or hostname and 'server_id' is the Auth server UUID. This adds meaningful semantic value, satisfying the requirement for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details of a specific authentication server, using the verb 'Get' and specifying the resource ('specific authentication server'). This clearly distinguishes it from sibling tools like vsz_list_auth_servers, which presumably lists all servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific server_id (via the word 'specific'), but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisite steps like listing available auth servers to obtain the UUID. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, requires special permissions, or any rate limits or error behaviors. The only disclosed aspect is the data content, which is purpose rather than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line of purpose followed by a parameter definition, with no redundant text. It is front-loaded with the action and immediately clarifies the required input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description sufficiently explains the tool's function and input. It could add context about network prerequisites or the format of the inventory, but the output schema addresses the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'host' is described as 'vSZ controller IP or hostname', adding concrete meaning beyond the schema's generic string type. 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system inventory with per-zone AP and client statistics, using a specific verb ('get') and resource. This differentiates it from sibling tools like get_system_info or get_system_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when detailed per-zone AP and client statistics are needed, but provides no explicit guidance on when to choose this over alternatives or any exclusions. There is no mention of alternative tools for similar inventory queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. 'Get' implies a read-only operation, but the description does not explicitly state that it has no side effects, requirements for permissions, or behavior on invalid zone IDs. It is minimally adequate but lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in the first sentence, followed by a concise parameter list. No wasted words, and the structure is suitable for tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema present, the description covers the essential inputs and purpose. It lacks error handling details and explicit differentiation from sibling tools, but the output schema for return values reduces the need for that information. Overall it is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description compensates by explaining both parameters: 'host: vSZ controller IP or hostname' and 'zone_id: Zone UUID'. This adds meaningful semantic context beyond the bare schema titles, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific zone' clearly identifies the action (get) and resource (zone), and the modifier 'specific' distinguishes it from list/create/update/delete operations. This is a standard get-by-ID tool and the purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like vsz_list_zones or when not to use it. It only states the parameters, leaving the agent to infer that zone_id is required for a single-zone lookup. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry transparency. It discloses the type of data returned (uptime, clients, status) but does not state that the operation is read-only, nor mention any permission requirements or failure modes. The 'get' verb implies non-destructive behavior, but the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a structured Args list. It is front-loaded with the purpose and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema present, so no need to describe return values. The description covers purpose and parameters adequately, but lacks usage guidance and behavioral caveats, which are addressed in other dimensions. Overall, it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage), but the Args section defines both parameters: host as vSZ controller IP/hostname and ap_mac as AP MAC address. This fully compensates for the schema gap, though it lacks format details for ap_mac.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('operational information of an AP') with clarifying examples (uptime, clients, status). This distinguishes it from sibling tools like vsz_get_ap (general AP details) and vsz_get_ap_statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given. The description implies it is for operational state (uptime, clients, status) but does not contrast with vsz_get_ap or vsz_get_ap_statistics, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' implies a read operation, but the description does not explicitly state it is non-destructive, nor does it mention any performance or pagination aspects. It adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a minimal Args block. Every word earns its place, and it is clearly structured. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with an output schema, so the description need not explain return values. It covers the essential purpose and parameter format. It does not mention authentication or prerequisites, but for a read-only list tool this is likely sufficient. Given the output schema richness, the description is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the host parameter (coverage 0%), but the description's 'Args' section defines host as 'vSZ controller IP or hostname.' This adds meaningful semantic detail about the expected format, beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all zones configured on the vSZ controller' with a specific verb ('List') and resource ('zones'). It distinguishes itself from sibling tools like vsz_get_zone (single zone) by emphasizing 'all zones'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all zones, but does not explicitly compare to vsz_get_zone or mention when to use an alternative. The phrase 'all zones' gives context but no explicit exclusions or alternatives, so it is only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral caveat: DOMAIN-type filters may return 403 depending on privileges, and recommends full_text_search. However, it doesn't mention whether the tool is read-only, pagination, or any side effects beyond the API call. This is helpful 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, a note, and an Args list. The first two sentences are slightly redundant ('Query access points with filters' and 'Uses the vSZ query API to search APs by criteria'), but the overall length is appropriate and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 need no explanation. The description covers purpose, parameters, and a significant API caveat, making it functionally complete. It could improve with explicit alternative tool references, but the core usage context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must document parameters, and it does thoroughly. It explains host (IP/hostname), filters (JSON string with example), and full_text_search (free-text, recommended). This adds significant meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query access points with filters', providing a specific verb and resource. It further clarifies it uses the vSZ query API to search APs by criteria, making its role distinct from simpler listing tools like vsz_list_aps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is implied: 'Query access points with filters' suggests it's for filtered search, and the note recommending full_text_search over DOMAIN-type filters provides practical direction. However, it doesn't explicitly compare against siblings like vsz_list_aps or vsz_query, nor state 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains that the tool sends a test authentication request and validates reachability and credentials, which is useful. However, it does not mention potential side effects (e.g., account lockout), whether the operation is read-only, or failure behavior, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement followed by a structured Args list. It is appropriately sized for an 8-parameter tool, with no unnecessary words or repetition. Every line contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters sufficiently. With an output schema present, return values are handled externally. Missing usage guidelines and behavioral caveats are gaps, but for a moderate-complexity test action, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides one-line explanations for all 8 parameters, including examples like port 1812 for RADIUS and enumerated values (PAP, CHAP, PEAP). Since schema description coverage is 0%, this adds meaningful context beyond the raw parameter names and types, though the explanations are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Test AAA server connectivity' and elaborates 'Sends a test authentication request to validate the RADIUS/TACACS+ server is reachable and credentials work.' This is a specific verb+resource description that distinguishes the tool from sibling read-only auth server tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for testing AAA server connectivity but does not explicitly state when to use it versus alternatives like vsz_list_auth_servers or vsz_get_auth_server. There are no exclusions or alternative recommendations, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it tries /system/systemSummary first and falls back to /system/inventory. This is valuable context beyond what annotations or schema provide, since no annotations are present. It also clarifies the output composition (AP count, client count, zone statistics), adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the purpose, followed by a useful implementation note and parameter explanation. Every sentence contributes meaning without redundancy. The structure is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description covers purpose, fallback behavior, and parameter semantics. It does not explicitly mention return format, but the presence of an output schema reduces that need. However, it lacks explicit comparison to sibling tools, which is a minor gap for selecting the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists 'host' with a title and type, lacking any descriptive text. The description compensates by explicitly stating 'host: vSZ controller IP or hostname', giving the parameter clear meaning. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a system summary with AP count, client count, and zone statistics. The verb 'Get' clearly identifies the action, and the resource 'system summary' is well-defined. This distinguishes it from sibling tools like vsz_get_system_info and vsz_get_system_inventory by specifying the summarized content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a high-level system overview, but it does not explicitly compare to alternatives or state when not to use it. The fallback behavior offers some context but no direct guidance on selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 discloses that the tool returns a list of neighbors with specific fields, which is useful. However, it does not explicitly state read-only behavior, authentication requirements, or error handling. The verb 'Get' implies a read operation, but more transparency about side effects or prerequisites would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured well: a one-sentence purpose, a return-value sentence, and an Args list. Every sentence contributes value, though it could be slightly tighter by merging the first two sentences. Overall, it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with no annotations and an output schema, the description provides adequate context: what it does, what it returns, and the parameters. It doesn't mention pagination or edge cases, but given the likely small result set and existing output schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates with an Args section explaining both parameters. 'host: vSZ controller IP or hostname' and 'ap_mac: AP MAC address (e.g. ...)' add meaning beyond the plain schema, including an example for ap_mac. This is excellent parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get LLDP neighbor devices discovered by an AP' with a specific verb and resource, and it distinguishes itself from siblings like vsz_list_ap_mesh_neighbors by explicitly focusing on LLDP neighbors. It also lists the specific returned fields, leaving no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to retrieve LLDP neighbors for a specific AP) and the context is clear from the function name and description. It does not explicitly mention alternatives or exclusions, but the use case is evident without requiring additional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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. 'List' clearly indicates a read-only operation, and the scope ('in a zone') is stated. However, it does not disclose any additional behavioral details such as whether the response includes disabled WLANs, pagination, or required access permissions. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a simple two-line Args section. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list operation with an output schema present, the description covers the essential scope and parameters. It is complete enough for an agent to invoke the tool correctly, though it omits potential error conditions or prerequisites (e.g., zone existence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: host is 'vSZ controller IP or hostname' and zone_id is 'Zone UUID'. This adds meaningful format and semantic context beyond the raw schema names, though it does not provide deeper guidance like where zone_id can be found.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all WLANs in a zone.' It uses a specific verb ('List'), a clear resource ('WLANs'), and a scoping context ('in a zone'), distinguishing it from sibling tools like vsz_get_wlan (singular fetch) and vsz_create_wlan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool to list all WLANs associated with a specific zone. It does not mention alternatives or exclusions, but the context is clear enough without explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explains that the tool uses the query API, the type of statistics returned, and that omitting `wlan_name` returns all WLANs. This provides meaningful behavioral context beyond the schema, though it does not cover authentication or potential performance limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It leads with the tool's purpose, then summarizes the output and lists arguments with clear, concise explanations. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an output schema, the description covers the essential purpose, parameter semantics, and behavior. It lacks explicit guidance on when to choose this tool over siblings, but this is a minor gap for a simple getter and the output schema covers return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for parameters are minimal ('Host', 'Wlan Name'), so the description adds essential meaning. It specifies that `host` expects an IP or hostname and that `wlan_name` is an optional filter defaulting to all WLANs. This fully compensates for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get statistics for WLANs via the query API.' It enumerates the returned statistics (client count, traffic, status), which distinguishes it from sibling tools like `vsz_list_wlans` and `vsz_get_wlan` that focus on WLAN configuration rather than statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when WLAN statistics are needed, with an optional filter by WLAN name. However, it does not explicitly name alternative tools or state when not to use it, stopping short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 transparently reveals that the tool fetches the entire alarm list and filters locally, which is a significant implementation detail. It does not mention error handling or performance implications, but the read-only nature is implied and adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a brief explanation of the why, and a clean Args list. No redundant or irrelevant information is present, and the most important content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters and an output schema exists, the description provides all necessary context. It explains the unconventional behavior (list-then-filter) and documents both parameters, making it fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides parameter titles, so the description's Args section adds essential meaning. It explains host as the controller IP/hostname and gives an example format for alarm_id, which is exactly the kind of clarification an agent needs beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get details of a specific alarm,' clearly stating the verb, resource, and scope. It further explains the filtering approach and explicitly contrasts with the absence of a single-alarm endpoint, distinguishing this from list_alarms and other alarm operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving a single alarm by ID, even noting the API limitation that forces a list-then-filter approach. However, it does not explicitly name alternative tools like vsz_list_alarms or state when not to use this, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xEkho/Ruckus-vSZ-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server