unifi_gen_getswitchstackpage

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, and the description adds nothing on top — no pagination behavior, no filtering semantics, no result-ordering or total-count information for a 'page' endpoint.

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?

It is short and front-loaded, which is good, but the length comes at the cost of omitting everything useful; the appended developer.ui.com URL is dead weight that contributes nothing to invocation.

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 paginated list endpoint with three undocumented parameters and no output schema, the description should at minimum explain paging and filter conventions. As written, an agent could not construct a correct filtered or paged request from the definition alone.

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% across three parameters (limit, filter, offset), and the description does not compensate at all. It never states the filter syntax, the default or maximum page size behavior, or how offset interacts with limit.

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?

"List Switch Stacks" gives a verb and a resource, so the basic action is legible. However, nothing distinguishes it from the near-identical siblings unifi_net_list_switch_stacks and unifi_gen_getswitchstack, and the trailing documentation URL is provenance noise rather than a purpose statement.

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 when-to-use guidance, no exclusions, and no mention of the sibling tools that appear to do the same thing. The agent has to guess whether this page endpoint or unifi_net_list_switch_stacks is the right call.

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