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, but it only says 'Adopt a device onto a site' and defines the host format. It does not disclose that this is a state-changing operation, what the side effects are (e.g., device becomes managed by the site), whether any device state must already exist, or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well ordered: purpose first, then parameter definitions, then a concrete example that clarifies real usage. Every sentence earns its place and nothing is redundant or padded.

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

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

An output schema exists, so return values need no explanation, and parameter formats are reasonably covered. However, for a mutating tool with a nested free-form device payload and no annotations, it lacks information about prerequisites, what constitutes a valid payload, and what adoption actually changes — adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it genuinely does: host is explained as 'console name, ID, or composite ID (MAC:numericId format)', site as 'site name or ID', and device as an 'adoption payload (mac, name, etc.)' backed by a realistic example. The device object could be specified further, but the added meaning far exceeds what the empty schema strings provide.

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

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

The opening sentence 'Adopt a device onto a site' uses a specific verb and resource, making the core operation clear. It is distinguishable from related siblings like unadopt_device, approve_pending_device, and reject_pending_device through the unique 'adopt' verb and the online/site framing, though it does not explicitly name or contrast with those alternatives.

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

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

The description provides a concrete example call but gives no guidance on when adoption is appropriate versus related device lifecycle flows such as approve_pending_device or unadopt_device. There are no stated conditions, prerequisites, exclusions, or alternative routing, so an agent gets no help deciding between this tool and its siblings.

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

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

With no annotations, the description carries the full burden, and it delivers: it warns that the tool physically triggers hardware, requires an explicit confirm=true, explains enable toggling behavior, and documents delay/duration effects. This is strong behavioral disclosure for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The warning is front-loaded and every subsequent line adds semantic value. Parameter hints are compactly grouped and there is no filler or repeated schema information.

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

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

Given a physical hardware-triggering mutation with seven parameters and no annotations, the description covers safety, required identifiers, parameter semantics, and execution gating. The output schema exists, so no return-format explanation is needed, and nothing essential is missing.

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

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

Schema description coverage is 0%, but the description documents every parameter: host formats, how to source alarm_hub_id, meaning of output_id, confirm as an execution guard, enable as on/off/toggle, delay in ms, and duration with 0 meaning indefinite. It fully compensates for the schema's lack of descriptions.

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

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

The description opens with a specific verb and resource — 'Trigger an alarm-hub output' — and reinforces it with the exact HTTP endpoint. It is clearly distinct from sibling operations like relay_activate_output or list_alarm_hubs because it names the alarm-hub output trigger action.

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

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

It gives actionable context: confirm must be true to execute, alarm_hub_id should be obtained from list_alarm_hubs, and the operation is gated by UNIFI_PROTECT_MUTATIONS_ENABLED. It does not explicitly name alternative tools or when-not-to-use cases, but the route to prerequisites is clear.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that this is a live PUT to a shared port profile, explains the side effect on every switch port using the profile, states that it refuses with an error dict when confirm is False, and describes the internal read-modify-write behavior before the controller call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence adds necessary information, and the most important action is front-loaded. Parameter explanations are grouped clearly, and the remediation context is stated compactly without repetition or filler.

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

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

For a mutating tool with no annotations, the description covers prerequisites, ID sourcing, confirmation semantics, side effects, and the high-level return shape. The existence of an output schema reduces the need to detail the return structure further, so nothing essential is missing.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: host formats, site name/ID, profile_id source, network_id source, and the confirm requirement. This is exactly the guidance an agent needs to resolve otherwise opaque parameter names.

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

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

The description opens with a specific verb-resource pair ('Atomically allow (un-exclude) a VLAN network on a switch port profile') and clearly distinguishes this from the inverse operation by using 'un-exclude'. It leaves no ambiguity about what the tool does or which entity it affects.

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

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

The description gives a concrete trigger condition: use it on every profile named in a `create_network` `D12_AUTO_EXCLUSION` warning. It does not explicitly contrast this with the sibling `exclude_network_on_port_profile`, but the inverse semantics are implied by 'un-exclude' and the focused remediation use case provides clear context.

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

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

There are no annotations, so the description carries the full burden. It discloses the core state change—approving a pending device for adoption onto a site—and implies a transition from pending to approved. However, it does not clarify whether approval automatically triggers adoption, whether the action is reversible, or what side effects occur. For a state-changing tool, this is useful but not deeply transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences deliver the purpose and all parameter semantics without redundancy. The main action is front-loaded, and the parameter notes are compact and directly useful.

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

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

The tool is simple, all required parameters are semantically explained, and an output schema exists, so return-value documentation is unnecessary. The only gap is the lack of behavioral/side-effect detail for a mutation tool with no annotations, but nothing essential for selecting and invoking the tool correctly is missing.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting all three parameters: host accepts console name, ID, or MAC:numericId; site accepts name or ID; and device_id is sourced from list_pending_devices. This is actionable and goes well beyond the empty schema.

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

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

The description uses a specific action verb ('Approve') and a specific resource ('pending device for adoption onto a site'), clearly distinguishing this from sibling operations like reject_pending_device or adopt_device. It is not a tautology and immediately tells an agent what the tool accomplishes.

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

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

The description gives clear context by instructing that device_id should come from list_pending_devices, which implies the prerequisite workflow: list pending devices, then approve one. It does not explicitly name alternatives like reject_pending_device or state when not to use this tool, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits, and it does so extensively. It reveals that this is a 'Guarded write' with a sequence of safety behaviors: read-before, no-op when already on the plan, confirm=true requirement, write kill-switch, and read-after. It also discloses testability limitations and the upstream rejection of archived or unknown plans. This far exceeds typical descriptions and gives the agent a clear mental model of side effects and backend expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. The opening sentence gives the purpose immediately, followed by needed caveats (testability, rejection, guarded behavior) and then parameter explanations. There is no fluff or repetition; even the testability warning is operationally relevant because it sets expectations for how the tool is validated. The structure front-loads the essential information.

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

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

For a mutating operation with a guard flag and upstream validation, the description covers all invocation-critical aspects: purpose, prerequisites (source tools for IDs), required confirm flag, optional key_label routing, success no-op condition, failure modes (archived/unknown plan), and backend safety checks. An output schema exists and is noted in context, so the absence of return-value documentation is acceptable. This is a complete picture for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it fully does. Each parameter is given an explicit semantic: subscriber_id is 'the subscriber UUID from list_carrier_subscribers', plan_id is 'the service-plan UUID to assign (from list_carrier_service_plans)', confirm 'must be true to apply the change', and key_label is 'optional configured API-key label'. This is exactly the kind of grounding the schema lacks, providing provenance and constraints that the bare property names do not convey.

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

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

The description opens with a direct, specific statement: 'Assign a service plan to a subscriber (PUT .../subscribers/{id}/plan).' The verb, resource, and HTTP endpoint are explicit, making the tool's purpose unmistakable and clearly distinct from sibling carrier tools like suspend/resume/create/update. The inclusion of the endpoint syntax further concretizes the operation.

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

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

The description provides strong usage context by specifying that subscriber_id comes from list_carrier_subscribers and plan_id from list_carrier_service_plans, implicitly instructing the agent to gather IDs from those tools first. It also states the confirm parameter must be true to apply the change, clarifying a critical precondition. However, it does not explicitly name alternative tools or state when not to use this one, so it stops short of full usage exclusion guidance.

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

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

With no annotations, the description fully carries the burden. It discloses the guarded behavior: read-before, no-op when already linked, confirm=true required, write kill-switch, and read-after reporting prev_host_id. Also states the testing limitation (hermetic/spec-conformance only), which is critical for expectation-setting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence delivers unique value: endpoint, guarded behavior, constraints, parameter meanings, and testing caveat. No fluff or redundancy; information is front-loaded with the action and endpoint first.

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

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

Despite having an output schema, the description provides all necessary contextual details: the guarded workflow, prerequisites (same ISP organization), source of subscriber_id, and the no-op behavior. An agent has everything needed to invoke this tool correctly and understand side effects.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It does: subscriber_id (source), host_id (gateway host id), confirm (must be true), key_label (optional API-key label). Every parameter is covered with meaningful explanation beyond the schema's raw type definitions.

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

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

The description states a specific verb ('Attach or re-link') and a resource ('subscriber's gateway host') with the exact PUT endpoint. It clearly distinguishes from siblings like detach_carrier_subscriber_host, leaving no ambiguity about what this tool does.

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

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

Provides explicit operational context: host must be in the same ISP organization, and links to the source of subscriber_id from list_carrier_subscribers. It doesn't explicitly name alternative tools for when not to use, but the guarded nature and constraints effectively guide appropriate use.

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

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

Because no annotations are present, the description carries full responsibility for disclosing behavioral traits. 'Block' implies a mutation, but the description does not state consequences (e.g., loss of network access, whether existing sessions are terminated) or any permission requirements. The parameter format details are helpful but do not cover behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core action. Parameter explanations are presented in a compact, scannable format with no unnecessary repetition or filler. Every sentence contributes useful information.

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

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

The description covers all parameters and the critical source for client_id, but with no annotations it omits behavioral and safety context such as reversibility, impact on client access, or required permissions. For a mutation tool of this simplicity, this is a moderate gap, making the definition minimally viable but not comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains all three parameters: host (console name, ID, or composite MAC:numericId), site (name or ID), and client_id (required, obtainable from list_clients). This adds substantial meaning beyond the bare string types in the schema.

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

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

The description states a clear verb and resource: 'Block a client on a site.' This is unambiguous about the action and target. It does not explicitly contrast with sibling unblock_client or execute_client_action, so differentiation relies on the name, slightly lowering the score.

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

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

The description provides a prerequisite (obtain client_id from list_clients) but does not explain when to use block_client versus unblock_client or other client-action tools. There is no explicit 'use this when...' or mention of alternatives, leaving the selection logic to inference.

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

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

No annotations are available, so the description carries the full burden of behavioral disclosure. Despite being a destructive bulk operation, it does not warn that matching vouchers will be permanently deleted, mention irreversibility, or note any authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the main purpose appears first, followed by brief parameter definitions. No filler is present, though the `filter_params` line is somewhat tautological.

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

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

The description is inadequate for a destructive bulk operation with no annotations and an opaque `filter_params` object. It omits irreversibility, criteria details, and any usage boundaries, even though an output schema exists and return-value explanation is not required.

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

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

With 0% schema description coverage, the description must compensate. It usefully explains `host` as "console name, ID, or composite ID (MAC:numericId format)" and `site`, but `filter_params` is only described as "filter parameters," leaving the actual keys and value shapes undocumented.

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

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

The description states a specific verb and resource: "Bulk delete hotspot vouchers matching filter criteria." It distinguishes itself from the sibling `delete_hotspot_voucher` by emphasizing bulk operation and selection via filters, so an agent can tell it apart.

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

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

The description gives no explicit when-to-use guidance or mention of alternatives like `delete_hotspot_voucher` for single deletions. The phrase "matching filter criteria" implies bulk selection, but no clear context or exclusions are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'compare', which implies a read-only operation, but it does not explicitly state side effects, required permissions, how invalid site names are handled, or whether results are live or cached. The description lacks transparency about potential edge cases or operational nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no fluff. The purpose is front-loaded, and the parameter explanation earns its place. Every word contributes to understanding the tool.

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

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

For a tool with a single parameter and an output schema, the description covers the core behavior and parameter meaning. However, it lacks usage context, any note about minimum number of sites, or behavior on missing/invalid sites. It is minimally complete but could be more helpful.

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

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

The schema only defines 'sites' as an array of strings with no description. The description adds meaning by explaining the parameter as 'list of site names or IDs to compare', clarifying the acceptable values and their purpose. This compensates well for the 0% schema coverage.

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

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

The description states a specific verb 'compare' with a resource 'health and performance metrics across multiple sites' and the manner 'side-by-side'. This makes the purpose clear and distinct from single-site tools, though it does not explicitly name or differentiate sibling tools.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_site_health_summary or list_all_sites_aggregated. There are no conditions, prerequisites, or exclusions mentioned; the usage scenario is only implied by the purpose.

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

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

With no annotations, the description carries the full burden. It reveals local validation details, the exact controller error for an empty body, and that field validation is type-specific. It is strong but does not mention permissions, idempotency, or duplicate-rule behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense yet well-organized, front-loading the purpose, then parameter semantics, then routing guidance. Every sentence adds value—no filler or repetition.

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

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

For a tool with a nested object and zero schema descriptions, this covers all critical aspects: required parameters, validation behavior, type-specific shape, and alternatives. The output schema likely covers return values, so nothing essential is missing.

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

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

Schema description coverage is 0%, yet the description compensates thoroughly. It defines host and site formats, notes the 'type' discriminator, and enumerates MAC-type rule fields (name, action, enabled, sourceFilter, networkIdFilter). This gives an agent enough to construct a valid call.

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

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

The description opens with 'Create a new ACL rule on a site,' using a specific verb, object, and target. It further distinguishes ACL rules from zone-based perimeter firewall rules, clearly separating this tool from create_firewall_policy.

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

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

Explicitly states when to use this tool (intra-VLAN/inter-network L3 filtering) and when not to, directing to create_firewall_policy for zone-based rules. Also advises reading an existing rule with get_acl_rule to learn the exact shape, giving the agent a concrete next step.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by identifying the Fabric proxy endpoint, noting that settings are server-side validated, and flagging the UNIFI_PROTECT_MUTATIONS_ENABLED feature gate. However, it does not describe failure behavior, permission requirements, or side effects beyond the obvious 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight and front-loaded: the operation and endpoint appear first, followed by brief parameter explanations. Each line provides actionable information without repetition or filler.

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

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

The description covers the endpoint, host targeting, all required parameters, the key nested settings fields, server-side validation, and the feature flag. An output schema exists to cover return values. It is not exhaustive about exact settings structure or failure modes, but it is complete enough for an agent to make a well-informed call.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains that host accepts console name, ID, or MAC:numericId composite format; clarifies that name is the required display name; and breaks down settings into automations, schedules, recordEverything, and activationDelay. It leaves some ambiguity around the exact settings object shape, but the guidance is substantially more informative than the bare schema.

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

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

The description opens with the specific verb and resource pair 'Create an arm profile' and provides the exact endpoint 'POST /v1/arm-profiles via Fabric proxy.' This clearly distinguishes it from the many get/list/update/delete sibling tools that operate on arm profiles.

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

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

The description implies this tool is for creating a new arm profile, and it mentions the UNIFI_PROTECT_MUTATIONS_ENABLED gate, which is useful operational context. However, it does not explicitly state when to use this tool instead of update_arm_profile or update_arm_profile_settings, nor does it provide any exclusion criteria.

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

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

With no annotations, the description carries the full burden. It discloses that this is a guarded write, requires a feature gate, and states that the tool is not testable against live hardware—only hermetic/spec-conformance tested, so a live create is impossible. This is valuable context beyond basic parameter docs, though it stops short of describing error responses or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and organized, but it redundantly lists parameters twice: once in prose ('subscriber_number is required...') and again at the end as a bullet-like series. Trimming that duplication would make it tighter without losing meaning.

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

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

Given the tool has 9 parameters, zero annotations, and an output schema, the description covers all necessary invocation details: the confirm gate, feature gate, testing limitations, every parameter constraint, and the key_label special case. An agent has everything required to call this tool correctly.

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

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

Schema description coverage is 0%, and the description compensates fully. It explicitly documents every parameter: required subscriber_number (1-32 chars), length limits for name/email/notes/service_address, plan_id as UUID, metadata as object, confirm must be true, and key_label for API-key routing. This is exactly what an agent needs and goes far beyond the bare schema.

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

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

The description states a specific verb and resource: 'Create a Carrier / ISP Fabric subscriber (POST /v1/carrier/subscribers)'. It also adds 'Guarded write', which distinguishes this creation tool from other subscriber operations like update, suspend, attach, or detach that exist in the sibling list.

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

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

The description gives clear context for when to use the tool: creating a new subscriber, requiring confirm=true and the UNIFI_ENABLE_CARRIER_FABRIC_WRITE gate. It also notes that live creation is impossible in this environment. However, it does not explicitly name alternative tools for different operations, though the sibling names make the distinction obvious.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the critical fact that this is a write operation that modifies live config. It does not cover idempotency, duplicate-name behavior, permission requirements, or failure modes, which would add valuable transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: the operation and write warning come first, then parameter explanations, then workflow context. Every sentence adds value and the bullet-like formatting is easy to scan.

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

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

For a tool with three parameters, a nested object, and no annotations, the description provides the essential invocation details. Because an output schema exists, return-value documentation is not required. It stops short of error and duplicate-handling context, but that is not necessary for a correct first call.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains host formats (name, ID, composite MAC:numericId), site as name or ID, and documents the tag object's required name field and optional color field with a hex example.

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

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

States a specific verb and resource: 'Create a device tag on a site.' It also explicitly calls out that this is a write operation modifying live config, which clearly differentiates it from read tools and tag-modification siblings.

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

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

Provides useful context: tags are created on a site and later assigned to devices for grouping/filtering, which implies the intended workflow. However, it does not offer explicit when-to-use or when-not-to-use guidance, nor does it route the agent to update_device_tag, delete_device_tag, or list_device_tags.

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

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

With no annotations to carry the safety profile, the description discloses local validation, ValueError behavior naming missing fields, the controller's first validation of the type discriminator, and a verified live failure mode for an empty body. This is considerably more behavioral detail than a bare 'create' label would provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose, then organized into parameter semantics, validation behavior, and policy guidance. Every detail, including the verified empty-body rejection message, earns its place and no filler is present.

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

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

For an opaque policy object with no annotations and no request-schema descriptions, the description supplies host/site formats, the required type discriminator, validation ordering, and a concrete strategy for discovering the full request shape. Because an output schema exists, not detailing the return value is acceptable.

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

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

Schema description coverage is 0%, so the description fully compensates: host accepts a console name, ID, or composite ID in MAC:numericId format, site accepts a name or ID, and policy requires a type discriminator plus type-specific fields. It even suggests consulting get_dns_policy for the exact policy shape, which is essential because the schema leaves the policy object unrestricted.

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

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

The opening sentence, 'Create a new DNS policy on a site,' states a specific verb, resource, and scope. It is immediately distinct from sibling operations such as list_dns_policies, get_dns_policy, update_dns_policy, and delete_dns_policy.

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

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

The description gives clear context for how to use the tool, such as including name and network scope for a typical policy and reading an existing policy via get_dns_policy to confirm the exact shape. It does not explicitly state when not to use it, though no close alternative create operation exists among the siblings.

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

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

With no annotations, the description carries the full burden and delivers exceptional behavioral detail: local validation with ValueError naming, live controller verification, absence of the index field, the source-port filter footgun, and a runtime warning condition. These are exactly the non-obvious behaviors an agent needs before invoking an API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, the description is tightly organized: a one-line purpose, parameter definitions, and a clearly labeled PORT-FILTER PLACEMENT FOOTGUN warning. Every sentence contributes necessary information for correctly constructing a firewall policy with a nested schema.

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

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

For a complex create operation with an opaque schema and no annotations, the description covers host/site resolution, required fields, optional trafficFilter types, ordering via a sibling tool, zone ID sourcing, and a dangerous port-filter placement caveat. The presence of an output schema covers return-value expectations, so nothing critical is missing.

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

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

The input schema is generic — policy is simply an 'additionalProperties: true' object — so the description supplies the entire semantic layer. It documents host formats, site addressing, required policy fields with types, the action/source/destination structure, and the trafficFilter one-of variants, fully compensating for 0% schema coverage.

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

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

The description opens with a specific verb and resource: 'Create a new firewall policy on a site.' It also differentiates from related siblings by explicitly stating there is NO 'index' field and directing rule-order management to set_firewall_policy_ordering, removing any ambiguity about scope.

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

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

The description gives clear pointers to sibling tools for related tasks: use set_firewall_policy_ordering for rule order, list_firewall_zones_proxy for zone IDs, and list_firewall_policies for discovering in-use filter types. It does not explicitly state exclusions against update_firewall_policy or patch_firewall_policy, though 'Create a new' implies the distinction.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the zone payload is validated locally and that a missing field raises a ValueError naming the field, and that the zone is then verified against the live controller. This goes beyond a generic 'creates' statement, though it does not discuss permissions or failure details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. The first sentence states the action, and subsequent lines map cleanly to each parameter without extraneous prose.

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

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

For a three-parameter create operation with an output schema available, the description covers the parameter formats, the required nested zone payload, local validation behavior, and how to source networkIds. It is complete enough to call correctly, though it does not explain the connector-proxy context or what response to expect beyond the existing output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It explains all three parameters: host accepts a console name, ID, or MAC:numericId composite; site accepts name or ID; zone must contain name and networkIds with their types. It also tells the agent where to get network IDs. Slight gap: it doesn't state whether additional zone properties are allowed or prohibited.

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

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

Description opens with a specific verb and resource: 'Create a new firewall zone on a site via connector proxy.' This matches the tool name and cleanly separates it from sibling firewall-zone operations (list/get/update/delete_firewall_zone_proxy).

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

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

The description gives clear context for when to invoke it: creating a new zone rather than listing, fetching, updating, or deleting one. It also directs the agent to list_networks to obtain required networkIds. It does not explicitly state exclusions (e.g., use update_firewall_zone_proxy to modify an existing zone), so not a 5.

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

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

No annotations are provided, so the description bears the full responsibility for behavioral disclosure. It states the operation is 'create,' but does not mention permissions, idempotency, side effects, or any caveats. The output schema exists, but the description does not hint at what the response contains. This is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the second packing parameter clarifications into a dense but readable format. No filler or redundancy. Every sentence adds value.

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

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

Given the five parameters and the presence of an output schema, the description covers the core required fields and gives format hints for host and site. The only missing piece is the optional 'note' parameter and clearer guidance on response handling, but the output schema fills that gap. Overall, it is sufficiently complete for a competent agent.

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

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

The input schema has no descriptions, so the description must compensate. It explains host (including the MAC:numericId composite format), site (name or ID), name (username), and password (password). However, it omits the optional 'note' parameter entirely. Despite the omission, the provided explanations are concrete and actionable, earning a strong score.

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

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

The description starts with a specific verb and resource: 'Create a hotspot operator account.' This clearly distinguishes it from sibling tools like list_hotspot_operators, update_hotspot_operator, and delete_hotspot_operator. The description also explains key parameters that reinforce the creation purpose.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies usage through the verb 'create,' but there is no guidance on when the update or delete siblings should be used instead. The parameter explanations provide some context, but no direct usage guidance.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond a simple "create" by explaining local validation behavior (missing field raises ValueError naming it), live controller verification, and the exact required fields. It does not discuss permissions or failure modes, but it provides substantial behavioral detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then uses a compact, labeled structure for parameters. Every clause provides useful information: host formats, site formats, required config, validation behavior, and optional fields. There is no filler.

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

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

The description is complete enough to call the tool correctly: all three required parameters are explained, the nested voucher_config is described with mandatory and optional keys, and the return value is handled by the existing output schema. It is slightly open-ended about the full set of optional voucher_config fields, but the "etc." covers that without bloating the description.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: host is explained as console name/ID/composite ID with format, site as name/ID, and voucher_config is broken down into required name/timeLimitMinutes with units and optional fields. This adds rich meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: "Generate hotspot vouchers for a site." This clearly distinguishes the tool from sibling list/get/delete hotspot-voucher tools and from the broader create_hotspot_operator tool.

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

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

The description gives clear context on how to use the tool: it explains what host, site, and voucher_config mean and what is required. It does not explicitly name alternatives or exclusions, but the creation purpose and parameter guidance are unambiguous enough for an agent to know when to invoke it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention permissions required, side effects, or what happens upon creation. It also does not indicate whether existing liveviews are affected or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a one-line summary followed by parameter explanations in a clear list format. No extraneous content.

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

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

The description covers the essential parameters but lacks usage context, behavioral expectations, and any edge-case handling. Since an output schema exists, return values are covered, but the agent still lacks guidance on when and how to use this tool in a broader workflow.

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

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

The description adds significant meaning beyond the raw schema by explaining each parameter: host format ('MAC:numericId'), name purpose, and settings as optional extra fields. This is especially valuable given 0% schema description coverage.

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

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

The description clearly states the action 'Create a liveview on a Protect console' with a specific verb and resource. It does not explicitly differentiate from sibling tools like update_liveview, but the action is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context. The description only states what it does, leaving the agent to infer when it's appropriate.

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

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

There are no annotations provided, so the description fully carries the burden of explaining behavior. It thoroughly discloses the side effect of D12 auto-exclusion (networks silently added to custom-tagged port profiles, blackholing VLANs), explicitly states local validation with error naming, and notes the controller's enforcement of management-mode-specific schema. It also clearly indicates that field names are camelCase and there is no 'purpose' field, preventing common mistakes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but organized with clear sections: a one-line summary, field definitions, parameter requirements, and a distinct warning block. It front-loads the core purpose, then provides essential nested schema, then the critical behavioral warning. Every sentence earns its place, and the formatting makes it easy to scan.

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

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

Given that there is no annotation schema and the input schema is minimal, the description provides comprehensive information: the full required schema for the main management mode, optional fields, validation semantics, error behavior, and the D12 auto-exclusion side effect with remediation instructions. It fully equips an agent to construct a correct request and handle a known failure mode. The return output schema exists and includes a warnings entry, which is acknowledged.

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

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

The input schema only lists host, site, and network_config as generic strings/objects with 0% description coverage. The description compensates by defining what each top-level field means (host: console name, ID, or composite ID; site: site name or ID), and provides the full nested schema for network_config when management='GATEWAY', including types for each field. It doesn't document every possible management mode, but it does explain the structure and optional fields for the main case.

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

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

The description clearly states the action 'Create a new network/VLAN on a site' with the primary resource (network/VLAN) and context (site). It distinguishes this from sibling tools by specifying it creates a network as opposed to updating, deleting, or listing networks. The additional detail about management-mode-specific schema further clarifies the scope.

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

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

The description provides explicit when-to-use context: it details the required parameters (host, site, network_config), gives a concrete example of the GATEWAY management-mode schema, and warns about the D12 auto-exclusion behavior with specific remediation steps (run allow_network_on_port_profile). It also implicitly distinguishes this from update_network, delete_network, and list_networks by focusing on creation and the unique caveats.

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

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

The description makes critical behavioral details transparent: the local validation of required fields, the fact that the server-side endpoint enforces no required fields, and that an empty body would silently create a broken rule. It also notes the proto default. This is excellent risk disclosure, especially with no annotations provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: purpose, parameter definitions, behavioral warning, and a concrete example. Every sentence provides necessary information without filler. Despite being detailed, it remains efficient and scannable.

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

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

The description covers all essential invocation details: how to specify host/site, the required payload structure, the important server-side validation gap, and a realistic example. Since an output schema exists, not detailing return values is acceptable. This is highly complete for a create operation with a nested object payload.

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

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

Schema description coverage is 0%, so the description carries the full burden. It defines host, site, and payload semantics, lists the required payload fields (name, dst_port, fwd, fwd_port), explains that proto is optional with a default, and gives a complete example. This fully compensates for the schema's lack of description.

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

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

The description clearly states the tool's action: 'Create a port forwarding rule via the Classic REST API.' It specifies the verb (create), the resource (port forwarding rule), and the API context. This distinguishes it from sibling CRUD tools like update_port_forward and delete_port_forward based on the verb alone.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention update_port_forward, delete_port_forward, or list_port_forwards, nor does it provide conditions for choosing this tool. The 'create' verb implicitly suggests usage for new rules, but the description leaves that to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It warns that a 405 response means RADIUS profile creation is unsupported and profiles are read-only, which is a meaningful behavioral caveat beyond the basic 'create' action. It does not mention permissions or idempotency, but the provided failure-mode note is valuable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: a clear opening line, a line-separated parameter list, and a brief fallback note. Every sentence adds usable information without redundancy or padding.

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

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

Given that an output schema exists and the parameter semantics are thoroughly covered, the description is complete for invocation. It clarifies required vs optional fields, host addressing, and includes a fallback instruction for an important edge case, making it self-sufficient for correct tool usage.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining all nine parameters: host format (console name, ID, or MAC:numericId), site as name/ID, required auth server fields, and optional accounting fields. It adds semantics not present in the schema, such as host allowed formats, port example (1812), and the shared secret purpose.

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

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

Description opens with 'Create a RADIUS authentication profile', clearly stating the verb and resource. It differentiates from sibling tools like list_radius_profiles and get_radius_profile by emphasizing creation, and the parameter list reinforces the action.

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

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

The usage context is implied by the creation verb and parameter requirements, but the description goes further by stating that on HTTP 405 the tool should not be used and list_radius_profiles should be used instead. This explicitly gives an alternative and a specific when-not-to-use condition, though it does not broadly cover all sibling alternatives.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses case-insensitive normalization, absence of local allow-list validation, upstream API authority over invalid channel names, and the special behavior of the 'package' channel. It stops short of discussing side effects or lifecycle of the created stream, but provides substantial 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The one-line purpose is front-loaded, and each parameter has a focused block of detail. Every sentence adds operational value; there is no filler or repetition of schema content.

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

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

Given the output schema exists and no annotations are present, the description covers parameters and edge behavior thoroughly. Minor gaps remain around prerequisites, whether existing streams are replaced, and authentication expectations, but nothing critical is missing for invoking this tool.

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

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

Schema description coverage is 0%, but the description fully compensates. It explains host formats, enumerates the valid qualities, clarifies case-insensitivity, documents the no-local-validation behavior, and tells the agent exactly where to obtain camera_id. This goes far beyond the bare input schema.

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

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

The description states a specific verb and resource: 'Create an RTSPS stream for a Protect camera.' This is clear and the create/get/delete distinction among siblings is obvious from the name, though the description itself does not explicitly contrast it with get_rtsps_stream or delete_rtsps_stream.

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

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

Usage is implied by the verb 'Create' and the guidance to obtain camera_id from list_cameras. It references get_rtsps_stream as a verification source, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that this 'is a write operation that modifies live config,' which is a meaningful warning about real-world side effects. However, it does not disclose authentication requirements, idempotency, conflict behavior, or reversibility, leaving the profile incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, behavioral warning second, parameter clarifications last. Every sentence contributes value with no filler. The inline parameter documentation at the end is slightly awkward as a run-on but remains appropriately sized for a three-parameter tool.

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

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

For a write operation with an output schema and no annotations, the description covers the core action, the side-effect warning, and parameter formats. It lacks prerequisites such as the site/host needing to exist, failure or validation behavior, and whether the tunnel payload is a full replacement or partial update. These gaps are notable but not fatal for a create operation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does meaningfully. It explains host as 'console name, ID, or composite ID (MAC:numericId format),' site as 'site name or ID,' and enumerates tunnel payload fields like remoteIp, psk, networks, and enabled. The 'etc.' signals non-exhaustive listing, so it stops short of fully specifying types and required subfields.

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

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

The description opens with a specific verb-resource pair, 'Create a site-to-site VPN tunnel,' which clearly identifies the action and resource. This distinguishes it from sibling tools like list_site_to_site_tunnels, update_site_to_site_tunnel, and delete_site_to_site_tunnel. The added 'site-to-site' qualifier also differentiates it from VPN server tools such as create_vpn_server.

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

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

The description offers no explicit guidance on when to use this tool versus alternatives, such as update_site_to_site_tunnel for modifying an existing tunnel or list_site_to_site_tunnels for inspection. The 'create' verb implies use only for new tunnels, but no prerequisites, exclusions, or alternative routing are stated.

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

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

With no annotations, the description carries the transparency burden and does substantial work: it discloses local validation, ValueError behavior on missing fields, the required `type` discriminator, a live-verified rejection message, and the 'items' vs 'entries' naming trap. It does not cover authorization or side effects, but the disclosed behavior is unusually rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then uses compact labeled details for host, site, validation behavior, and traffic_list structure. It is slightly dense, but every sentence contributes useful information and there is no fluff.

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

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

For a nested-object create tool with 0% schema coverage, the description covers the essential call requirements: host/site identifiers, the `type` discriminator, the PORTS object fields, and the items/entries gotcha. The output schema exists, so return-value details are not required. Minor ambiguity remains about whether other `type` values besides 'PORTS' are supported, but the description is otherwise sufficient.

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

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

Schema description coverage is 0%, so the description must compensate fully. It explains host formats (console name, ID, or composite ID), site naming, the required top-level `type` discriminator, and the PORTS-list shape with `name` and `items`. This adds meaning far beyond the bare schema with `additionalProperties: true`.

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

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

The description opens with a specific verb and resource: 'Create a new traffic matching list on a site.' This clearly distinguishes it from sibling read/update/delete operations and identifies the scope (a site).

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

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

The description clearly indicates this is for creating a new traffic matching list, which implies when to use it versus listing, updating, or deleting. It does not explicitly name alternatives or exclusion criteria, but the 'create' framing provides clear context.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses local validation raising ValueError, verification against the live controller, and the snake_case wire-format constraint with a concrete accepted/rejected example. It does not describe response behavior or side effects, but for a create operation the mutation is clear from the tool's name and first sentence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but appropriately sized for a nested-object create tool. It front-loads the main verb and resource, then covers all parameters in an organized bullet-like layout. Every sentence adds useful information and there is no filler.

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

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

The description covers the required payload and field naming in detail, but leaves some gaps: target_devices is not fully specified, the source of 'traffic matching list ID' is not pointed to, and no return/confirmation behavior is mentioned. These are relatively minor against the strong parameter-level detail and no output schema.

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

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

The input schema provides only bare string and object types with 0% description coverage, and the description compensates thoroughly: it defines host, site, the required payload keys, accepted values, optional fields, and even warns that 'networkId' is not accepted. This is far beyond what the schema alone supplies.

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

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

The description uses a specific verb and resource: 'Create a traffic route on a site' and immediately scopes it with '(policy-based routing / WAN load-balancing)'. This makes the tool clearly distinct from sibling tools like create_traffic_rule or create_traffic_matching_list.

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

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

The tool's intended scenario is clear from the parenthetical scope and the payload guidance (e.g., 'network_id ... from list_networks'). It does not explicitly state when to prefer it over closely related create_traffic_rule, but it provides enough context that an agent can infer the use case.

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

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

With no annotations, the description carries the full burden. It discloses significant behavioral details: local validation raises ValueError, live controller verification, target_devices is required by the API though previously undocumented, and a firmware version limitation. These go beyond the basic create semantics and help an agent anticipate errors and compatibility issues.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but every sentence carries unique information: purpose, parameter formats, required/optional fields, validation behavior, API endpoint, and compatibility note. The section is well-organized with bullet-like separations, making it scannable despite its length.

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

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

Given the tool's complexity (nested payload, many optional fields, validation behavior, firmware constraints), the description covers the essential knowledge needed to call it correctly. An output schema exists, so return values need not be described. Missing details like permission requirements or whether the rule is appended or replaces existing rules are minor given the richness present.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does: host (name/ID/composite ID), site (name/ID), and payload with a breakdown of required fields (action, matching_target, target_devices) and optional fields (description, enabled, matching_target_type, bandwidth_limit) including specific formats and API expectations. This completely compensates for the empty schema.

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

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

The description opens with a precise verb-object pair: 'Create a traffic matching rule' and specifies the rule types (QoS, block, or route by application/IP group). This clearly distinguishes the tool from siblings like create_traffic_route or create_firewall_policy by focusing on traffic-matching rules.

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

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

The description provides context on when the tool is applicable by noting that it uses the Classic REST v2 API and may not exist on firmware 10.2.105 and below. However, it does not explicitly state when to prefer this tool over alternatives like update_traffic_rule or delete_traffic_rule, nor does it mention prerequisites beyond providing host/site/payload.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the creation action but does not disclose side effects, permissions required, idempotency, or failure modes. It is more of an action statement than a behavioral contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four short lines, front-loading the action and then listing parameter notes. Every segment adds information without filler, making it efficient and scannable.

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

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

The presence of an output schema reduces the need to document return values. The description covers the operation and several key parameters, but it omits semantics for the required 'name' parameter and the 'enabled' flag, and provides no context on preconditions. For a create operation with no annotations, this is nearly complete but not fully.

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

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

Schema description coverage is 0%, but the description adds useful meaning for host (name/ID/composite ID format), site (name/ID), vpn_type (enumerated values), and subnet (CIDR pool). However, it leaves the required 'name' and optional 'enabled' parameters undefined, which is a gap.

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

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

The description opens with a specific action 'Create a VPN server' and lists supported VPN types, clearly identifying the resource and operation. It distinguishes from sibling tools like update_vpn_server and list_vpn_servers via the 'Create' verb, though it does not explicitly name an alternative.

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

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

The description implies usage when creating a VPN server, but provides no explicit guidance on when to use this tool versus update_vpn_server or delete_vpn_server, nor any exclusions. There is no mention of prerequisites such as host/site existence.

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

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

With no annotations, the description discloses important behavioral traits: local validation before the request, ValueError on missing fields, controller-first validation of the type discriminator, type-specific enforcement, and required camelCase field names. This goes well beyond a simple 'creates' statement and prepares the agent for validation and API syntax constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. It starts with the purpose, then gives parameter formats and payload structure in a readable block. Each sentence adds value and there is no filler, though the payload formatting could be slightly tighter.

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

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

The description covers the required identifiers, local validation, discriminator behavior, STANDARD payload keys, and camelCase requirement. Since an output schema exists, return value explanation is unnecessary. The only notable gap is not explicitly saying when not to use this tool (e.g., use update_wifi_broadcast for modifying an existing SSID), but for the creation use case it is sufficiently complete.

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

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

Schema coverage is 0%, so the description must compensate. It does add meaning for host, site, and broadcast, including the STANDARD payload fields and camelCase requirement. However, it does not fully enumerate all possible broadcast subfields for other types, leaving some semantics underspecified for the schema's empty 'broadcast' object.

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

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

The description begins with a specific verb and resource: 'Create a new WiFi broadcast SSID on a site.' It clearly distinguishes this from sibling tools like get_wifi_broadcast, update_wifi_broadcast, and delete_wifi_broadcast by focusing on creation. 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.

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

The description gives clear usage context by explaining required parameters, host/site format, and the broadcast payload shape for a STANDARD SSID. It doesn't explicitly list alternatives, but the creation verb and field guidance make it clear when to use this tool versus the sibling read/update/delete operations.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates that the tool deletes an ACL rule; it does not say whether deletion is permanent, whether it affects rule ordering, what prerequisites exist, or what side effects may occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded: one sentence states the operation, and three compact notes document the parameters. There is no filler, and every sentence earns its place.

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

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

For a simple three-string-parameter delete operation with an output schema present, the description covers all invocation essentials: operation, parameter semantics, requiredness, and ID source. It is not a 5 because, without annotations, it omits any statement about the destructive action's permanence or aftermath.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining host as a console name, ID, or composite ID, site as a name or ID, and rule_id as REQUIRED with a source instruction pointing to list_acl_rules. Every parameter receives functional meaning beyond the bare string type.

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

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

The description opens with a specific verb and resource, 'Delete an ACL rule,' which unambiguously defines the operation and distinguishes it from sibling tools such as list_acl_rules, get_acl_rule, update_acl_rule, and create_acl_rule. The purpose is immediately understandable and not a mere restatement.

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

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

The description gives clear when-to-use context by defining the operation as deletion and instructing the caller to obtain rule_id from list_acl_rules. It does not explicitly enumerate when-not-to-use alternatives such as update_acl_rule, so it stops 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.

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

With no annotations, the description carries the full burden and covers the destructive nature ('Irreversible — no undo'), the confirmation requirement, and the UNIFI_PROTECT_MUTATIONS_ENABLED guard. It doesn't discuss cascading side effects or permission requirements, but the critical delete semantics are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short lines, with the core action and the most important warning first. Parameter notes are one line each and contain only actionable details.

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

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

For a three-parameter destructive action, everything needed to call it correctly is present: endpoint, id source, confirmation flag, and the feature flag governing execution. An output schema exists, so return-value documentation isn't required and its absence doesn't hurt.

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

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

Schema description coverage is 0%, and the description compensates fully: host's accepted formats (name/ID/composite MAC:numericId), arm_profile_id's required status and how to obtain it, and confirm's role plus the env-var gate. This is exactly the semantics missing from the schema.

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

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

The description opens with the verb and resource ('Delete an arm profile') and includes the HTTP endpoint, so an agent knows exactly what operation this is. It doesn't explicitly contrast with sibling operations like disable_arm or update_arm_profile, so it misses the top tier for sibling differentiation.

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

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

It says deletion is irreversible and that confirm must be true, giving a clear precondition. It also tells the agent to source arm_profile_id from list_arm_profiles, but it never says when to prefer this over alternatives (e.g., disable_arm or update_arm_profile).

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

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

This description states that the action 'permanently removes the tag from the site', which communicates irreversibility. With no annotations available, the description carries the burden of behavioral disclosure; it covers permanence but omits other important details such as required permissions, potential side effects on associated devices, or lack of confirmation prompts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient: a one-sentence action with permanence note, followed by concise parameter definitions. No filler or redundant text; every sentence and line adds value.

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

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

Given the tool's simplicity and the presence of an output schema, the description is largely complete. It covers the action, permanence, and parameter formats. However, it lacks any note about permission requirements or what happens if the tag is in use, which could matter in an enterprise context, but these are minor given the straightforward delete operation.

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

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

The input schema provides only names and types with 0% coverage, but the description compensates thoroughly by explaining each parameter: host as 'console name, ID, or composite ID (MAC:numericId format)', site as 'site name or ID', and tag_id as 'device tag ID to delete'. This adds significant meaning beyond the schema, giving the agent clear format and purpose guidance.

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

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

The description uses a specific verb 'Delete' with a clear resource 'device tag by ID' and adds the consequence 'permanently removes the tag from the site', which leaves no ambiguity about the operation. It distinguishes itself from create/update/list sibling tools through the explicit destructive verb and the word 'permanently'.

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

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

The description implies usage by stating 'Delete a device tag by ID', making it obvious this is for removing a tag. However, it provides no explicit guidance on when to use this tool versus alternatives like update_device_tag or list_device_tags, and does not mention any prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it only repeats the destructive verb without stating consequences such as irreversibility, prerequisite policy state, or potential failures. It does not contradict the schema, but it fails to add meaningful behavioral context beyond the word 'Delete.'

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with the action stated in the first sentence and parameter details in a compact list. Every clause adds useful information, with no filler.

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

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

The description provides enough param semantics to call the tool and an output schema exists, so return-value documentation is not needed. However, the absence of behavioral warnings about deletion, and the incomplete 'REQUIRED' emphasis, leave gaps for a destructive operation with no annotations.

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

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

Since schema description coverage is 0%, the description supplies valuable parameter guidance: host may be a console name, ID, or composite MAC:numericId, site is a name or ID, and policy_id is obtained from list_dns_policies. It could be clearer that all three parameters are required, given the schema lists all as required and only policy_id is marked REQUIRED.

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

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

The first sentence, 'Delete a DNS policy,' uses a specific verb and resource, exactly matching the tool's purpose. Among many delete_* siblings, the DNS policy resource is unambiguous and distinct.

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

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

The description implies the expected workflow by telling the agent to obtain policy_id from list_dns_policies. It does not explicitly state when not to use this tool or name alternatives, but no alternative deletion tool for DNS policies exists, so the context is clear enough.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete a firewall policy' and does not mention that deletion is irreversible, what permissions are needed, whether associated rules are affected, or any side effects. This is a meaningful gap 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: one clear purpose sentence followed by terse parameter guidance. There is no filler or repetition of schema field names without added value.

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

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

Given the tool's low complexity and the presence of an output schema, the description covers the essential calling details: what to delete, how to address host/site, and where to get the required policy_id. It is slightly incomplete only in that it omits any behavioral caution for a destructive action, but the core invocation context is present.

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

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

Schema description coverage is 0%, so the description must compensate. It does: host is documented as console name, ID, or composite ID in MAC:numericId format; site as name or ID; and policy_id as required and sourced from list_firewall_policies. This adds real meaning beyond the bare string fields in the input schema.

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

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

The description opens with a specific verb and resource: 'Delete a firewall policy.' This clearly distinguishes it from sibling tools like create_firewall_policy, get_firewall_policy, update_firewall_policy, and patch_firewall_policy without needing to inspect their schemas.

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

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

It gives context by explaining that policy_id must be obtained from list_firewall_policies via its id field, which tells the agent the prerequisite step. It does not explicitly state when to avoid this tool or list alternatives, but the use case is clear enough for a simple delete operation.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It conveys that the operation deletes a resource, but fails to mention irreversibility, potential side effects, permissions needed, or failure conditions. This is a destructive operation, so more behavioral disclosure is warranted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the purpose, and uses a clear parameter breakdown. Every sentence adds value, and there is no redundant or verbose content.

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

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

All required parameters are covered and the provenance of zone_id is explained; the presence of an output schema reduces the need to document return values. The description is complete enough for making the call, though a brief note on the destructive/permanent nature would strengthen it.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining each parameter: host accepts console name, ID, or composite ID (MAC:numericId format), site accepts name or ID, and zone_id is required and sourced from list_firewall_zones_proxy. This provides meaningful guidance beyond the raw schema.

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

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

The description states a specific action ('Delete a firewall zone') and the mechanism ('via connector proxy'), which clearly distinguishes it from sibling tools like list, get, or update firewall zone proxy. The resource and operation are unambiguous.

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

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

The description clearly instructs that zone_id is required and must be obtained from list_firewall_zones_proxy, providing an explicit prerequisite and source. It does not explicitly state when not to use this tool versus alternatives, but the delete-focused context makes the use case clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the deleted resource but does not mention whether deletion is permanent, whether it cascades to other entities, what permissions are required, or what the response indicates. The parameter format hints add context, but they are not behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences, with the action front-loaded and parameter clarifications neatly separated. Every line adds value, and there is no redundant or filler content. It is an appropriate size for a simple three-parameter delete tool.

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

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

For a simple delete operation with three string parameters and an output schema present, the description gives enough parameter semantics to invoke the tool correctly. It explains the tricky host composite ID format and clarifies site and operator_id. The absence of behavioral and usage context is covered by other dimensions, but the basic invocation details are sufficiently complete.

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

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

The schema description coverage is 0%, so the description must compensate, and it partially does. It explains that host accepts a console name, ID, or composite ID in MAC:numericId format, and that site accepts a name or ID. operator_id is defined only as 'hotspot operator ID,' which is nearly tautological, but the host composite format is genuinely useful beyond the bare schema.

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

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

The description opens with the specific verb and resource: 'Delete a hotspot operator by ID.' This clearly distinguishes the tool from sibling operations like update_hotspot_operator, create_hotspot_operator, and list_hotspot_operators. The resource and action are unmistakable.

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

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

The description provides no guidance about when to choose this tool over related alternatives, nor does it state prerequisites or conditions. It implies usage through the word 'Delete' but fails to mention exclusions, such as whether the operator must exist or what happens on failure. This is not enough to route an agent confidently among the many delete tools in the sibling list.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' makes the destructive nature clear, but the description does not state whether deletion is permanent, require confirmation, or have side effects on dependent resources. Beyond naming the action, it offers no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the action, followed by terse parameter definitions and a retrieval hint. Every sentence earns its place without redundancy.

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

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

For a simple 3-parameter delete operation, the description covers all required inputs and tells the agent exactly where to source voucher_id. It omits any warning about irreversibility or permission requirements, but the presence of an output schema reduces the need to explain return values.

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

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, and it does. It defines host as 'console name, ID, or composite ID (MAC:numericId format)', site as 'site name or ID', and explains that voucher_id is required and obtainable from list_hotspot_vouchers. This is meaningful semantic guidance beyond the raw string fields.

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

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

The description opens with a specific verb and resource pair: 'Delete a single hotspot voucher.' The word 'single' explicitly distinguishes this from the sibling bulk_delete_hotspot_vouchers, so an agent can immediately identify which tool matches the operation.

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

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

It provides clear context for using the tool, including how to obtain the voucher_id from list_hotspot_vouchers. It does not explicitly mention when to prefer bulk_delete_hotspot_vouchers instead, but the 'single' framing gives enough implicit guidance for this simple deletion case.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Delete a network/VLAN' without elaborating on consequences such as irreversibility, cascading effects on associated objects, required permissions, or potential errors. While 'Delete' implies destructiveness, the description lacks any detail about the operation's side effects, making the behavior largely opaque. This is a significant gap for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and efficient. Two sentences deliver the purpose and parameter semantics without any filler. The key action is front-loaded, and parameter explanations are concise and directly useful. Every word earns its place.

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

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

While an output schema exists (so return values need not be described), the description omits critical context for a destructive operation. It does not mention whether deletion is permanent, whether there are safety checks, or what happens to networks in active use. Given the complexity of network management and the lack of annotations, the description should provide more operational context to avoid accidental misuse. It only covers parameter sourcing, not the operation's broader implications.

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

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

The input schema provides only type information with no descriptions. The description compensates fully by explaining each parameter: host (with specific formats), site (name or ID), and network_id (required and how to obtain it). This is substantial added meaning beyond the schema, which is nearly useless alone. The guidance to use list_networks for the ID is particularly valuable.

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

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

The description begins with a clear, specific verb and resource: 'Delete a network/VLAN.' This makes the tool's purpose immediately obvious and distinguishes it from sibling tools like create_network, get_network, and update_network. The action and target are unambiguous.

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

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

The description provides clear context on how to use the tool by explaining the required parameters and directing users to list_networks to obtain the network_id. It implies usage ('when you want to delete, use this'), but it does not explicitly mention exclusions or alternative tools for scenarios like conditional deletion or bulk deletion. This is a clear context without formal exclusions, matching a 4.

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