unifi_console_system_log

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what categories of events are recorded, the default time/severity window, and that critical_only bypasses the time window and paging. It does not mention rate limits or pagination limits beyond what the schema implies.

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?

Front-loaded with the purpose, then behavior, defaults, the critical_only escape hatch, and the return shape. Every sentence contributes, though the return-format block is somewhat redundant given an output schema exists.

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 multi-parameter, read-only query tool with annotations and an output schema, the description covers purpose, defaults, severity semantics, and the critical_only special case. It omits guidance on category filtering and on choosing between this and sibling log tools, but nothing critical to invoking it 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?

The description reinforces key parameter semantics: critical_only switches to the Critical view with no time window or paging, and min_severity defaults to MEDIUM with LOW described as Wi-Fi connect/roam noise. The nested schema properties themselves carry full descriptions, so the schema does most of the work; the description adds useful nuance on top rather than filling 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?

States a specific verb and resource ('Query the UniFi System Log'), anchors it to a UI location (the Network app's 'System Log' page), and enumerates the event families it covers (STP loops, PoE/port faults, WAN failovers). It distinguishes itself from 'the older event list' but never names a sibling tool, so an agent still has to infer how it differs from unifi_console_syslog or unifi_console_logging_levels.

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?

Gives concrete operating context: defaults to last 24 hours at MEDIUM+, and explicitly routes to critical_only=true for switching faults with example event names. It stops short of naming when NOT to use this tool or which sibling log tool to prefer, so it is clear context without exclusions.

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