unifi-udm-pro-mcp

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation4/5
Most tools target distinct resource-action pairs, and the descriptions clarify their purpose. A minor overlap exists between update_wlan and set_wlan_password, but the quick-update intent of the latter reduces confusion.
Naming Consistency5/5
Every tool follows the consistent `unifi_verb_noun` snake_case pattern. Verbs like list/get/create/update/delete/set are used predictably, making the surface easy to navigate.
Tool Count2/5
With 43 tools, the server is well beyond the 25-tool threshold typically considered manageable. While the UniFi domain is broad, this many tools risks overwhelming agents and increases selection difficulty.
Completeness3/5
The set covers most core workflows for WLANs, networks, devices, and clients. However, firewall rules, firewall groups, port forwards, and user groups lack update or delete operations, creating dead ends for management flows.
Average 3.4/5 across 43 of 43 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 4 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Create a new network subnet / VLAN' with no details on side effects, idempotency, permissions, or potential conflicts (e.g., duplicate subnets). This is effectively a tautology of 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks any structure or additional detail, making it insufficient for a create operation with multiple parameters. Conciseness should not come at the cost of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 2 required, no annotations, no output schema, and no parameter descriptions. The description only covers the basic action, omitting required parameters, input formats, expected behavior, and return values. It is critically incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the four parameters (name, ip_subnet, vlan, purpose). The phrase 'subnet / VLAN' hints at ip_subnet and vlan but provides no format, constraints, or relationships between parameters, leaving the agent to guess.
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 'Create a new network subnet / VLAN' uses a specific verb and resource, clearly indicating a create operation for network subnets/VLANs. It distinguishes from sibling update/delete/list tools, though it does not explicitly contrast with create_wlan for wireless networks.
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 create_wlan or update_network. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that this is a create operation, but fails to mention potential side effects (e.g., whether it overwrites existing rules), required permissions, limits on port ranges, or what happens on success/failure. The agent is left guessing about the tool's real-world impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It omits all parameter context and guidance, making it nearly as minimal as a tautology. A good concise description should still convey essential usage details, which this lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with no schema descriptions, no annotations, and no output schema. Given this complexity, the description is completely inadequate—it does not explain parameter semantics, required inputs, potential errors, or expected return values. An agent cannot safely invoke this tool based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The parameter names (fwd, fwd_port, dst_port, proto) are cryptic to agents unfamiliar with UniFi networking. Without additional semantic context, the agent cannot reliably map values to fields or understand the distinctions between 'fwd' and 'dst'.
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 (create) and resource (port forwarding rule), making it distinct from sibling tools like unifi_list_port_forwards and unifi_delete_port_forward. However, it does not elaborate on the specific type or scope of port forwarding, leaving some ambiguity about its exact functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as unifi_create_firewall_rule or unifi_create_network. The description does not mention prerequisites, typical use cases, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It only says 'create', which is already implied by the tool name, and offers no additional details about side effects, required setup, or what happens on success. This is minimal and fails to disclose any meaningful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than efficient conciseness. It omits essential information about parameters and behavior, making it inadequate for a tool with five parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a write operation with five parameters, no annotations, and no output schema. The description fails to explain valid values for 'action' or 'ruleset', the relationship between addresses, or any other context. It is fundamentally incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the five parameters (name, action, ruleset, dst_address, src_address). It provides no explanation of what these fields mean or how they should be populated, leaving the agent entirely dependent on schema property names.
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 (create) and the resource (firewall rule), distinguishing it from sibling tools that create other entities like firewall groups or networks. The verb and noun are 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?
The description gives no indication of when to use this tool versus alternatives, nor any context about prerequisites or typical use cases. It simply states the action without any guidance on selection or invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'update configuration' without explaining whether unspecified fields are overwritten, whether the WLAN must exist, or whether the operation is reversible. This lack of detail is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, with no wasted words. However, it is extremely terse and could be considered under-specification rather than efficient conciseness.
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?
Given 4 parameters, no annotations, no output schema, and overlapping sibling tools, the description is incomplete. It does not describe return values, effects on unlisted fields, or how it differs from unifi_set_wlan_password/status, leaving an agent without sufficient context to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must compensate for the undocumented parameters. It only clarifies that wlan_id is the identifier, leaving name, enabled, and x_passphrase without any added meaning beyond their names.
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 ('Update'), resource ('configuration of an existing Wi-Fi network'), and identifier ('by WLAN ID'). It is specific enough to understand the tool's basic function, but it does not differentiate from overlapping sibling tools like unifi_set_wlan_password or unifi_set_wlan_status, which also modify WLAN 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?
No guidance is provided on when to use this tool versus alternatives such as unifi_create_wlan, unifi_delete_wlan, unifi_set_wlan_password, or unifi_set_wlan_status. The description implies the WLAN already exists, but there is no explicit 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits, but it only states the core action without mentioning side effects (e.g., disconnecting connected clients), permission requirements, password validation rules, or reversibility. It is not misleading, but it is largely non-transparent about consequences and 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 concise sentence with no wasted words. It is appropriately front-loaded and easy to parse. While more detail could be added, the structure is efficient and clear.
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?
This is a mutation tool with no annotations and no output schema, and the description provides only minimal functional information. It lacks usage guidelines, parameter clarifications, and behavioral side effects. Given the existence of a similar sibling (unifi_update_wlan), the description is insufficient for an agent to confidently select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain the parameters. It clearly indicates that 'password' is the new WPA passphrase, but it does not explicitly explain that 'wlan_id' is the identifier of the target Wi-Fi network or how it should be obtained (e.g., from 'unifi_list_wlans'). The phrase 'a Wi-Fi SSID network' vaguely implies the target but does not map to the parameter name.
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 ('update WPA passphrase') and the resource ('a Wi-Fi SSID network'), making the tool's purpose specific and understandable. However, it does not explicitly distinguish this tool from the sibling 'unifi_update_wlan', which could also potentially update WLAN settings, so it lacks explicit sibling differentiation.
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 'unifi_update_wlan'. It does not mention prerequisites, typical scenarios, or situations where this tool should not be used. The implied usage is for changing a Wi-Fi password, but this is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning idempotency, name uniqueness, permissions, or side effects. This leaves key operational details undisclosed.
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 wastes no words. It is appropriately concise for the simple action it describes.
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?
For a create tool with three parameters, no annotations, and no output schema, this description is too sparse. It lacks parameter explanations, expected return behavior, and any caveats, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the parameters. The schema has no descriptions, and the term 'bandwidth rate-limiting' only hints at the purpose of qos_rate_max_up/down. An agent must guess the meaning, units, and relationship of these 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 a specific verb ('Create') and identifies the resource ('user group') with a clear qualifier ('bandwidth rate-limiting'). This clearly distinguishes it from sibling tools that list, update, or delete user groups.
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 given on when to create a new user group versus reusing an existing one, nor how it relates to tools like unifi_set_client_usergroup. The use case is implied by the description, but there is no mention of alternatives or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a creation action but does not disclose side effects, required permissions, quota implications, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 core purpose efficiently.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is underspecified. It lacks return-value expectations and parameter semantics, making it inadequate for fully informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention parameters at all. It fails to clarify the meaning of 'count', 'quota', or 'minutes', leaving the agent with only parameter names.
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 action ('Create') and resource ('guest hotspot Wi-Fi vouchers'), distinguishing it from sibling tools like list_vouchers and revoke_voucher. The verb-resource combination 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?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It is a bare statement with no contextual or comparative information.
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 the obvious (that it creates an SSID) but does not mention side effects like whether the network becomes immediately active, whether duplicate names are rejected, permission requirements, or idempotency behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded and easy to parse. However, it is so minimal that it borders on under-specification; the sentence earns its place but leaves much unsaid.
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 tool has 4 parameters, no output schema, and no annotations. The description only covers the core action, leaving out important details like required fields, passphrase constraints, and behavior of boolean flags. An agent would need additional documentation or trial-and-error to invoke this correctly. This is not 'complete enough' for autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not. The schema exposes 'name', 'enabled', 'is_guest', and 'x_passphrase', but the description adds no meaning. 'x_passphrase' is particularly obscure—it likely means the Wi-Fi passphrase, but this is left to inference. An agent cannot correctly construct a call without guessing parameter intent.
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 'Create a new Wi-Fi SSID network' uses a specific verb ('create') and a clear resource ('Wi-Fi SSID network'). It distinguishes this tool from siblings such as unifi_update_wlan and unifi_delete_wlan, and even clarifies that it creates a WLAN rather than a general network (which unifi_create_network might do).
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 like unifi_update_wlan or unifi_set_wlan_password. It does not mention prerequisites, such as whether a site must be selected, or exclusions, such as not using this for guest networks if is_guest is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions nothing about reversibility, whether blocking affects existing connections, permission requirements, or that it pairs with unifi_unblock_client to undo the action.
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 redundant words. It promptly conveys the core purpose and is appropriately concise for a simple tool.
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?
For a mutating tool with no annotations and no output schema, the description is too minimal. It lacks essential context such as whether the block is reversible, how it affects network access, and any prerequisites or side effects, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not add meaningful parameter semantics. Saying 'by MAC address' merely restates the parameter name 'mac' without adding format, validation, or other constraints 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 action ('Block'), the resource ('a client device'), and the specific method ('by MAC address'). This distinguishes it from sibling tools like reboot, upgrade, and the opposite unifi_unblock_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, prerequisites, or consequences. The description only states the action itself, 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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds minimal context by specifying 'new' (implying no overwrite) and 'IP or Port' (clarifying group type), but it does not mention permission requirements, duplicate name handling, idempotency, or what the response contains. This is insufficient for a create 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 nine words, containing no filler or repetition. Every word earns its place, and the key information (action and group type) is front-loaded.
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?
For a tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It does not explain the group_type values, the structure of group_members, or any usage context. While it is not completely useless, it leaves too much uncertainty for an agent to invoke the tool correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints that group_type distinguishes IP vs Port groups, which is useful, but it says nothing about the name parameter or the expected format of group_members (e.g., array of strings, CIDR notation, port ranges). This is a significant gap for a tool with only three 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 the action (create), the resource (firewall group), and the two possible group types (IP or Port). It distinguishes this tool from siblings like unifi_create_firewall_rule, which creates a rule rather than a group, and unifi_list_firewall_groups, which lists existing groups.
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 creating a firewall rule, nor does it mention prerequisites or relationships with other firewall tools. It simply states what the tool does, leaving the agent to infer usage context from the tool name and siblings.
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 states the action without disclosing side effects, irreversibility, permission requirements, or any impact on dependent resources. It doesn't even explicitly warn that deletion is permanent.
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, succinctly stating the action and the key. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too sparse. It does not provide caveats, prerequisites, or what happens on success/failure. The tool is simple, but the lack of behavioral context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter network_id with no description (0% coverage). The phrase 'by ID' clarifies that the parameter is the identifier of the network to delete, but does not explain the format, how to find the ID, or any validation rules. This adds minimal value beyond the parameter name.
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 'Delete' with a clear resource 'network subnet / VLAN' and identifies the key by ID. This clearly distinguishes it from sibling tools like delete_wlan or delete_firewall_rule.
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 or any prerequisites or alternatives. It does not mention conditions like network being unused, or any related list/create 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 carries the full burden of behavioral disclosure. It states 'Delete' which implies destructiveness, but it does not disclose consequences such as whether the deletion is permanent, disconnects clients, or requires specific permissions. This is a minimal level of transparency for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded with the verb and resource, with no extraneous words or redundancy. Every word contributes to clarity.
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?
For a one-parameter tool with no annotations or output schema, the description is technically sufficient to state the action, but it lacks critical context for an agent: safety implications, prerequisites, or how to retrieve the WLAN ID. The description is too sparse to be considered complete for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It does reference 'WLAN ID' which names the parameter, but it does not explain what the ID looks like or how to obtain it. The added meaning is minimal beyond the schema's type and property name.
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: 'Delete a Wi-Fi SSID network by WLAN ID.' It uses a specific verb ('Delete') and resource ('Wi-Fi SSID network'), and the 'by WLAN ID' distinguishes it from other WLAN operations like create, update, or list. This unambiguously identifies the tool's 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 usage guidance is provided. The description does not mention when to use this vs. alternatives (e.g., using unifi_set_wlan_status to disable rather than delete), nor does it advise obtaining the WLAN ID from unifi_list_wlans. The agent is left without contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source of behavioral info. 'Fetch' implies a read-only operation, but the description does not disclose whether events are ordered, paginated, or rate-limited.
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, making it optimally concise.
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 tool is simple but the description omits any discussion of the limit parameter or return payload, and there is no output schema or annotations to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never mentions the 'limit' parameter, leaving the agent to guess whether it caps the number of results or sets a time window.
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 identifies the resource as 'recent network events, client connects/disconnects, and security alerts', which clearly distinguishes it from sibling list tools like unifi_list_alarms or unifi_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 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 choose this tool over siblings such as unifi_list_alarms, nor does it mention prerequisites, exclusions, or alternate 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 provided, the description carries the full burden of disclosing side effects. It states 'assign' which implies a mutation, but does not explain whether the change is persistent, reversible, or whether it affects the client's DHCP settings. It also does not mention any required client state or potential impacts on the network.
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, straightforward sentence that is front-loaded with the core action and target. There is no unnecessary verbosity or filler, making it extremely concise and easy to parse.
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?
Given the tool's mutating nature, lack of annotations, and absence of an output schema, the description is too sparse. It does not cover return behavior, side effects, parameter explanations, or any caveats, leaving significant gaps for an agent attempting to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (mac, ip, use_fixed_ip) or their roles. The tool name hints at the IP and fixed IP concept, but the parameter semantics are entirely left to the schema's bare type definitions, which is insufficient for a 3-parameter 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 clearly states the tool's function: 'Assign a static/fixed IP address to a client device on the network.' It uses a specific verb (assign), specifies the resource (client device), and the target (IP address), making it distinct from sibling client tools like unifi_set_client_name or unifi_block_client.
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 used when a fixed IP address needs to be assigned to a client, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or edge cases. The purpose is clear enough to infer basic usage, but there is no explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a mutating action but fails to mention potential side effects, persistence, or whether existing client sessions are affected.
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 redundant words. It is appropriately sized for the tool's simplicity.
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 description is incomplete for a mutation tool with no annotations and no output schema. It lacks context about how to source wlan_id, idempotency, or any operational caveats, making it insufficient for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description barely adds meaning beyond the schema. It implies 'enabled' toggles the SSID state, but it does not explain 'wlan_id' or the relationship between the 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: 'Enable or disable a Wi-Fi SSID network on demand.' This distinguishes it from sibling tools that create, update, or delete WLANs, as it focuses solely on toggling the enabled state.
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 unifi_update_wlan, which might also modify the enabled state. It does not specify prerequisites like obtaining a wlan_id via unifi_list_wlans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a destructive action ('Revoke/Delete') but does not mention irreversibility, required permissions, side effects on active guest sessions, or any other consequences beyond the immediate action.
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 one concise sentence, front-loaded with the action and target. No unnecessary words or repetition of the tool name.
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 destructive tool with one parameter and no output schema, the description covers the core action and parameter. However, it lacks behavioral context such as consequences, prerequisites, or error handling, which leaves some gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (voucher_id) with no description (0% coverage). The description says 'by ID', which clarifies that the parameter is the voucher identifier, but it does not explain how to obtain the ID, its format, or any other useful semantic detail. With low schema coverage, the description should compensate more.
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 ('Revoke/Delete') and a clear resource ('guest hotspot voucher') with an explicit scope ('by ID'). This distinguishes it from sibling tools like unifi_list_vouchers and unifi_create_voucher.
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 does not mention prerequisites, conditions, or how this tool relates to sibling tools such as unifi_list_vouchers or unifi_create_voucher.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it updates an existing network, but does not mention whether updates are partial or full replacement, permission requirements, side effects, or error behavior. For a mutation tool, this is insufficient.
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 filler. It is front-loaded and efficient, stating exactly what the tool does without unnecessary detail.
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?
With 3 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what happens after the update, whether unspecified fields are preserved, error cases, or any required permissions. An agent would lack critical context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It mentions 'by ID' and 'network subnet / VLAN', giving some context for network_id and ip_subnet, but it does not explicitly explain the name parameter. The parameter names are somewhat self-explanatory, but the description adds minimal value.
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 'Update' and identifies the resource as 'an existing network subnet / VLAN by ID'. This clearly distinguishes it from sibling tools like create_network or delete_network.
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 updating an existing network, but offers no explicit guidance on when to use it vs alternatives, nor any exclusions or prerequisites. The intent is inferred from the tool's update nature.
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 available, leaving the description to carry the full transparency burden. It only states the action without mentioning significant behavioral traits, such as potential device reboot, downtime, or that a firmware upgrade is a disruptive, potentially lengthy operation. This is a critical omission for a mutation-like 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 sentence with no superfluous words. It is front-loaded with the action and target, making it highly efficient and easy to parse.
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?
Odd this is a simple tool with one parameter, but firmware upgrades have important operational implications (e.g., device downtime, duration, risk of failure). The description does not cover these aspects, and since there is no output schema, the description should have provided this context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only adds that the MAC address identifies the device. It does not provide format expectations (e.g., colon-separated), validation rules, or clarify whether any special policies apply. The added meaning beyond the parameter name is minimal.
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 'Trigger' and identifies the resource ('firmware upgrade') and target ('UniFi device by MAC address'). This clearly distinguishes it from sibling tools like reboot or locate, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (upgrading a device's firmware) but does not explicitly state when to prefer this tool over alternatives like unifi_reboot_device or unifi_locate_device. No exclusions or prerequisites are provided, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action ('power cycle/restart') and the PoE context, but it does not disclose the disruptive impact on the connected device, required permissions, expected downtime, or whether the action is reversible. This leaves significant behavioral traits unstated for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no wasted words. Every part of the sentence adds value: 'Power cycle (restart)' defines the action, 'PoE switch port on a UniFi Switch' defines the scope, and 'by device MAC and port index' names the required parameters.
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 two-parameter tool, the description covers the essential purpose and targets, making it minimally viable. However, because there is no annotation or output schema, the description could add useful context such as port indexing convention, prerequisites, or side effects. These gaps prevent it from being fully complete, though the tool's inherent simplicity keeps the score above 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare input schema. It names both parameters ('device MAC and port index'), but provides no additional semantics such as MAC format, whether port_idx is 1-based, or how to discover valid values. This is only marginal improvement over the parameter names in 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 uses a specific verb 'Power cycle (restart)' and clearly identifies the resource as 'a PoE switch port on a UniFi Switch', distinguished from sibling tools like unifi_reboot_device which reboots the whole device. It also specifies the key identifiers (device MAC and port index), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by clearly stating the target (a PoE switch port) and the required identifiers, but it does not explicitly contrast with alternatives or state when not to use it. There is no mention of using unifi_list_devices to obtain the MAC or of preferring whole-device reboot in other scenarios, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the action 'Assign' but does not reveal side effects such as overwriting existing user group assignments, whether the client must be online, or any permissions required. This lack of detail makes the mutation behavior insufficiently 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?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core action and object, earning a perfect score for conciseness and structure.
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 tool has no annotations, no output schema, and zero schema coverage. The description only states the action, not prerequisites, expected results, or how to source the IDs. For a mutation tool, this is incomplete, as the agent is left without guidance on what happens after invocation or how to prepare inputs.
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 has no descriptions for its two parameters, so the description must compensate. It adds meaning by mapping 'client device' to user_id and 'User Group' to usergroup_id. However, it doesn't specify that these IDs are obtained from other tools (e.g., unifi_list_clients, unifi_list_user_groups), leaving room for ambiguity. The description adds value but does not fully resolve parameter semantics.
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 ('Assign'), the resource ('client device'), and the object ('bandwidth rate-limiting profile (User Group)'). It distinguishes from sibling tools like unifi_set_client_name and unifi_block_client by specifying the rate-limiting aspect, making the tool's unique purpose evident.
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: to assign a bandwidth profile to a client. However, it does not explicitly contrast with alternatives (e.g., unifi_block_client) or mention prerequisites like creating a user group first. There is no exclusionary guidance, so the usage context is implied but not fully articulated.
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 of disclosing behavior. It states the delete action and target, but does not mention permanence, failure conditions, or side effects. The action 'delete' is explicit, but additional context like irreversibility is not provided.
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 front-loads the action. It is concise with no wasted words, achieving high clarity and efficiency.
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 delete with one parameter, the description is functional but lacks any mention of prerequisites, error handling, or return values. It is adequate for a basic tool but leaves gaps for a mutation operation with no annotations or output schema.
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 has only rule_id with no description, and schema coverage is 0%. The description adds 'by ID', clarifying that the parameter is the identifier of the firewall rule. This is helpful but minimal; it does not explain format or source.
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 (delete), the resource (firewall rule), and the method (by ID). It effectively distinguishes from sibling tools like list, create, and update firewall rules.
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, prerequisites, or exclusions. While the name and siblings imply usage, the description itself provides no explicit context or alternatives, which is a gap for a mutation tool.
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 burden. It only states 'Delete,' which implies destructive action, but it does not disclose whether the deletion is permanent, what permissions are required, or what happens if the ID does not exist. The description lacks context about side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the action, resource, and parameter. No filler or redundant information. It is appropriately structured and front-loaded.
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 (one parameter, no output schema), so the description does not need to explain return values. However, it omits prerequisites (e.g., needing to list port forwards first), success/failure indicators, and any side effects. It is minimally complete but leaves gaps for an agent to infer.
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 provides no description for pfwd_id (0% coverage), and the parameter name already indicates it is an ID. The description adds the context that this ID identifies the port forwarding rule to delete, which is helpful but minimal. It does not explain the format or how to obtain the ID, so it only partially compensates for the schema 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 ('Delete') and resource ('port forwarding rule') and identifies the method ('by ID'). It clearly distinguishes this tool from siblings like unifi_list_port_forwards and unifi_create_port_forward, 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?
Usage is implied: you would delete a port forward by its ID. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., unifi_list_port_forwards to find the ID), nor are any prerequisites or exclusions mentioned. The 'by ID' hints at needing a prior list call but does not state 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?
No annotations are present, so the description carries the full burden. The verb 'List' implies a read-only, non-destructive operation, but no explicit details about side effects, authorization, or return behavior are given. This is minimal but acceptable 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 a clear front-loaded verb and no extraneous information, making it highly readable 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?
Given the zero-parameter schema and absence of an output schema, the description adequately conveys the tool's purpose for straightforward invocation. However, it lacks any detail about the response format or potential limitations, leaving minor 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 tool has zero parameters, so the schema fully covers inputs. The description adds no parameter-specific details, which aligns with the baseline of 4 for parameterless tools.
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 specific resource 'active network security alarms and system alerts'. It distinguishes the tool from most siblings, though unifi_list_events might overlap without explicit differentiation.
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 compared to alternatives like unifi_list_events or unifi_get_sysinfo. There are no usage conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the action ('force a reconnect') but does not disclose potential side effects such as a brief network interruption, whether it requires special permissions, or what happens if the MAC is invalid. This is a mutation with no safety 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?
One concise sentence (12 words) with no filler. It is front-loaded with the verb 'Force' and clearly conveys the core action.
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 one-parameter tool with no output schema, the description covers the action and parameter. However, with no annotations, it fails to disclose the disruptive nature of forcing a reconnect, leaving an important gap for an agent deciding whether to invoke it. It is minimally viable but not fully contextual.
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 a single required 'mac' property with no schema-level description (0% coverage). The description's phrase 'by MAC address' provides minimal clarification that this parameter is the client's MAC, but it does not explain format (e.g., colon-separated) or validation rules, so it only partially compensates for the missing schema 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 'force', names the resource 'client device', and specifies the action 'reconnect to the nearest access point by MAC address'. This clearly distinguishes it from sibling tools like unifi_reboot_device or unifi_block_client.
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 (client connectivity issues) but does not explicitly state when to prefer this over alternatives like unifi_reboot_device or unifi_forget_client. No exclusions or conditions 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 must carry the burden of behavioral disclosure. It only names the action (flash LED) without addressing reversibility, side effects, prerequisites (e.g., device online/adopted), or duration. The enable parameter's role in stopping the flashing is not mentioned.
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 with no filler. It front-loads the action and provides the necessary information in a concise, well-structured manner.
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 two-parameter tool with no output schema, the description is minimally viable. It conveys the core purpose but lacks important behavioral context such as parameter semantics and side effects, leaving gaps that annotations would normally fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not explain what 'mac' or 'enable' mean. While inferable from context, the agent receives no explicit parameter semantics, and the description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (flash LED), the target (UniFi Access Point or Switch), and the purpose (locate physically). This distinguishes it from sibling device management tools, all of which involve different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description effectively implies when to use the tool (when you need to physically locate a device) and no sibling tool offers similar functionality, so the use case is clear. However, it does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It does state that the tool removes a record from the controller database and specifies the 'offline client record' constraint, which is valuable. However, it does not disclose whether the action is permanent, whether special permissions are required, or what the response indicates, leaving significant behavioral ambiguity for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 10 words, front-loaded with the action and resource. It contains no filler, redundant phrasing, or unnecessary details, earning full marks for efficiency.
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 (one parameter, no annotations, no output schema), the description covers the core operation, input type, and the 'offline' constraint adequately. However, it omits usage guidance, potential errors or prerequisites, and return format, making it minimally complete but not thoroughly contextual.
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 only provides the parameter name 'macs' as an array of strings with 0% description coverage. The description adds 'by MAC address', which confirms the semantic meaning of the input, but this is largely redundant with the parameter name. It does not explain the expected format (e.g., colon-separated vs. dash-separated) or behavior when multiple MACs are provided, offering only marginal added value.
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 action 'Forget/remove' and identifies the resource as 'an offline client record from controller database', clearly distinguishing it from sibling tools like unifi_block_client or unifi_reconnect_client. The addition of 'by MAC address' further clarifies the input method, making 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 the tool is used for removing offline client records but provides no explicit guidance on when to choose it over alternatives such as unifi_block_client or unifi_unblock_client. It lacks clear context for when forgetting is appropriate, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden for behavioral disclosure. 'List' implies a safe read operation, but the description does not disclose whether results are scoped to the current site, whether pagination is applied, or what the output structure is. It adds no details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It directly communicates the tool's purpose and is appropriately sized for a parameterless 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's simplicity (no parameters, no output schema), the description covers the core purpose. However, it does not mention what information is returned for each group (e.g., name, type, members), which could be relevant for an agent deciding whether this tool meets its needs. This is a minor gap for a 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, and the input schema is empty. The baseline for 0 params is 4, as there is nothing to describe. The description does not need to explain parameter semantics since 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 clearly states the tool lists configured firewall IP and port groups, using a specific verb ('List') and resource ('firewall IP & port groups'). It is unambiguous and distinct from sibling tools like unifi_list_firewall_rules, which list rules, not 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 description implies usage: when you need to see configured firewall groups, you call this tool. However, it provides no explicit guidance on when to use it over alternatives, nor does it mention any exclusions or prerequisites. Since it's a simple list operation, implied usage is acceptable but not clearly 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?
With no annotations, the description carries full burden. It restates the action ('Restart/Reboot') but does not disclose side effects such as client disconnection, downtime, or any system impact. It lacks detail on process, response, or safety considerations.
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, and contains no filler or redundancy. It conveys the key information efficiently.
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 tool with one parameter and no output schema, the description adequately covers the action, target, and method. However, it omits any behavioral context like expected result, error conditions, or prerequisites, which could leave the agent uncertain about the tool's full effect.
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 0%, but the description explicitly states that the device is identified 'by MAC address', giving clear meaning to the single 'mac' parameter. This compensates for the lack of schema documentation, though it does not specify format details like delimiter or capitalization.
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 (Restart/Reboot), the resource (UniFi device), the specific device types (Access Point, Switch, Gateway), and the method (by MAC address). It distinguishes from sibling tools like unifi_upgrade_device or unifi_locate_device.
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 naming the action and resource, but provides no explicit when-to-use or when-not-to-use guidance, nor alternatives. There are no exclusions or prerequisites mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Trigger a WAN speedtest' but does not disclose potential side effects (e.g., impact on network performance during the test), duration, or what the return value contains. This is a significant transparency gap for an action that may interfere with network operations.
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 of nine words: 'Trigger a WAN speedtest directly on the UDM Pro gateway.' It is front-loaded with the verb 'Trigger' and contains zero filler words. Every word provides value, making it exceptionally 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?
The tool has no parameters and no output schema, so the description must clarify the return value or outcome. 'Trigger' is ambiguous—it could mean just starting the speedtest or returning the results. The description does not state what the agent should expect as a result, leaving room for misinterpretation. For a simple action, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the input space. The baseline for 0 params is 4, and since there are no parameters to explain, the description does not need to add parameter semantics. It correctly omits any param-related 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 specific action: 'Trigger a WAN speedtest directly on the UDM Pro gateway.' It uses a specific verb ('Trigger') and resource ('WAN speedtest on UDM Pro gateway'), which uniquely distinguishes it from all sibling tools in the UniFi management suite.
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 when to use it (when you want to run a speedtest on the gateway) but does not explicitly state alternatives or exclusions. The phrase 'directly on the UDM Pro gateway' provides context that this is device-specific, but there is no guidance on when not to use it or alternative methods for measuring network performance.
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 states the basic assignment action. It does not disclose whether the alias overwrites existing names, what happens if the MAC is unknown, permission requirements, or the result/return value. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence that is front-loaded with the action and contains no redundant phrases. It earns its place with zero waste.
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 (2 params, no output schema, no annotations), the description covers the essential purpose and parameter meanings, making it minimally viable. However, it lacks behavioral details like idempotency, error handling, or whether the client must exist, which are important for an agent to invoke it correctly in all scenarios.
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 0%, so the description must compensate. It does explain that 'mac' is a MAC address and 'name' is an alias/custom display name, which adds meaning beyond the raw parameter names. However, it does not provide format constraints (e.g., MAC notation, name length limits) or clarify behavior when parameters are invalid.
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 (assign), the target (client device), the value (alias/custom display name), and the identifier (MAC address). This unambiguously distinguishes it from sibling tools like unifi_set_client_fixed_ip or unifi_set_client_usergroup.
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 the tool: to assign a human-readable name to a client identified by MAC. It does not explicitly mention alternatives or exclusions, but the clarity of 'alias or custom display name' provides sufficient context, with no misleading 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?
No annotations are provided, so the description must carry the full behavioral disclosure. It only states the action 'unblock' without revealing side effects, whether the operation is idempotent, error cases, or whether it affects the network state beyond unblocking. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no unnecessary details. It is efficient and to the point.
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 parameter and no output schema. The description covers the core action and parameter meaning, but it lacks context about prerequisites (e.g., what happens if the client is not currently blocked) and does not differentiate from reconnect in ambiguous scenarios.
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 0% description coverage, but the description explicitly states 'by MAC address', which fully explains the meaning of the single 'mac' parameter. This compensates for the lack of schema descriptions.
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: 'Unblock a previously blocked client device on the network by MAC address.' It uses a specific verb+resource structure and distinguishes itself from sibling tools like unifi_block_client and unifi_reconnect_client.
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 used when a client device has been previously blocked and needs to be resumed. However, it does not explicitly state when to prefer this over alternatives, nor does it provide exclusions or prerequisites beyond the implicit 'previously blocked' condition.
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 of behavioral disclosure. It explicitly notes 'all sites' and 'managed on this UniFi controller,' which implies a read-only, all-encompassing list. However, it does not disclose potential behavioral traits like pagination, response format, or authentication requirements, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly communicates the action ('List') and the resource ('all sites managed on this UniFi controller'). There is no redundancy or wasted words, making it optimally concise.
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, the description is mostly complete. It clearly defines the scope and action. The absence of an output schema means the return format is not specified, but the core functionality is sufficiently clear for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline for parameter semantics is 4. The description does not need to explain parameters, and it does not. This is fully sufficient for a parameterless 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 clearly states 'List all sites managed on this UniFi controller,' using a specific verb and resource. It distinguishes this tool from sibling tools like unifi_list_devices and unifi_list_clients by focusing specifically on sites within the UniFi controller 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 only states what the tool does and offers no guidance on when to use it versus alternatives. It does not mention prerequisites, exclusions, or compare with sibling list tools, leaving the agent to infer usage from the tool's 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 provided, the description must carry the full burden. The verb 'List' implies a read operation, and the returned fields are listed. However, it does not explicitly state that no modifications occur, nor does it mention authentication requirements, rate limits, or sensitivity of passphrases.
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 action and the specific data returned. Every word contributes value, with no redundancy or extraneous 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 that there is no output schema, the description lists the key WLAN attributes, serving as a partial output contract. It does not clarify whether 'all' means all sites or just the current site, nor does it mention pagination or error behavior, but for a simple list tool it is largely sufficient.
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 an empty schema. Since there are no parameters to describe, the description does not need to add parameter details. According to the rubric, a zero-parameter tool receives a baseline score of 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 'List' and clearly identifies the resource as configured Wi-Fi SSIDs, enumerating distinct attributes (passphrases, security modes, frequency bands, enabled status). This distinguishes it from sibling tools that create, update, delete, or set WLAN properties.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that it is a read-only operation or point to alternatives like unifi_list_networks or unifi_get_health. Usage is only implied by the resource name and action.
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 indicates a read-only fetch and specifies that it includes devices that have ever connected, but it does not disclose return format, potential large payloads, pagination, or other side effects. The scope detail adds some value, but more behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It avoids unnecessary words and is 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 no output schema and no annotations, the description should ideally clarify what the returned historical record contains or any operational caveats. It is minimal but sufficient for a simple read tool, though mentioning that the result could be a large list would 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 and the schema coverage is 100% (vacuously). Baseline for 0 parameters is 4; the description adds no parameter information but none 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 clearly states the action ('Fetch') and resource ('historical record of all client devices that have ever connected'). This distinguishes it from sibling tools like unifi_list_clients, which likely returns current clients, by emphasizing the historical 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 usage context is implied via the word 'historical'—suggesting it is for past records versus current clients—but no explicit alternatives or exclusions are mentioned. There is no guidance on when not to use it or mention of sibling tools.
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 implies a read-only list operation and mentions 'active connected' as a scope, but it does not define what 'active' means (e.g., real-time vs. last-seen threshold), nor does it mention pagination, rate limits, or required permissions. The field list adds some context, but behavioral traits are only lightly covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the specific output fields, with no wasted words or redundancy. It is concise and well-structured for a tool with no parameters.
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 zero parameters and no output schema, the description adequately covers the purpose and the output content via the parenthetical field list. It could be more complete with an explicit pointer to the historical or device sibling tool, but the low complexity means 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 schema is trivially complete. The description does not need to add parameter details. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description does not harm that.
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 opens with the verb 'List', names the specific resource 'active connected client devices', and enumerates the data fields (IP, MAC, hostname, signal, bandwidth, network). This clearly distinguishes it from sibling tools like unifi_list_devices (which likely lists infrastructure) and unifi_get_all_clients_history (historical).
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 'active connected' implies this is for current clients, which separates it from the historical tool. However, there is no explicit statement of when to use this tool versus alternatives like unifi_list_devices or unifi_get_all_clients_history, and no exclusions or conditions are mentioned.
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 disclose behavior. It communicates that the operation is a read-only list and specifies key output fields, but it does not mention pagination, required privileges, or any edge cases. The verb 'List' provides some basis for assuming no side effects, but deeper behavioral context is lacking.
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, front-loading the core action and then adding relevant detail about the output. It is efficiently written and 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 list operation with no parameters, the description covers the main purpose and identifies the key return fields. However, without an output schema, it only lists three fields and does not mention whether additional fields exist or whether pagination is involved, leaving some 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 has zero parameters, so the schema already fully covers inputs. The description adds value by describing output contents, which is helpful given no output schema, but no parameter-level semantics 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 states 'List configured firewall rules' with a specific verb and resource, and elaborates on the returned fields (rule numbers, action, interface bindings). It distinguishes from siblings like unifi_list_firewall_groups by focusing on firewall rules, not 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 description implies usage (when you need to view firewall rules) but does not explicitly state when to prefer this over alternatives such as unifi_list_firewall_groups or unifi_list_port_forwards. There is no mention of exclusions or prerequisites, so guidance is only implied.
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 full responsibility for behavioral disclosure. The verb 'List' indicates a read-only operation, which is a key behavioral trait, but the description does not mention potential side effects, permissions, rate limits, or response format. It adds minimal context beyond the operation 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, front-loaded sentence that packs all key information without any filler. It is concise and well-structured, with every word contributing to understanding the tool's purpose and output.
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 parameterless list tool with no output schema, the description provides a clear and fairly complete picture of what the tool returns. It covers the main network configuration attributes, though it could be more explicit about the response format (e.g., array of objects) or include use cases, but overall it is sufficient for an agent to know when and how 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 baseline is 4. The description adds meaning by specifying the exact data returned (subnets, VLANs, gateway IPs, DHCP ranges, DNS settings), which is valuable since the input schema is empty and there is no other source of semantic detail.
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 a clear resource ('configured network subnets, VLANs, gateway IPs, DHCP ranges, and DNS settings'). It clearly distinguishes this from sibling tools like unifi_list_wlans or unifi_list_devices by enumerating the exact network configuration details returned.
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 when to use the tool (when you need to view network configuration details) but provides no explicit guidance on when not to use it or how it compares to alternatives like unifi_list_wlans. There are no alternative tool references or exclusion criteria, so usage is implied rather than 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?
With no annotations, the description carries the burden of behavioral disclosure. It adds one behavioral detail by specifying 'active' (implying a filter), but it does not mention return format, pagination, or side effects. For a simple list operation 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, front-loaded sentence with no wasted words: 'List active guest hotspot vouchers.' It is perfectly concise and efficiently communicates the core 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 tool with no output schema, the description is reasonably complete. It specifies the object type and the 'active' filter. However, it does not clarify what fields are returned or the output format, which would be useful in the absence of an output schema.
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 is 4. There are no parameter semantics to explain, and the description does not need to compensate for any undocumented fields.
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 active guest hotspot vouchers' clearly states the action (list), the resource (guest hotspot vouchers), and a scope filter (active). It distinguishes from related siblings like unifi_create_voucher and unifi_revoke_voucher by specifying the list operation.
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 by the description: use when you need to view active vouchers. However, there is no explicit guidance on when to prefer this tool over other list tools or any exclusion criteria, so it meets only the 'implied usage' level.
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 responsibility for behavioral transparency. 'Get health status' clearly indicates a read-only operation, but it does not disclose whether the tool triggers a live speed test or only returns cached results, nor any other side effects or prerequisites. 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, well-structured sentence that is immediately informative. It lists the subsystems in a compact, parenthetical list without redundancy, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no annotations, and no output schema, the description should more thoroughly explain what the health status looks like (e.g., a summary object, per-subsystem metrics, or simple pass/fail). The current description lists what is included but leaves the return format ambiguous, making it incomplete for an agent that needs to interpret results.
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 shows no properties (100% coverage by definition). The description adds all necessary semantic meaning by defining the scope of health status for the listed subsystems. With no parameters to explain, a baseline of 4 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 uses a specific verb ('Get') and identifies a clear resource ('health status of UniFi UDM Pro network subsystems') with enumerated subsystem names (WAN, LAN, WLAN, VPN, ISP speed, CPU/Memory usage). This differentiates it from sibling tools like unifi_list_devices or unifi_get_sysinfo, which have distinct purposes.
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 usage for retrieving overall network health, but it does not explicitly state when to use this tool versus alternatives like unifi_run_speedtest or unifi_get_sysinfo. However, the clear scope of health subsystems provides sufficient context without exclusions, so it earns a 4.
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 clearly implies a read-only operation by using 'Get' and lists the exact data fields retrieved. It does not explicitly state 'read-only' or discuss side effects, but for a system info getter, the behavior is transparent and safe.
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 lists the key return fields without waste. Every part of the sentence carries meaning.
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 params, no output schema), the description is complete for an agent to understand what the tool does and what data it returns. No further context is necessary.
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 schema coverage is 100% (vacuously). The baseline for 0 params is 4. The description adds no parameter info because 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 uses a specific verb ('Get') and resource ('UniFi UDM Pro console system info'), and enumerates exactly what is returned (OS version, controller build, timezone, uptime). This clearly distinguishes it from siblings like unifi_list_devices or unifi_get_health.
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 when-to-use or alternatives are mentioned. The description simply states what it does; there is no guidance on when to prefer this over sibling tools like unifi_get_health or unifi_list_devices. No exclusions or context are 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 provided, the description carries the burden of disclosing behavior. It indicates a read-only list operation ('List all') and specifies the included data fields, but it does not mention potential side effects, authentication requirements, or how results are returned. The impact of this gap is limited given the tool's simple read-only nature.
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, efficiently worded sentence that front-loads the action ('List all') and immediately lists the relevant device types and attributes. No unnecessary words or 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 no-parameter list tool, the description is complete enough: it names the resource type and the main data points returned. While there is no output schema, the description provides sufficient context for an agent to understand what will be returned. Minor gaps like pagination or site scope are 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?
The tool has zero parameters, and the input schema (empty object) fully documents this with 100% coverage. No additional parameter semantics are needed, so the baseline of 4 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 the tool's purpose with a specific verb 'List' and explicitly enumerates the resource types and attributes ('access points, switches, gateways, uptime, IP addresses, and adoption status'). This distinguishes it from sibling tools like unifi_list_clients or unifi_list_wlans.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or fallback options. However, the scope is clear from context, making usage implied rather than explicit.
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 must disclose behavioral traits. 'List' implies a read-only operation, but the description does not explicitly state non-mutating behavior, authentication requirements, or return format. The added QoS context is useful but does not compensate for these omissions.
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 is front-loaded with the action and resource, and includes precise qualifiers (bandwidth rate-limiting, QoS max upload/download speed). Every word contributes to understanding.
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, the description fully specifies the resource type and purpose. Since no output schema exists, the description could mention the return structure, but 'List' implies a collection of user groups. It is adequately complete for 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 the schema is fully complete. The description's focus on the content of the list (bandwidth rate-limiting groups) adds semantic clarity beyond the empty schema. Baseline 4 is appropriate for 0-parameter tools.
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 'user groups' and adds clarifying context (bandwidth rate-limiting, QoS max upload/download speed). This distinguishes it from sibling tools like unifi_create_user_group and unifi_set_client_usergroup.
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 clearly implies the tool is for retrieving user groups and provides context about what those groups represent. It does not explicitly mention alternatives or when not to use it, but the operation is straightforward and the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'List' which conveys a read-only behavior, and the absence of side effects is implied. It also discloses the specific attributes returned, providing sufficient behavioral transparency 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 that efficiently states the purpose and return fields with no unnecessary words. Every element 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 read-only listing tool with no parameters and no output schema, the description fully covers what the tool does and what information it returns. It is complete for an agent to select and invoke correctly.
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, which is fully covered by the schema. By the baseline rule, a score of 4 applies since there is no parameter information to add.
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 ('configured port forwarding rules') and enumerates the returned fields (forwarded IP, external/internal ports, protocol). This distinguishes it from sibling tools like unifi_create_port_forward and unifi_delete_port_forward.
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 clearly implies the tool is for viewing existing port forwarding rules. It does not explicitly state when to use it versus alternatives, but the context is unambiguous given the sibling set and the list verb.
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-udm-pro-mcp MCP server](https://glama.ai/mcp/servers/rodolfoconcepcion/unifi-udm-pro-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rodolfoconcepcion/unifi-udm-pro-mcp)

Score Badge

Copy to your README.md:

[![unifi-udm-pro-mcp MCP server](https://glama.ai/mcp/servers/rodolfoconcepcion/unifi-udm-pro-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rodolfoconcepcion/unifi-udm-pro-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/rodolfoconcepcion/unifi-udm-pro-mcp'

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