Server Quality Checklist

Tool Scores

• unifi_infoB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, which the description reinforces with 'Read'. It adds no extra behavioral context such as response format, authentication needs, or consoleId handling beyond what the schema provides. No contradiction with annotations.

  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 very concise, using a single line plus a bullet for the operation. It is front-loaded with the resource name. However, the operations list is redundant with the schema's enum, making it slightly less efficient, but still 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 is simple with one operation and two parameters, and there is no output schema. The description gives the essential purpose but omits details about what 'Application Info' contains or how to interpret the response. This is adequate for a simple read-only tool, but lacks enrichment.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptions for both parameters (consoleId and operation), including enum values. The description adds no semantic meaning beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the resource as 'UniFi Network application info' and the operation as 'Get Application Info', establishing a specific verb+resource. It distinguishes itself from sibling tools like unifi_devices or unifi_sites by targeting general application info, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when retrieving application info via the 'get' operation, but provides no explicit when-to-use or alternatives guidance. No mention of consoleId requirements in cloud mode appears only in the schema, not in the description, so usage context is minimal.

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

• unifi_wifi_broadcastsA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark this as destructiveHint=true and readOnlyHint=false, but the description goes further by labeling delete as 'Destructive' and stating it 'requires confirm: true'. It also discloses pagination behavior and list result structure, which adds transparency beyond the annotation flags.

  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 front-loaded with the purpose and operation list, followed by concise pagination/filtering reference and a pointer to unifi_spec. It is dense but well-structured, with no filler sentences. Slightly long due to technical details, but each section earns its place.

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

  Completeness4/5

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

  Given the tool's complexity (5 operations, 10 params, pagination, filtering) and lack of output schema, the description covers the operation list, pagination contract, filter syntax, and confirm requirement. It appropriately delegates request-body schemas to unifi_spec, though that is a slight gap for full self-sufficiency.

  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 100% coverage with parameter descriptions, so baseline is 3. The description adds significant extra semantics by explaining the filter expression syntax (functions like eq, contains, and combinators and/or/not) and the pagination shape (offset, limit max 200, count, totalCount). It also clarifies that request bodies should be fetched via unifi_spec, which goes beyond the schema's generic 'body' description.

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

  Purpose5/5

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

  The description clearly states 'WiFi broadcasts (SSIDs) configuration' and explicitly enumerates five operations (list, create, delete, get, update) with read/create/destructive markers. This gives the agent a specific verb-resource pairing and distinguishes it from sibling tools like unifi_networks, unifi_devices, etc., which target different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides operational details (pagination, filtering syntax, confirm requirement) but does not explicitly state when to use this tool versus alternatives like unifi_networks or unifi_supporting. The context is clear enough for an agent to infer its purpose, but the description lacks explicit exclusions or alternative tool references.

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

• unifi_specA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description adds the return value content (request-body, path/query parameters, response schema). It does not disclose error behavior or limitations, but for a read-only lookup this is acceptable.

  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?

  Three sentences, front-loaded with the primary action, then return value, then usage guidance. Every sentence is purposeful with no filler.

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

  Completeness4/5

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

  The tool has one parameter and no output schema. The description explains what it returns and when to call it. It could mention error handling or explicitly scope coverage across all unifi_* tools, but the core information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the description reinforces parameter format with a concrete example ('operation: "unifi_networks.create"'). This adds value beyond the schema, clarifying the exact dot-separated format.

  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 reads the committed vendor API contract and returns exact schemas for any operation of sibling unifi_* tools. It distinguishes itself from siblings by being a meta-lookup, with a concrete example of the operation format.

  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?

  Explicitly instructs to call this tool before create/update/action operations, providing clear when-to-use guidance. It does not explicitly mention when not to use or name alternatives, but as a unique meta-tool the guidance is sufficient.

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

• unifi_vouchersA
  4.2/5.0
  Behavior5/5

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

  The description goes well beyond the annotations by labeling each operation as Destructive/Read/Create, explicitly stating that destructive ops require confirm:true and "change or remove live configuration," and detailing the list response pagination structure. This directly complements the readOnlyHint=false and destructiveHint=true annotations.

  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 well-structured with bullets and sections, making the dense information about operations, pagination, filtering, and spec reference scannable. It is appropriately sized for the complexity, though slightly dense in the filter-details portion.

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

  Completeness4/5

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

  Given the tool's complexity (5 operations, 9 parameters, no output schema), the description covers operations, pagination, filtering, and points to unifi_spec for request-body shapes. However, it does not document response shapes for get/generate/delete operations, which would be valuable since no output schema is provided.

  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?

  All 9 parameters are already described in the input schema with usage hints, so the baseline is 3. The description adds extra value by defining the full filter grammar (property.function, operators, string quoting, like patterns) and directing users to unifi_spec for body shapes, enhancing parameter understanding beyond the schema.

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

  Purpose4/5

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

  The description clearly identifies the tool's purpose as managing hotspot vouchers and enumerates its five operations (list, get, generate, delete, delete_by_filter). It does not explicitly distinguish from sibling tools, but the resource scope is unambiguous within the UniFi context.

  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?

  Provides operational usage guidelines: destructive operations require confirm:true, list pagination parameters (offset/limit), filter expression syntax, and direction to call unifi_spec for request-body shapes. It does not mention when to use this tool over alternatives, but the domain is clear and the guidance for using the tool is substantial.

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

• unifi_firewall_zonesA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate destructive behavior; the description adds valuable context by labeling delete as 'Destructive' and requiring 'confirm: true', with the confirm parameter warning that actions 'change or remove live configuration'. This goes beyond the annotation without contradicting it.

  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 dense but well-structured, using line breaks to separate operations, pagination, and filtering. Every sentence contributes useful information, with no fluff, though it is slightly long due to the complexity of the filtering section.

  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?

  Without an output schema, the description explains list result shape and directs users to unifi_spec for request-body schemas. It covers pagination, filtering, and operation usage. It could mention return values for other operations, but overall it is sufficiently complete for the tool's complexity.

  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?

  Input schema covers 100% of parameters, so baseline is 3. The description enriches this by explaining filter function syntax (eq, ne, like, contains, etc.) and pagination field structure, adding meaning beyond the schema's simple 'Used by' notes.

  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 enumerates five distinct operations (list, create, delete, get, update) with specific verbs and the resource 'Firewall Zones'. This provides strong differentiation from sibling tools that operate on other UniFi resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear operational context such as pagination structure, filter syntax, and the confirm requirement for delete. However, it does not explicitly state when to use this tool over alternatives like unifi_firewall_policies, so it lacks explicit exclusion or alternative guidance.

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

• unifi_acl_rulesA
  4.4/5.0
  Behavior4/5

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

  Even though annotations already mark destructiveHint=true and readOnlyHint=false, the description adds valuable behavior: paginated list results with offset/limit, detailed filter expression syntax, and the convention that request-body shapes are retrieved via unifi_spec. It also explicitly flags delete as requiring confirm: true. No contradiction with annotations.

  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 compact but information-dense, using a bulleted operations list, a short paragraph on pagination, and a focused paragraph on filtering. It ends with a necessary reference to unifi_spec. Every sentence earns its place and the most important information (operations) is front-loaded.

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

  Completeness4/5

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

  For a multi-operation tool with 9 parameters and no output schema, the description covers the full operation list, pagination, filtering, and the path to get request bodies. It does not explicitly state return shapes for non-list operations, but the unifi_spec pointer likely covers those, so the description is sufficiently complete for effective use.

  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 already provides descriptions for all 9 parameters (100% coverage), so the baseline is 3. The description goes further by explaining the filter expression grammar (property.function(args), combining with and/or/not, supported functions, quoting rules) and by pointing to unifi_spec for body schemas, which adds meaningful semantics beyond the bare 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 opens with 'ACL rules and their ordering' and lists all seven operations with explicit action verbs (List, Create, Reorder, Delete, Get, Update), clearly identifying the tool's scope. It distinguishes from sibling tools by explicitly managing ACL rules rather than firewall policies or DNS policies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for each operation, including a note that delete requires confirm: true, and explains when list, create, get_ordering, update_ordering, delete, get, and update are appropriate. However, it does not explicitly compare with sibling tools or state exclusions (e.g., 'use unifi_firewall_policies for firewall rules'), so it falls just short of a 5.

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

• unifi_devicesA
  4.4/5.0
  Behavior5/5

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

  The description goes beyond annotations by classifying each operation as Read, Create, Destructive, or Admin, and clearly flagging any destructive or admin actions as requiring confirm:true. It also details pagination behavior and filtering semantics, giving a fuller picture of the tool's effects.

  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 long but well-structured with a clear operations list and grouped information for pagination, filtering, and request bodies. Every section serves a purpose, though some details (e.g., filter grammar) could arguably live in a sub-spec without loss.

  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 description covers list/filter/pagination well and references unifi_spec for request bodies, but it leaves some operation behaviors underspecified (e.g., execute_action vs execute_port_action) and does not describe return shapes for non-list operations. A complex multi-operation tool would benefit from a bit more detail or a pointer to output specs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline value. The description adds meaning by explaining the filter expression grammar (eq, like, contains, etc.), pagination structure, and confirm semantics, complementing the schema's per-parameter notes.

  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 this tool manages UniFi devices, listing eight concrete operations (adopt, remove, get, statistics, etc.) with a title summarizing the scope. This distinguishes it from sibling tools like unifi_clients or unifi_sites.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context on when to use this tool (device operations) and explicitly directs users to unifi_spec for request-body shapes, which is helpful complementary guidance. It lacks explicit when-not-to-use alternatives, but the resource focus is unambiguous.

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

• unifi_supportingA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: the pagination format (offset, limit, count, totalCount, data[]) and the detailed filtering grammar. This helps the agent understand how results are returned and how to construct filters.

  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 well-structured: a short title, a bullet-like list of operations, then pagination and filter details. Every sentence earns its place, and the organization makes it easy to scan. There is no redundant or filler content.

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

  Completeness4/5

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

  Given the tool has 8 operations and no output schema, the description covers the common pagination contract and filtering mechanics. It does not detail per-operation return fields, but for a read-only list utility with consistent pagination, this is adequate. The schema covers parameter applicability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% but the description adds significant meaning to the 'filter' parameter by explaining the expression syntax (property.function(args), combining with and/or/not, supported functions, string quoting, like patterns). This goes beyond the schema's simple reference to 'see tool description'.

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

  Purpose5/5

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

  The description clearly identifies the tool as 'Supporting resources (countries, DPI, device tags, RADIUS, VPN, WANs)' and enumerates eight concrete list operations with (Read) indicators. This distinguishes it from sibling tools like unifi_devices or unifi_sites, which target specific resource types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by listing all operations and explaining pagination and filtering syntax. It does not explicitly mention when not to use this tool or name alternatives, but the operation names and resource categories make the intended use obvious.

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

• unifi_traffic_matching_listsA
  4.4/5.0
  Behavior4/5

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

  Annotations already flag the tool as destructive (destructiveHint: true). The description adds valuable behavioral context: delete requires confirm: true, list results are paginated with specific fields, and the filter DSL is fully specified. This goes beyond what annotations provide, but it doesn't cover potential side effects of create/update 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?

  Though lengthy, the description is well-structured and every section earns its place: operation list, pagination, filter DSL, and pointer to unifi_spec. It is front-loaded with the operation summary and then provides necessary details without fluff.

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

  Completeness4/5

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

  The description thoroughly covers the list operation's response shape and the filtering system, and it tells agents how to get request-body schemas. However, it does not describe the return values for get/create/update/delete operations, and there is no output schema to fill that gap. This leaves some ambiguity for those operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds substantial meaning beyond the schema: it explains the full filter expression grammar (functions, combinators, quoting, like patterns) and documents pagination semantics. It also clarifies that the body parameter for create/update should be retrieved via unifi_spec, which helps agents construct valid requests.

  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 resource ('Traffic matching lists') and enumerates specific operations (list, create, delete, get, update) with verbs. This distinguishes it from sibling tools that target different UniFi resources, and the operation list makes its scope immediately clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for each sub-operation (read vs. destructive) and instructs that delete requires confirm: true. It also directs users to unifi_spec for request-body shapes, acting as a pointer for complex parameters. However, it does not explicitly mention when to use this tool over sibling tools, though that is reasonably implied by the resource-specific name.

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

• unifi_sitesA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds substantial behavioral details including pagination response shape (offset, limit, count, totalCount), max limit of 200, and a comprehensive filter expression language with functions, combinators, quoting, and escaping rules.

  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 well-structured and front-loaded, but contains minor redundancy by repeating the annotation title and using an 'Operations:' header for a single operation. The information density is high, but slightly less crisp than ideal.

  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?

  With no output schema, the description fully compensates by explaining the paginated response structure. It covers all essential aspects: operation, pagination, filtering, and cloud-mode targeting, making it complete for a list operation with rich filtering.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds crucial semantics for the filter parameter, defining the full filter syntax and escaping rules. This is essential for using filter correctly and far exceeds the schema's minimal 'see tool description' note.

  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 (Read): List Local Sites' with a specific verb and resource. The tool name 'unifi_sites' and sibling context make it distinct from other UniFi resource tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance on when to use this tool vs alternatives. The description implies it is for listing sites, but lacks exclusions or alternative tool references. The cross-reference to unifi_consoles for consoleId provides minor contextual guidance.

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

• unifi_switchingA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'read-only views' and 'Read' labels. Beyond annotations, it adds pagination envelope details and a comprehensive filter expression grammar, which are substantial behavioral disclosures.

  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 moderately long but well-structured with a purpose line, operation list, and separate explanations for pagination and filtering. Each section earns its place given the tool's complexity, though it could be slightly tighter.

  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 scope (six operations, pagination, filtering) and absence of an output schema, the description covers essential usage context: operation names, page envelope, filter grammar, and read-only nature. It leaves little ambiguity about how to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes each parameter's purpose and usage, but the description adds critical semantics for the filter parameter by explaining the full expression syntax (functions, combinators, string quoting, wildcards). It also clarifies pagination defaults and max limits, going beyond schema descriptions alone.

  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 'Switching read-only views (LAGs, MC-LAG domains, switch stacks)' and then lists six specific read operations. This explicitly names the resource types and distinguishes the tool from sibling tools focused on devices, networks, clients, etc.

  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 scopes the tool to switching resources via its title and operation list, but it does not explicitly name when to prefer this tool over siblings or when not to use it. However, the read-only and domain-specific framing provides implicit guidance.

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

• unifi_firewall_policiesA
  4.6/5.0
  Behavior5/5

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

  The description provides rich behavioral context beyond the annotations: it labels each operation by type (Read/Create/Update/Destructive), explicitly warns that delete 'requires confirm: true' and that these operations 'change or remove live configuration,' and details pagination behavior and filter expression syntax. The destructiveHint annotation is true, and the description aligns with it without contradiction.

  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 well-structured with a concise operation list followed by necessary details on pagination, filtering, and confirm behavior. It is longer than a single-sentence description, but the tool has eight operations and several shared parameter conventions, so the length is justified. Each sentence contributes actionable information; no filler is present.

  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 complexity (8 operations, 11 parameters, no output schema), the description covers all essential aspects: operations, request-body guidance, pagination, filtering syntax, confirm requirements, and site/console targeting. It also references unifi_consoles for console ID discovery. The description is self-sufficient for an agent to invoke this tool correctly, making it contextually 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 input schema already describes every parameter with 100% coverage, so the baseline is 3. The description adds meaningful value by explaining the filter expression grammar (functions like eq, like, in, plus logical combinators), pagination defaults (offset 0, limit 25 max 200), and directs users to unifi_spec for exact request-body schemas. This goes beyond the schema descriptions, especially for the 'filter' and 'body' 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 opens with 'Firewall policies and their ordering' and then enumerates eight specific operations (list, create, get_ordering, etc.), each with a clear verb and resource. This precisely defines the tool's scope and differentiates it from sibling tools like unifi_acl_rules and unifi_firewall_zones by explicitly targeting firewall policy management and ordering.

  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 enumerates operations and their associated HTTP semantics (Read, Create, Update, Destructive), and gives explicit guidance for using the 'confirm' parameter with delete. It also directs users to unifi_spec for request-body shapes, effectively telling them when to use unifi_spec as a supporting tool. It does not explicitly state when to use this tool over alternative firewall-related tools, but the operation list makes the domain unambiguous.

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

• unifi_clientsA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses that execute_action requires confirm:true and 'changes or removes live configuration', while list/get are reads. It also explains pagination behavior and the detailed filter expression grammar, adding substantial behavioral context beyond the annotation flags.

  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 structured with bullet-style operation breakdown, pagination shape, and filtering syntax. Every sentence serves a purpose, front-loads the key operation distinctions, and avoids redundancy. The length is justified by the tool's complexity.

  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 absence of an output schema, the description covers the list return shape, filtering rules, pagination limits, and referential guidance for request-body schemas. It addresses the major usage scenarios for all three operations and integrates well with the schema descriptions, making the tool self-sufficient for invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of parameters, but the description adds essential semantics: the filter parameter's non-trivial syntax (functions, combinators, quoting, escape rules) and the pagination response shape. This goes beyond the baseline schema coverage, though the schema already explains which operations use which 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 identifies the tool's purpose: 'Connected clients (list, details, guest authorization)' and enumerates three distinct operations (list, get, execute_action) with explicit read/admin semantics. This specific verb+resource structure distinguishes it from sibling tools focused on other UniFi entities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context about when to use this tool (for listing client details, guest auth, etc.) and gives a direct pointer to unifi_spec for request-body shapes. However, it does not explicitly state when-not-to-use or name alternative tools for similar client-related tasks, so it lacks explicit exclusion guidance.

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

• unifi_consolesA
  4.7/5.0
  Behavior5/5

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

  Discloses read-only nature via operation 'list (Read)' and annotation readOnlyHint; adds cache behavior ('per-process cache' and refresh bypass) and API context ('Site Manager API'). No contradictions with annotations.

  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?

  Three compact bullet-style sections with no filler; each sentence adds context (return fields, ID usage, cache bypass).

  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?

  Despite lacking an output schema, the description lists return fields (id, name, type, ipAddress) and explains the tool's role in the broader unifi_* workflow, covering essentials for a read-only list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Both parameters are fully described in the schema (operation enum, refresh boolean). The description does not add new parameter-level details—it repeats refresh semantics and operation purpose, with no additional meaning 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 tool lists consoles visible to the API key, using 'List every UniFi console' and 'discovery only', distinguishing it from sibling tools focused on specific resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly frames this as the discovery entry point: 'Pass a returned id as consoleId to the other unifi_* tools.' It also restricts scope with 'discovery only — ADR-002', implying when not to use it.

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

• unifi_networksA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=true), description flags delete as Destructive and requires confirm:true, warns that it changes live configuration in the confirm parameter description, and documents list pagination. This adds meaningful behavior about destructive operations and response format.

  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?

  Organized into operations list, pagination, filtering, and body reference; every sentence adds needed information without repetition. Dense but 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?

  Covers list pagination and filtering thoroughly, and delete confirm requirement. However, non-list operations lack explicit return shape or field details; relies on unifi_spec. Given no output schema and 10 params, it is mostly complete but has some fallbacks.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions are present for all parameters, but the description adds deep filter grammar (functions, combining, quoting, like escapes) and response paging structure not in schema. It also directs to unifi_spec for body schemas, crucial for create/update.

  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 'Networks (VLANs/subnets) configuration' and enumerates six specific operations (list, create, delete, get, update, get_references), each with a short summary and read/destructive marker. This distinguishes it from sibling tools targeting other Unifi resources.

  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?

  Provides operational context: delete requires confirm, list returns paginated data, filtering grammar detailed, and body shapes delegated to unifi_spec. However, it does not explicitly contrast with alternative sibling tools or state exclusions; usage is implied by resource domain.

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

• unifi_dns_policiesA
  4.8/5.0
  Behavior5/5

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

  Annotations provide destructiveHint true, and the description adds critical detail: delete requires confirm to avoid accidental removal, pagination and filtering behavior are disclosed, and request-body shapes are delegated to unifi_spec. This goes well beyond the annotation and gives the agent a solid behavioral model.

  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 efficiently organized: a concise operation list, then targeted notes on pagination, filtering, and request-body resolution. Every sentence provides operational value, and there is no redundancy or filler.

  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 multi-operation tool with 9 parameters and no output schema, the description covers all aspects an agent needs: how to invoke each operation, pagination controls, filter expression grammar, and how to obtain detailed schemas via unifi_spec. It is self-sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning: filter expression syntax with examples, like pattern rules ('.', '*', '\'), page defaults (limit default 25 max 200, offset default 0), and which operations use which parameters. This significantly enriches the raw 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 tool manages DNS policies with a list of operations (list, create, delete, get, update), each with a brief purpose. The specific resource ('DNS policies') distinguishes it from siblings like unifi_firewall_policies and unifi_acl_rules.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear operation-specific usage (e.g., delete requires confirm: true, create/update need body via unifi_spec, list supports pagination/filtering). It does not explicitly name alternatives for when not to use this tool, but context is clear enough without exclusions.

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