UniFi Internal API MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources (devices, clients, WLAN, firewall, etc.), but several client-related tools (list_users, list_clients, list_active_clients, list_clients_history, stat_allusers) have overlapping purposes. The descriptions help differentiate them by online/offline/v2/API filters, but there is still some potential for misselection.
Naming Consistency4/5
The naming pattern is predominantly verb_noun with underscores (list_*, stat_*, get_*, set_*), which is consistent. However, there is a mix of 'list' and 'stat' for similar operations (e.g., list_clients vs stat_client), and some names like stat_full_status and custom_api_request deviate slightly from the convention.
Tool Count2/5
With 64 tools, the server presents an overwhelming surface area. Even though the UniFi controller API is large, this many tools makes it difficult for an agent to select the right one quickly, and many tools are highly specific (e.g., list_device_name_mappings, list_country_codes). A more focused set of 20-30 tools would be more appropriate.
Completeness3/5
The tool set is extensive in read-only coverage across many domains (health, devices, clients, WLAN, firewall, stats, events). However, it lacks create/update/delete operations for most resources, which are only possible via the generic custom_api_request. This leaves a significant gap for management workflows, but the read surface is fairly complete for monitoring purposes.
Average 3.6/5 across 64 of 64 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.json to 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Use with care' hints at risk, but it does not state whether requests can be destructive, require authentication, are rate-limited, or what the response format is. Given the generic and potentially powerful nature of this tool, the lack of concrete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loading the main purpose and ending with a caution. It is appropriately sized for a generic tool, though it is arguably too brief given the lack of context. No wasted words, but additional useful information would not hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full parameter schema coverage, the description is incomplete for a tool of this nature. It lacks guidance on when to use it, potential pitfalls, authentication needs, or how it relates to the many specific sibling tools. The 'Use with care' warning is insufficient for a raw API request tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (path, method, payload) with descriptions, including a required path, default method, and payload format. The description adds no additional parameter semantics, but as schema coverage is 100%, the baseline of 3 is appropriate. The schema itself is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Make a custom API request to the controller') and distinguishes this from the many specific list/stat sibling tools. The term 'custom' implies a generic fallback, which is further supported by the parameter schema allowing arbitrary path/method/payload. However, it does not explicitly define what endpoints are reachable, so it falls slightly short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the extensive list of specific sibling tools (e.g., list_health, stat_sysinfo). 'Use with care' is a warning, not usage direction. There is no mention of preferring specific tools, prerequisites, or scenarios where this custom request is 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, the description carries the full behavioral disclosure burden. 'Fetch' implies a non-destructive read, but the description does not disclose any behavioral traits such as data sensitivity, pagination, or scope constraints beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that avoids fluff, but it is under-specified in terms of scope and usage, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, but the description lacks usage guidance and behavioral context. It is adequate for a basic list operation but could be more complete 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter, so no additional description is needed. The tool description adds no further meaning to the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches client device fingerprint information, providing a specific verb and resource. However, it does not differentiate from sibling tools like list_devices or list_clients, so it misses the full 5 for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of use cases, prerequisites, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the listing operation. It does not disclose any security requirements, side effects, pagination, or result scope. The read-only nature is only implied by the verb 'list', 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is appropriately brief, though it could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be described. However, the tool lacks annotations and the description alone is too sparse to fully understand the scope, especially given the many sibling list tools. The phrase 'port forwarding rules/settings' is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the schema description coverage is 100%. The baseline for 0-parameter tools is 4, and the description correctly does not add irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with the resource 'port forwarding rules/settings', clearly stating the tool's function. However, it does not distinguish this from the sibling tool 'list_port_configs', leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like list_port_configs or list_port_forward_stats. There is no mention of context, prerequisites, or what differentiates this listing from others.
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. 'Fetch' implies a read operation, but the description does not mention authentication, rate limits, or any potential side effects. This is a significant gap for a network management tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise, but it essentially restates the tool name ('Fetch port forwarding statistics' vs 'list_port_forward_stats'). While it is short and front-loaded, it lacks additional helpful context that would make it more valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a zero-parameter fetch with an output schema, so the description doesn't need to explain return values. However, it would benefit from clarifying what 'statistics' includes (e.g., counters, per-port data, time ranges) to give the agent a better understanding of the tool's role among similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any input semantics. Per the baseline for 0-parameter tools, a score of 4 is appropriate, as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Fetch') and a specific resource ('port forwarding statistics'), which distinguishes it from the sibling tool 'list_port_forwarding' that likely deals with port forwarding rules. However, it doesn't explicitly explain the difference or the scope of the statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_port_forwarding' or other stats tools. It only states the action without 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?
There are no annotations, so the description must carry the behavioral burden. It only says 'using the v2 API', which is a minor implementation detail. It does not disclose potential pagination, data volume, or other behavioral traits expected from a history-listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the core purpose and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema and output schema, the description is minimally adequate. However, it lacks context about data limits, pagination behavior, or how it relates to sibling client list tools, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters fully described in the input schema. The description adds no additional parameter semantics, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool 'List offline client history', which is a specific verb and resource scope. It distinguishes from sibling tools like list_clients or list_active_clients by focusing on offline history, though it does not explicitly contrast with these 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description lacks mentions of use cases, exclusions, or related sibling tools, leaving the agent to infer usage solely from the purpose.
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 full responsibility for behavioral disclosure. It only says 'Fetch ... statistics' with no mention of side effects, scope (e.g., all vs. filtered), auth requirements, or limitations. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and easy to parse. However, it is minimal to the point of omitting useful context (e.g., sibling distinction), so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params) and has an output schema, so the description need not explain return values. However, the existence of 'list_dpi_stats_filtered' suggests a filtered alternative, and the description does not address this, leaving a contextual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter info because there are none; baseline for zero-param tools is 4, and no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('Deep Packet Inspection statistics'), clearly stating what the tool does. However, it does not differentiate from the sibling tool 'list_dpi_stats_filtered', leaving ambiguity about whether this returns all or uniltered stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling 'list_dpi_stats_filtered' suggests a filtered variant exists, but the description does not mention it or provide any context for selecting between them.
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?
The only behavioral trait disclosed is sorting by most recent first. It does not mention pagination behavior, the role of 'historyhours' as a time window, or any read-only nature. Since no annotations are provided, the description carries the full burden but provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence that directly communicates the core purpose. It is optimally concise with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter set, a full output schema, and documented parameters. However, the description lacks usage context and behavioral depth, which is noticeable given the large number of sibling tools and the absence of annotations. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description (e.g., 'Number of events to return'). The tool description adds no extra parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('site events'), and adds the sorting order. It does not explicitly distinguish from sibling tools like list_alarms or stat_ips_events, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With many sibling list tools, such as list_alarms or list_health, the description should clarify the specific event-related use case or how it differs from similar tools.
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 carry the behavioral burden. It discloses the default 7-day window but does not mention whether the operation is read-only, what permissions are needed, or any rate limits or output shape beyond the schema. This is minimal for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and followed by a key default. There is no redundant wording or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks usage context, alternative tool comparisons, and behavioral traits. For a tool with four parameters and many siblings, this minimal description is insufficient for an agent to reliably select it among close alternatives like stat_sta_sessions_latest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds value by clarifying that null start/end defaults to the past 7 days, which is not obvious from the schema's null defaults. This semantic enrichment goes beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Fetch login sessions.' This distinguishes it from other stat tools, though it does not explicitly contrast with stat_sta_sessions_latest. The additional default time range adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives like stat_sta_sessions_latest or stat_authorizations. It only notes the default time range, which implies usage for historical sessions but offers no 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?
No annotations are provided, so the description must disclose behavioral traits itself. It does not clarify whether the operation is read-only, how 'latest' is ordered, whether it returns a single session or multiple, or any error/edge-case behavior. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded with the key action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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, the core functionality is communicated, and parameter details are covered by the schema. However, the lack of usage guidance and behavioral transparency makes the description only minimally complete for selecting among similar session/client tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both 'mac' and 'limit' (including the default), so the description adds no additional parameter meaning. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('latest login sessions'), and the scope ('single client'), which is specific and distinguishes it from broader session tools like stat_sessions. However, it does not explicitly name alternatives or contrasts with sibling tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as stat_sessions or list_clients_history. It simply states what the tool does without context about which scenarios call for this per-client session view.
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 mentions returning 'latest known version info' but does not clarify whether this is a read-only operation, whether it contacts external servers, or if any state changes occur. This is minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using two short sentences to convey the core functionality and return value. Every word earns its place with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters) and the presence of an output schema, the description is minimally viable. However, it lacks any mention of when to use it or what 'latest known version' means, so it is not fully complete for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter meanings. The baseline of 4 applies because there is nothing to add beyond the schema's declaration of an empty object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (check) and resource (controller firmware updates), making the tool's purpose unmistakable. However, it does not explicitly differentiate from the sibling tool list_firmware, which could also be associated with firmware information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as list_firmware, or what prerequisites exist. The description simply states what it does without any contextual usage 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 conveys a read operation via 'Fetch' and mentions the optional filtering behavior, but lacks details on pagination, defaults, authorization, or rate limits. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It front-loads the core action (Fetch alarms) and qualifies it with the optional filter, making it appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param) and benefits from a 100% schema description coverage and an output schema, so the description doesn't need to explain parameters or return values. It sufficiently states the core purpose, though it lacks usage context or alternatives. For this simplicity level, the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'payload' parameter with a description and example filter flags, achieving 100% coverage. The description adds only the phrase 'optionally filtered,' which restates the optional nature already evident from the schema's default null value. Thus minimal additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'alarms', clearly indicating the tool lists alarm data. It also notes the optional filtering capability. However, it doesn't explicitly differentiate from the sibling 'count_alarms' tool, though the verb implies listing rather than counting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like 'count_alarms' or 'list_events'. There is no mention of typical use cases, needed permissions, or context for 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, the description must carry the burden of disclosing behavior. It only says 'Fetch,' implying a read operation, but does not mention how filtering behaves, whether cat_filter is exclusive to by_app, or what the response contains. The parameter descriptions partially cover this, but the description adds no additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the tool's purpose with no filler or repetition. It earns its place and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with two optional parameters and a full parameter schema plus an output schema. The description is sufficient for basic invocation, but it doesn't mention the relationship to the unfiltered list_dpi_stats or clarify that cat_filter only applies to by_app (though the schema notes this). Overall, it's adequate for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter descriptions are complete. The description adds minimal meaning by mentioning 'category or application,' which aligns with dpi_type, but doesn't provide additional semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' with a clear resource 'DPI statistics' and a qualifier 'filtered by category or application,' which distinguishes it from the sibling list_dpi_stats. However, it doesn't explicitly name that alternative or explain the distinction beyond the word 'filtered.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus list_dpi_stats or other list_* tools. The description only states what it does, not when it should be preferred or what alternatives exist, leaving the agent to infer usage from the name.
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. 'Fetch' implies a read-only operation, but it does not mention what data is returned, whether there are any limitations, or any other behavioral characteristics. No additional value beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is front-loaded and appropriately concise for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 parameters) and has an output schema, so the description does not need to explain return values. However, it lacks any context about VoIP extensions, potential prerequisites, or how this fits into the broader API, making it minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to add; the description is not penalized for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a clear resource 'VoIP extensions', which distinguishes it from other list_* tools like list_devices or list_users. However, it does not elaborate on what constitutes a VoIP extension, and the differentiation from similar tools is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the large number of sibling list tools, the description provides no context or exclusions, leaving the agent to infer usage solely from the name.
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 simply states 'Fetch switch port configurations' without mentioning whether this is a read-only operation, whether any filtering or pagination exists, or what the response entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately conveys the tool's purpose. It wastes no words and is appropriately sized for a trivial list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema, the description is adequate for an agent to understand the basic function. However, it lacks context about the nature of the returned configurations or any operational details, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond the schema. The description adds no parameter semantics, but the baseline for a parameterless tool is 4, and the schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action 'Fetch' and the resource 'switch port configurations'. It is distinct from sibling tools like list_port_forwarding and list_port_forward_stats, which focus on port forwarding rather than switch port settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool over alternatives. There are no explanations of prerequisites, typical use cases, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosure. It only states 'List', implying a read-only operation, but gives no additional context about permissions, output characteristics, or potential side effects. Minimal beyond what the verb itself conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, three-word sentence that directly conveys the tool's purpose. There is no unnecessary elaboration, making it perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema available), the description is adequate but sparse. It lacks context about what WLAN groups represent or when they should be used, which is relevant given the many sibling list tools. The existence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description needs to explain no parameter semantics, and it does not introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (WLAN groups), making the tool's purpose unambiguous. It distinguishes from sibling tools by the specific resource type, though it does not explicitly call out differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_ap_groups or list_user_groups. The description provides no context about appropriate scenarios, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Fetch' implies a read-only operation, but no additional context is given about authentication requirements, potential side effects, or what 'all settings' entails. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the action and resource, and every word adds value. Perfectly appropriate for a simple fetch tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description is adequate to convey the tool's purpose. It could mention whether settings are scoped to a specific site, but overall it is complete enough for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100%). No parameter descriptions are needed, and the description does not add any parameter-related semantics. Baseline for 0 params is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch all site configuration settings' uses a specific verb ('fetch') and resource ('site configuration settings'), clearly distinguishing its purpose from sibling list tools like list_sites or list_dashboard. However, it could be more explicit about scope (e.g., current site vs all sites), but the core meaning is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. 'List all' indicates a read operation without filters, but it does not disclose behavior like authentication requirements, response volume, or any side effects. The existence of an output schema helps with return format, but the description itself adds minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the action and the resource clearly, appropriate for a tool with no parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is mostly complete. It states the exact resource and scope. However, given the lack of annotations, adding one sentence about typical use cases or safety could improve completeness, though it's not critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already covers everything. The description adds value by clarifying that the scope is 'all' user groups and defining 'user groups' as 'bandwidth profiles', which is helpful context that goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'user groups' and parenthetical 'bandwidth profiles' to clarify the domain. It distinguishes from siblings like list_wlan_groups or list_firewall_groups by naming a distinct resource, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 the many sibling list_* tools. The description simply states what it does without giving context or exclusions, leaving the agent to infer based on the name alone.
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. 'Fetch' implies a read-only operation, and the 24-hour default behavior is useful. However, it does not disclose potential volume handling, ordering, or whether events are raw or aggregated, leaving some 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Every piece of information is directly relevant: the action and the default time scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 3 optional parameters and an output schema, so a minimal description can be adequate. However, the ambiguity between this and sibling tools like list_events is not resolved, and the default limit behavior is left to the schema. The description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all parameters with 100% coverage. The description adds the semantic that null start/end means the past 24 hours, which is a small but useful addition beyond the schema. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and clearly identifies the resource as 'IPS/IDS events', which is distinct from sibling tools like list_events or list_alarms. However, it does not explicitly contrast it with those siblings, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a default time window ('Defaults to past 24 hours'), which is a usage hint, but it provides no guidance on when to choose this tool over alternatives, no exclusions, and no mention of conditions that might require different tools.
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. 'Fetch' implies a read-only operation, but the description does not disclose auth requirements, potential latency, or any data scope caveats. The agent is left without important context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose without any filler. Every word earns its place, making it an example of efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and only one documented optional parameter. The description is minimal but adequate for a straightforward read tool, though it does not clarify what 'hotspot' refers to in this context or any additional selection criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, including a description for 'within' ('Hours to go back'). The tool description adds no additional parameter meaning, so the schema is sufficient and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('hotspot payment records'), making the tool's purpose unambiguous. No sibling tool overlaps with this specific resource, so differentiation is not an issue here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, but the name and description imply it is for retrieving payment records. With no competing payment tools, this implied usage is sufficient for basic selection.
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 fetch action, implying a read-only operation, but does not disclose permissions, caching behavior, or any side effects. This lack of detail is a gap for a tool that might require admin privileges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's purpose without extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple no-parameter query, and an output schema exists to describe return values, so the description needn't cover those. However, it could benefit from a phrase indicating what 'system information' includes (e.g., controller version, uptime), but the overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making parameter documentation unnecessary. Per the scoring rules, the baseline for 0 params is 4, and the description appropriately omits any parameter details, so this score reflects that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Fetch') and resource ('system information from the UniFi controller'). It is not a tautology and provides enough clarity to distinguish it from pure list tools, though it does not explicitly differentiate from closely named siblings like 'stat_full_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. An agent would have to infer from the name and the context of 'system information' to decide 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 carries the full burden. It does add useful behavioral context: 'Defaults to past 7 days' and 'v2 API'. However, it does not disclose other behaviors such as ordering of results, inclusivity of timestamps, or handling of null parameters, which would be valuable for a log retrieval 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and resource. Every word earns its place with no filler. It is highly readable and efficiently communicates the tool's essence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers all five parameters with good descriptions, while the output schema presumably documents return values. However, the description does not help an agent choose among overlapping siblings like list_events or list_alarms, nor does it clarify the nature of 'system log' vs. other event types. It is adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that omitting start/end defaults to the past 7 days, which is not stated in the parameter descriptions. This provides meaningful semantic context for the time-range parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch system log entries (v2 API)'. It uses a specific verb ('Fetch') and resource ('system log entries'), making the primary purpose unambiguous. However, it does not distinguish this from sibling tools like list_events or list_alarms, which might overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The only usage hint is 'Defaults to past 7 days', which implies a default time range but does not explain when this tool is preferred over list_events or list_alarms. No when-not-to-use or alternative recommendations are 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 only states 'List all firewall rules' and adds no information about safety (read-only nature), pagination, response size, or any other behavioral traits. The word 'all' implies scope, but this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence: 'List all firewall rules.' It is concise, front-loaded, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 return format is defined externally. However, the description lacks any context about prerequisites, preconditions, or how this tool fits among the many sibling list tools. For a basic zero-parameter list, this is adequate but leaves room for improved contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which earns a baseline of 4. The description correctly does not attempt to explain any parameters, as there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all firewall rules' uses a specific verb and resource, clearly stating the tool's function. However, it does not explicitly distinguish itself from the closely related sibling 'list_firewall_groups', so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: the tool is meant to be used when a user needs to see all firewall rules. There is no explicit guidance on when to prefer this tool over alternatives like 'list_firewall_groups' or when not to use it, but for a simple list tool the implication is sufficient.
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 state that the operation is read-only, what 'cached' means, or what happens if no firmware versions are found. The description simply restates the action without providing deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 8 words, front-loading the action and resource. It contains no fluff and is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an existing output schema, the description adequately covers the core functionality. However, it omits the meaning of 'cached' versus 'available', which is a notable gap that could affect correct invocation. This prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the parameter 'firmware_type' with a default of 'available' and a description of the allowed values. The tool description repeats these values ('available or cached') but does not explain their meaning or impact on results. Since schema coverage is 100%, the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'firmware versions' with a specific scope 'available or cached on the controller'. This distinguishes it from sibling tools like list_health or list_dashboard by explicitly mentioning the firmware 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/5
Does 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 alternative list_* tools. It does not mention when to choose 'available' vs 'cached', nor does it state any prerequisites or exclusions. The only implied usage is derived from the tool name and description, which is insufficient.
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 disclose behavioral traits on its own. The verb 'Fetch' implies a read-only operation, but the description does not explicitly confirm safety, mention side effects, pagination, or error behavior, leaving the agent with limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description provides the core purpose and filtering capability. However, it lacks explicit guidance on scope limitations or alternatives, so it is not fully complete, but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's single parameter route_id is fully described with 100% coverage, so the baseline is 3. The description adds that filtering is optional, which reinforces the schema but does not introduce new parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'static routing settings', clearly distinguishing it from sibling tools like list_settings or list_networks. The optional route ID filter is mentioned, making the tool's scope precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as list_settings or custom_api_request. It does not state exclusions or mention sibling tools. Given many similar list_* tools, 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.
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 the default behavior of returning records from the past 7 days, which is useful. However, it omits other behavioral aspects like pagination, ordering, or whether the records are filtered by anything else, so it provides minimal but non-zero 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters and an output schema, which explains return values. The description covers the core purpose and default behavior, making it adequate for most uses. However, it lacks usage context or exclusions, which is a minor gap given the available sibling complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two optional parameters 'start' and 'end', so the baseline is 3. The description adds a small semantic note about the default time range (past 7 days), which clarifies how the default null values are interpreted, but it doesn't provide additional per-parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch authorization records' with a specific verb and resource, which distinguishes it from sibling tools like stat_sessions or list_clients. However, it doesn't elaborate on what exactly constitutes 'authorization records,' so it's clear but not maximally distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. The description only mentions the default time range ('Defaults to past 7 days'), which is behavioral rather than usage context. There are no explicit when/when-not conditions or alternative tool names.
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 disclose behavioral traits. It only mentions the API version and optional filters, but does not state that the operation is read-only, whether permissions are needed, what counts as 'active', or any rate limits/pagination behavior. The verb 'List' implicitly suggests a read operation, but this is insufficient for full 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the main action and resource. There is no redundant phrasing, and every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the core purpose is clear. However, the description leaves gaps: it does not define 'active' clients, does not explain how this relates to similar list tools, and does not mention what the response contains beyond the output schema. These gaps are moderate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both boolean parameters, so the baseline is 3. The description's phrase 'traffic and device filters' is a high-level summary that adds no new detail beyond the schema's parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('active clients'), and the optional filter dimensions. The 'active' qualifier distinguishes this from sibling tools like list_clients and list_clients_history, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving active clients, but it does not explicitly state when to use this tool instead of alternatives such as list_clients or stat_client. No exclusions or comparison guidance is provided, so the usage context is only partially clear.
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 full burden for behavioral disclosure. It conveys that the operation is read-only in nature via the word 'List' and clarifies the 'currently online' status, but it does not disclose potential limitations (e.g., behavior when MAC is not found), authentication requirements, or rate limits. This is acceptable but minimal for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the core purpose immediately and efficiently conveys both the default list behavior and the optional single-client lookup in 14 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, and the schema and output schema provide structured context. The description covers the main behavior and adds the 'currently online' nuance. It is not fully complete because it omits usage differentiation from siblings, but it is otherwise sufficient for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'mac' parameter with 100% coverage. The description adds semantic value by explaining that the MAC is used to 'fetch a single client', which clarifies that this is not a filter but a direct lookup. This extra context justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('clients'), with the additional scope of 'currently online (connected)' and optional single-client fetch by MAC. However, it does not distinguish itself from the sibling tool 'list_active_clients', which appears to serve an identical purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It neither mentions when to prefer list_clients over list_active_clients, list_clients_history, or stat_client, nor does it state any exclusions or prerequisites. Given the large number of sibling list tools, this is a significant gap.
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 burden. The verb 'fetch' implies a read-only operation, and 'current site' adds useful scope. However, it does not disclose auth requirements, whether data is live or cached, or what specific metrics are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no unnecessary words. It communicates the essential purpose and scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and an existing output schema, the description is functional. However, it lacks guidance on when to use this tool among many related list_ and stat_ tools, and 'dashboard metrics' is somewhat vague without further detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, including a description for 'five_minutes'. The tool description itself adds no extra parameter semantics, but the baseline of 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetch'), the resource ('dashboard metrics'), and the scope ('current site'). This is a specific verb+resource pair that distinguishes it from siblings like list_health or stat_sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 any exclusions or prerequisites mentioned. The description simply states what it does without context on selection.
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 full responsibility. It does not disclose any behavioral traits such as pagination, sorting, output format, permissions, or data scope, leaving the agent without additional operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is appropriately concise for a simple list operation, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no annotations, but has an output schema), so the description's one-liner is sufficient for basic understanding. The output schema covers return values, so the description does not need to explain them. Some context about whether 'all' means system-wide or site-scoped could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter details to add. The baseline of 4 applies because there is no need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the exact resource 'hotspot operators', which clearly states what the tool does. It distinguishes itself from sibling tools like list_users and list_admins by naming a unique entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It offers no context, prerequisites, or exclusions beyond a restatement of the tool's basic function.
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?
The description implies a read-only operation by using the verb 'Fetch', but it does not mention authentication requirements, potential response size, or any side effects. With no annotations, the description carries the full burden of behavioral disclosure, and it falls short of explicitly stating safety or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence with no redundant information. It is well-structured and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the availability of an output schema, the description covers the core functionality. However, it does not explain how this 'full status' differs from the related stat_sysinfo, leaving some contextual ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema is an empty object, so there are no parameter semantics to clarify. The description accurately reflects the no-parameter nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Fetch) and identifies the resource (full controller status), clarifying it as system information. However, it does not distinguish between this tool and the sibling stat_sysinfo, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like stat_sysinfo or list_health. The description only states what it does, not when it should be selected.
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 clarifies that 'non-archived' means 'active,' which is helpful. However, it does not disclose default behavior explicitly (that all alarms are counted by default), nor does it mention scope, pagination, or whether the count is global or scoped. This is a simple read operation, so the lack of side-effect warnings is acceptable, but more context would improve 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It contains no wasted words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count tool with one optional parameter and an existing output schema, the description is adequate. The schema covers the parameter fully, and the description conveys the tool's purpose. It does not explain return values, but the output schema handles that. Slight deduction for not explicitly stating default behavior, but it is inferable from the parameter description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the archived parameter is fully described with its default and behavior. The description adds a synonym ('active' for 'non-archived') but does not significantly expand on the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Count alarms.' This is a specific verb+resource pair that distinguishes it from sibling tools like list_alarms, which likely list alarm details rather than provide counts. The clarification about optionally counting only non-archived (active) alarms 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 Guidelines2/5
Does 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 such as list_alarms. It implies a use case for counting alarms but does not mention exclusions or direct the user to a sibling tool for different needs (e.g., detailed alarm listing).
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 disclosing behavior. It only states that it returns a mapping, implying a read-only operation, but adds no context about potential edge cases, whether the mapping is static, or whether any network requests are made. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key verb and resource. It wastes no words and is immediately understandable. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with an output schema, the description is nearly complete: it states what is returned (a mapping) and the data's nature (device state codes to names). It could still benefit from a hint about why this mapping exists or when it is typically used, but given the output schema fills in return structure, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (100% coverage). The baseline for 0 parameters is 4, and the description correctly focuses on the return value rather than parameters. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('a mapping of device state codes to human-readable names'). This clearly distinguishes it from sibling list tools like list_devices or list_health, which return device lists or health statuses. 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that this is a simple lookup for decoding state codes, nor does it direct users to other tools for different needs. There is no explicit or even implied 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 provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists guest devices within a time window, but provides no additional context such as whether results are read-only, paginated, or require authentication. The simple 'list' verb implies a read operation, but deeper behavioral traits are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the core action and scope. It avoids redundancy and unnecessary details, making it efficiently front-loaded with all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description provides sufficient context for an AI agent to understand its basic function. It does not explain return values, but the output schema covers that. A minor gap is the absence of any behavioral notes (e.g., whether it only includes guests currently online), but the level of completeness 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full (100%) coverage for the single 'within' parameter, including its type, default value, and description. The tool description's phrase 'specified time window' maps directly to this parameter but adds no new semantic detail beyond what the schema already provides. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure: 'List guest devices' clearly identifies the action and the target object. The scope is precisely qualified with 'seen within the specified time window,' which distinguishes it from similar list tools like list_devices or list_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning the time-window filtering capability, suggesting it is appropriate when listing guest devices over a specified period. However, it does not explicitly state when to use this tool over alternatives or mention exclusions, so it falls short of clear usage guidance.
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?
Annotations are absent, so the description must carry full behavioral disclosure. It only states the scope ('current site') and that it lists accounts, with no mention of read-only nature, authentication requirements, pagination, or anything beyond the obvious. The description adds minimal value 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the action, resource, and scope. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter tool, the description covers the essential context: what is listed and for which scope. An output schema exists, so return-value details are not needed. It is complete enough but could benefit from a note on whether all account states are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed. The 'current site' scope is a fixed behavior rather than a tunable parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('List') and resource ('RADIUS user accounts') with a specific scope ('current site'). This distinguishes it from sibling tools like list_users or list_radius_profiles, which target 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/5
Does 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. The description only states the function and scope without mentioning exclusions, alternatives, or prerequisites, leaving the agent to infer usage from the name and 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 burden. It discloses the read-only nature via 'Fetch' and the scope (wired/wireless, time window), but lacks details on whether users are unique, pagination behavior, or query limits. The existence of an output schema covers return format, but deeper behavioral nuance is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any filler or repetition. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no nested objects, output schema exists), the description adequately covers purpose and scope. However, it does not provide guidance on when to prefer this over sibling tools, and lacks exclusionary context, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter historyhours is fully documented in the schema with its default and explanation. The description's 'specified time window' aligns with this parameter but does not add additional meaning beyond the schema. With 100% schema coverage, baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Fetch') + resource ('all users') + scope ('wired and wireless', 'within the specified time window'). This distinguishes it from sibling tools like list_users (likely static) and stat_client (single user).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use instructions or alternative tool mentions. It implies a time-window-based query but does not compare with siblings such as list_active_clients or list_clients_history. The user must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the tool name by specifying that it returns basic attributes (_id, desc, name), which gives the agent a concrete understanding of the response. With no annotations provided, this disclosure of return payload is valuable. However, it does not explicitly state read-only behavior or any limitations, though the verb 'List' strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes exactly the necessary details. There is no wasted language or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, output schema available) and the description's inclusion of return fields, it is fairly complete. The only gap is the lack of differentiation from 'stat_sites', but that is more of a usage guideline issue than a completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric the baseline is 4. The description reinforces that there are no required inputs, and with schema description coverage at 100% (empty schema), there is nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('all sites managed by this UniFi controller'). It is unambiguous and easy to understand, but it does not differentiate itself from the sibling tool 'stat_sites', which could be interpreted as the stats variant of site listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'stat_sites'. The description simply says what the tool does, but offers no context about when it is appropriate or when another tool should be used.
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 transparency burden. The verb 'get' clearly indicates a read-only operation, and it's a simple fetch by ID. However, it does not disclose any failure behavior, auth requirements, or whether it may return null/error for missing IDs. For a trivial getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description adequately conveys what it does and its scope. It does not explain when to use it over list_tags, which is a minor gap but not critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter tag_id as 'Tag _id', which is very clear and matches the description's 'by ID'. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'device tag' and scope 'by ID'. It clearly distinguishes from sibling list_tags, which lists all tags rather than retrieving a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by ID' implies this should be used when a specific tag ID is known, but it does not explicitly mention when to use it versus list_tags or any other alternatives. No exclusions or context are provided, leaving the usage somewhat implied.
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 behavioral traits. It only states the basic action and scope, with no mention of authentication requirements, rate limits, or any edge-case behavior. The description is minimal and lacks transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that starts with the verb, providing the essential information without any filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For such a simple tool with no parameters and an output schema available, the description is sufficiently complete. It includes the useful 'across all sites' scope qualifier, but could have explicitly mentioned that this is the global variant of 'list_admins' for additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for this dimension is 4. The description does not need to explain any parameter meaning since there are none, and it does not add any confusing parameter-related information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'admins' and the scope 'across all sites', clearly indicating the tool's function. This differentiates it from the sibling 'list_admins' by explicitly stating the global scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all sites' implies the tool is for a global admin listing, but there is no explicit comparison to alternatives like 'list_admins' or any when-not-to-use guidance. Usage is implied rather than directly 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 carries the full burden of behavioral disclosure. It only says 'list', which implies a read-only operation, but it does not disclose potential delays, authentication requirements, empty results, or other behaviors. The description is safe but lacks meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and contains no unnecessary words. Every word adds informational value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description is mostly complete. The output schema covers return values, and no complex behavior needs explaining. However, 'auto-backups' could be more specific about what is being backed up, though this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed. The schema coverage is 100% (trivially). The description adds no parameter semantics, but none are required; the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available auto-backups' clearly states the verb (list) and the resource (auto-backups). It distinguishes this tool from all sibling tools, none of which mention backups, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent needs to list auto-backups, but it provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The usage is self-evident from the name and description, but there is no additional context.
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 present, so the description carries the full burden. The verb 'Fetch' implies a read-only operation, which is a minimal behavioral disclosure. However, it does not mention potential latency, authentication needs, or whether results are real-time or cached, which would be helpful for a no-annotation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains no redundant words. It is front-loaded with the action and the resource, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is largely complete for an agent to understand its function. It lacks usage context or alternative guidance, but for a straightforward listing tool, this is adequate. The output schema covers return values, so the description doesn't need to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline for 0 params is 4, and the description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a precise resource 'currently allowed wireless channels', making it clear what the tool does. While it doesn't explicitly name alternatives, the resource is unique among siblings and inherently distinguishes this tool from the many other list_* 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/5
Does 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. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without context for selection.
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. However, it simply states the action with no mention of authentication requirements, pagination, scope limitations, or any side effects. For a list operation, this lacks important 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the tool's purpose without unnecessary words or repetition. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, output schema present), the description is largely sufficient. It clearly states what the tool does, though it could be slightly enhanced by clarifying the scope of 'static DNS records' (e.g., global vs. per-site), but this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter semantics since none exist, but this is acceptable given the no-parameter nature of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all static DNS records', which clearly distinguishes it from other list tools in the sibling set such as list_routing or list_settings. This makes the tool's 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool lists DNS records, but it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. No sibling alternatives are referenced.
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 transparency burden. It clearly states the two operation modes (list all or get by ID), which implies a read-only operation, but it does not explicitly mention lack of side effects, pagination, or error behavior. This is adequate for a simple list tool but leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant elaboration. It efficiently conveys both core actions while leaving parameter details to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one optional parameter, and includes an output schema, so the description covers the essentials. It lacks explicit guidance among the many sibling list tools, but the resource specificity and dual-mode description are sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for network_id. The description's phrase 'by ID' merely restates what the schema already says ('Optional network _id to fetch a specific network') without adding new syntax, defaults, or edge-case details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses clear verbs ('List', 'get') and names the resource ('network configurations', 'specific network'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling list tools like list_devices and list_users by focusing specifically on network configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its resource name, but it provides no explicit when-to-use guidance, exclusions, or alternatives. With many sibling list tools, an agent would benefit from a note such as 'for device states use list_devices', but such context is absent.
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 convey safety and behavioral traits. 'Fetch' implies a read-only operation, and the description clearly indicates the return focuses on the current user, but it does not explicitly state side-effect-free behavior, authentication prerequisites, or output details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the essential purpose without redundancy. It is front-loaded and efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is sufficient to understand the core functionality. It doesn't elaborate on the exact fields returned, but the output schema fills that gap, so the description need not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the empty schema provides complete coverage. Per the rubric, zero parameters warrant a baseline of 4; the description naturally adds no parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the target resource ('information about the currently logged-in user'), which distinguishes it from sibling tools like list_users that list all users. The resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The self-referential name implies it for the current user, but the description does not mention any context 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?
With no annotations, the description carries the full burden. The verb 'List' implies a read-only operation, and 'all' clarifies the scope, but no further behavioral traits (e.g., auth requirements, response format) are disclosed. This is adequate for a simple list tool but not information-rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence that directly states the purpose. It is perfectly concise, front-loaded, and contains zero superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's extreme simplicity (no params, no nested objects, output schema present), the description is largely complete. It lacks only usage guidance, which is already penalized under usage_guidelines, so this dimension is otherwise well-served.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which is the baseline for a score of 4. The description adds no parameter details because there are none to describe, and the schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('all device tags'), distinguishing it from sibling tools like list_devices or get_tag. The inclusion of 'all' indicates the full scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 any exclusions or prerequisites. The description simply states what it does without contextualizing usage, which 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.
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 full burden. It clearly implies a read-only operation ('List') and an optional filter, but it does not disclose any additional behavioral traits such as pagination, authentication requirements, or response details. This is adequate for a benign list tool but lacks extra context that could be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action and adds the optional ID variant using an 'or' clause. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no required fields, output schema provided), the description is nearly complete. It only misses a brief positioning note about related tools like list_wlan_groups, and does not clarify whether additional filters or pagination are supported, leaving a minor context gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter has a full description), so the baseline is 3. The description's 'get a specific WLAN by ID' adds no new meaning beyond the schema's own parameter description, which already explains the optional ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List WLAN configurations (wireless networks), or get a specific WLAN by ID.' It uses a specific verb ('List') and resource ('WLAN configurations'), and distinguishes itself from sibling tools like list_wlan_groups by focusing on configurations rather than groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The optional ID parameter implies when to use the tool (list all vs. get specific), but no explicit guidance is given about when to choose this over alternatives like list_wlan_groups or list_networks. There are no exclusions or alternative recommendations.
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 disclose behavioral traits. It only states the action without mentioning whether it is read-only, requires authentication, or has any side effects, leaving the agent without essential safety 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys purpose with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the lack of annotations and behavioral context (e.g., authentication needs) leaves minor gaps. It is adequate for a basic list operation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List), resource (admins), and scope (current site), which distinguishes it from the similar sibling 'list_all_admins' that likely covers all sites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for the current site' provides a clear context for when this tool is appropriate, but it does not explicitly mention alternatives or exclusions, so it stops short of full 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?
With no annotations, the description carries the burden. 'List all AP groups' implies a read-only operation and tells the agent there is no filtering (all groups are returned). However, it does not explicitly confirm safety, auth requirements, or potential rate limits, leaving some ambiguity for a simple list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. Every word earns its place, delivering the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, an output schema, and a clear purpose—the description is complete. An agent can invoke it correctly based solely on 'List all AP groups.' The output schema covers return values, and there is no need for additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add. Per the rubric, 0 params sets a baseline of 4, and the schema coverage is 100% vacuously. The description correctly omits parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all AP groups.' uses a specific verb (List) and resource (AP groups), clearly stating what the tool does. It naturally distinguishes from sibling tools like list_wlan_groups and list_user_groups by explicitly naming the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like list_wlan_groups or list_user_groups. The description gives no context for selection among the many list_* siblings, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 comprehensive device information including model, firmware, uptime, configuration, port tables, radio tables, and statistics, which is useful context. It does not mention potential side effects or prerequisites, but as a read-only listing operation, the described behavior is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by a concise summary of returned data. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is only one optional param and an output schema exists, the description is nearly complete. It explains the main behavior and key return categories. However, it lacks explicit notes on limitations (e.g., maximum number of MACs, pagination) and error conditions, which would improve completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes 'macs' as 'Optional list of MAC addresses to filter by'. The description merely restates this with 'optionally filtered by MAC address(es)' without adding syntax, format, or additional meaning, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'List' and resource 'devices' with scope 'full detail' and optional filter by MAC addresses. It clearly distinguishes from siblings like list_devices_basic by emphasizing full detail and from other list_* tools by focusing on devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use when you need full device details or want to filter by MAC address(es). However, it does not explicitly name alternatives like list_devices_basic or provide exclusions, so guidance is not 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. It only says 'List all RADIUS profiles' and does not disclose pagination, output format, authentication needs, or any side effects. This lack of behavioral detail limits 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with an output schema, the description adequately states the action and scope. It could mention how the current site is derived, but overall it is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description is not required to add parameter detail. The baseline of 4 applies, and the empty schema is consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all RADIUS profiles for the current site, with a specific verb and resource. The resource 'RADIUS profiles' distinguishes it from sibling tools like list_radius_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by scoping to the current site, which implies when to use it. However, it does not explicitly name alternatives or state when not to use, but the scope is sufficient for a list operation.
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 the scope (all known clients, including offline) but does not mention authentication, rate limits, or other behavioral traits. Some useful context is provided, but it is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It immediately states the action, the target, and a key differentiator (including offline devices).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description sufficiently defines the scope and target. The minor mismatch between the name 'list_users' and 'client devices' is not misleading given the clear description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. Baseline 4 applies because no parameter semantics are needed; the description does not have to compensate for any gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all known client devices' and explicitly notes inclusion of offline devices, distinguishing it from siblings like list_active_clients. This makes the tool's 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (retrieving all clients regardless of online status) but does not explicitly state when to use this tool over alternatives such as list_clients or list_active_clients. No direct comparison or exclusion is provided.
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, the description carries the full burden. It discloses a key behavioral trait: results are returned only if the scan has completed, otherwise progress is returned. This goes beyond simple read-only semantics, though it does not cover error cases or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, followed by return value note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter status check, the description provides the purpose and return behavior. It is adequate, though it could mention the context of scan initiation or error handling for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with a clear description of 'mac' as the AP MAC address. The description adds no additional parameter semantics, but schema coverage is complete, so baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with a clear resource ('state of an RF spectrum scan') and specifies the target ('for an access point'). It also describes the return behavior, distinguishing it from sibling list/stat 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to determine the status of a spectrum scan, but it does not explicitly state when to use it versus alternatives or any prerequisites (e.g., after initiating a scan). No exclusions or alternative tool references are 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 disclosing behavior. The verb 'Fetch' implies a read-only operation, which is safe. However, it doesn't mention what happens if the MAC is not found, whether there are authentication requirements, or any rate limits. This is a minimal viable disclosure but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence (10 words) with no redundant phrasing. It gets straight to the point, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter, an output schema exists, and the operation is a straightforward read. The description is sufficient for an agent to understand what the tool does. It lacks explicit guidance on when to prefer this over similar stat tools, but given the low complexity and available output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'mac' is fully provided ('MAC address of the client to look up'), so schema coverage is 100%. The tool description adds no further meaning beyond restating the parameter's purpose. It doesn't specify the expected format (e.g., colons, dashes) or any default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch'), the resource ('detailed statistics for a single client'), and the required qualifier ('by MAC address'). This distinguishes it from sibling tools like list_clients or stat_allusers, which either list clients or fetch statistics for all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need detailed stats for one specific client identified by MAC address. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough that an agent would understand this is for a targeted lookup, not a bulk list.
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 the default time window, which is a behavioral trait, but does not mention whether the operation is read-only (though 'fetch' implies it), result ordering, or any potential rate limits. It is minimally transparent but lacks richer 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the action front-loaded. Every word earns its place—no filler, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two optional parameters and an output schema, the description covers the essential default behavior. It does not explain ordering or time zone handling, but these are not critical for a simple fetch, and the output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (start/end timestamps) with 100% coverage. The description adds that omitting these parameters defaults to the past 24 hours, which clarifies behavior beyond the schema alone—valuable for an agent deciding whether to pass parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action on a specific resource: 'Fetch speed test results.' This is distinct from sibling tools like stat_sysinfo or stat_sessions, and the additional default time window provides useful scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that the tool defaults to past 24 hours, implying typical use for recent data, but it does not explicitly mention when to use this versus alternatives or provide exclusions. With no overlapping siblings, usage is implied rather than explicitly guided.
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 states the operation is a list, implying read-only and non-destructive behavior, and mentions the optional filter. However, it does not disclose any additional behavioral traits such as result ordering, pagination, or potential side effects, which is acceptable for a simple 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It clearly communicates the action and the optional filter without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is sufficient to understand its purpose and usage. No edge cases are apparent from the schema, and the inherently safe nature of a list operation reduces the need for extensive behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description of the only parameter (create_time) with 100% coverage, so the description's mention of optional filtering adds little new meaning. It correctly restates the optionality but does not go beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('hotspot vouchers'), clearly stating the tool's function. The optional filter by creation time adds specificity, and no sibling tool overlaps with voucher listing, so it is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is the tool for listing hotspot vouchers, with an optional creation time filter. No alternatives or exclusions are mentioned, but since there are no overlapping sibling tools, explicit comparison is unnecessary.
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 full burden. 'Fetch' implies a read-only operation, and the ISO standard adds detail, but it does not explicitly confirm safety, authentication needs, or lack of side effects. For a simple zero-param tool, this is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Fetch', and includes only essential information (the ISO standard). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, but an existing output schema), the one-line description fully conveys the tool's purpose. The output schema handles return value details, so nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. Per the rule, 0 params earns a baseline of 4. The description adds no parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fetch') with a clear resource ('available country codes') and adds a precise standard ('ISO 3166-1 numeric'). This distinguishes it from sibling list tools, which focus on network devices, users, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or exclusions are mentioned, but the description implies usage when country codes are needed. The uniqueness among siblings makes the intended context clear, though not explicitly stated.
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 burden. It discloses the read-only nature by saying 'List' and the conditional behavior based on group_id, which is useful. However, it does not mention authentication needs, error handling, or pagination, though these are less critical for a simple list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, front-loaded with the primary action and with no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description covers the essential behaviors. It is sufficiently complete for the low complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes group_id as 'Optional firewall group _id', but the description adds meaning by clarifying the two modes: omit to list all, or provide to get a specific group. This goes beyond the schema's basic parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('firewall groups'), clearly distinguishing it from sibling tools like list_firewall_rules or list_wlan_groups. It also covers the secondary behavior of fetching a single group by ID, which 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need firewall groups, use this tool. However, it does not explicitly mention when to use this over alternatives or provide exclusions. Given the many sibling list tools, explicit differentiation would have improved this dimension.
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's 'Fetch' indicates a read-only operation and the 'current site' scoping is useful. However, it does not disclose whether special authentication is required, what 'health metrics' encompasses, or whether the response shape varies; the word 'fetch' implies no side effects but doesn't explicitly state it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that starts with the action verb and immediately states the object and scope. Every word adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema present, the description provides sufficient context: it names the operation (fetch), the resource (health metrics), and the scope (current site). The output schema covers return structure, so no additional description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds contextual scope ('current site') but has no parameter semantics to clarify; per the rubric, the baseline for a no-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' plus a resource ('health metrics') and explicitly scopes to 'the current site'. This clearly distinguishes it from sibling tools like list_dashboard or stat_full_status, which suggest broader or different metric surfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving health metrics for the current site, but it offers no explicit guidance on when to prefer it over sibling list/stat tools or when an alternative is more appropriate. It provides a clear use context (current site health) but no exclusions or alternatives.
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 burden for behavioral disclosure. It adds context (detected by managed APs, time window) but does not explicitly state read-only nature, authentication needs, or pagination behavior. As a list tool, the non-destructive nature is implied but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word earns its place. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), full schema coverage, and presence of an output schema, the description is complete. It provides enough context for the agent to understand the tool's scope and behavior without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'within' is already well-described in the schema. The description only reinforces the time-window concept without adding new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'List rogue (neighboring) access points detected by managed APs.' It distinguishes from siblings like list_known_rogue_aps by specifying 'not part of your UniFi deployment.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (identifying neighboring APs not in the deployment) and the time-window parameter. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It adds value by outlining the types of statistics returned, but it does not mention potential side effects, performance implications (e.g., data volume for many sites), authentication needs, or any caveats. As a read-only fetch operation, the risk is low, but the description omits these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes a concise list of the statistics covered. Every word contributes meaning with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an existing output schema, the description sufficiently communicates its scope and return highlights. It explains enough for an agent to know what data to expect and that it covers all sites, making it complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty (100% coverage trivially). Per guidelines, 0 params earns a baseline of 4. There are no parameter details to clarify, so no additional description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and names a clear resource: 'statistics for all sites on this controller.' It also enumerates the types of statistics (number of devices, clients, guests, health info), which effectively distinguishes it from sibling tools like list_sites (site listing) and list_health (health-only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need comprehensive statistics for all sites. However, it provides no explicit guidance on when to prefer this over similar tools like stat_full_status or list_health, nor does it mention any exclusions or alternative conditions. This falls under implied usage rather than clear directives.
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 uses 'Fetch' to imply a read-only operation and discloses a key invocation constraint (site context not required). However, it does not explicitly state side-effect status, authentication needs, or return format beyond what the output schema provides, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then adds a concise scope note. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and the output schema exists, the description covers the essential invocation context (what it fetches, site context not needed). It could slightly elaborate on what a 'device name mapping' represents, but overall it is complete enough for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific details, but none are needed. The note about site context effectively clarifies that no site parameter is required, which is helpful for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('device name mappings') with a clarifying parenthetical ('firmware bundles'), clearly distinguishing it from sibling list tools like list_devices or list_device_states. It also adds a scope note about site context, which further pinpoints its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Does not require site context,' providing clear context that this tool can be invoked without site-level parameters. It does not explicitly name alternatives or exclusions, but the context note is a useful usage signal in an API where many list tools may require site context.
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 transparency burden. It states the action and purpose, and even provides token acquisition instructions. However, it does not disclose potential side effects (e.g., whether an existing token is overwritten, whether the token is persisted across sessions, or if it requires specific permissions). This is sufficient for a simple tool but leaves some behavioral nuances unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action and purpose. The subsequent instruction for obtaining the token is relevant and clearly structured. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete: it states the purpose, provides usage criteria, and includes token acquisition steps. An output schema exists, so return values are not the description's responsibility. A minor gap is that it does not mention anything about session persistence or the token's lifespan, but this is not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'token' is already well-described in the schema (JWT string starting with eyJ...). The description adds meaningful context beyond the schema by instructing how to obtain the TOKEN value from the browser's DevTools, which helps the agent understand the real-world source of the value. This goes beyond the schema's formal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Set or update') and resource ('browser TOKEN cookie for authentication'). It distinguishes this tool from the many list/stat siblings by focusing on a unique action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Use this when authentication fails or no token is configured.' This clearly indicates the appropriate context. It does not explicitly state when not to use it, but the condition is self-evident, and no alternative tools exist among siblings for auth token management.
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 present, so description carries the full burden. It discloses that the tool combines multiple endpoints and provides default time ranges, which is useful. But it omits any mention of result size, pagination, or performance implications, leaving some transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences. The first states the purpose; the second delivers the default time ranges. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and there are no annotations, the description covers the tool's purpose, entity types, and default ranges, which is sufficient for most use. It could be more complete with an explicit statement about start/end interplay or entity-specific notes, but overall it is comprehensive enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default time ranges associated with each period value, which enriches the semantics of the 'period' parameter beyond the schema's simple type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'periodic statistics for site, AP, user, or gateway', and distinguishes itself from siblings by noting it combines all stat report endpoints into one tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context that this tool combines all stat report endpoints, implying it should be used over individual stat_* endpoints, and gives default time ranges that inform when to use with certain periods. However, it does not explicitly list exclusions or alternatives, so it lacks a definitive when-not-to-use statement.
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?
Without annotations, the description carries the burden of disclosing behavior. It adds useful context about the filtering (previously identified and marked as known), which is beyond the tool name. However, it does not explicitly state read-only nature, auth requirements, or potential side effects (though 'List' implies read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action. Every sentence contributes meaning: the first states the action, the second clarifies the scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, list operation), the description is complete. It clearly states what is returned and the filtering logic. The presence of an output schema means return values need not be detailed in the description. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is perfectly 100%. With 0 params, the baseline is 4, and the description rightly adds no parameter information since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists known rogue access points, using a specific verb ('List') and a resource ('known rogue access points'). It further distinguishes from sibling tool list_rogue_aps by specifying these are previously identified and marked as known in the controller, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it returns rogue APs that have been previously identified and marked as known. It implies the tool is for known/identified rogue APs rather than a general list, but it does not explicitly mention alternatives or exclusions (e.g., 'use list_rogue_aps for all APs').
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 burden. It discloses that the tool returns 'basic properties only,' is 'lightweight,' and is 'Faster than list_devices().' This conveys the reduced scope and performance advantage, which are useful behavioral traits not inferable from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences. The first sentence delivers the core purpose and scope, and the second adds relevant detail about the content and performance. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with an output schema, the description is complete. It states what the tool does, what fields are included, and how it differs from a sibling. The presence of an output schema covers return structure, so the description needs no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so there are no parameter semantics to clarify. Per the rubric, a 0-parameter tool earns a baseline of 4, and the description adds no conflicting or unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List all devices with basic properties only.' It also distinguishes itself from the sibling tool list_devices by explicitly noting that it returns a lightweight subset and is faster, making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use this tool: when a lightweight, fast device list is needed, explicitly comparing to list_devices(). However, it does not explicitly state when to choose the alternative (e.g., when full attributes are needed), so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![unifi_internal_api_mcp MCP server](https://glama.ai/mcp/servers/sevaepsteyn/unifi_internal_api_mcp/badges/card.svg)](https://glama.ai/mcp/servers/sevaepsteyn/unifi_internal_api_mcp)

Score Badge

Copy to your README.md:

[![unifi_internal_api_mcp MCP server](https://glama.ai/mcp/servers/sevaepsteyn/unifi_internal_api_mcp/badges/score.svg)](https://glama.ai/mcp/servers/sevaepsteyn/unifi_internal_api_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/sevaepsteyn/unifi_internal_api_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server