Observe one LAN client

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the 'bounded' aspect (likely referring to the duration limit) and specifies the observed data types, but it does not disclose additional behavioral traits such as output format, side effects, or timing behavior 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?

The description is a single, well-structured sentence that starts with the action verb and packs the essential scope into minimal words. There is no fluff or repetition, making it easy for an agent to quickly parse.

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 lack of an output schema, the description should explain what the tool returns or how results are presented. It mentions 'connection/log activity and conntrack state' as the observed data, which gives an idea of the output domain, but it does not specify the format, structure, or whether results are aggregated or streamed. The 'bounded' hint suggests a time-limited observation, but this is not fully elaborated.

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 only vaguely references 'one client address' and 'bounded' activity, without explaining the distinct roles of client_ip vs client_ipv6 or clarifying how duration (default 60, min 5, max 60) influences the observation. This under-specification is a significant gap for a three-parameter tool.

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 ('Observe') and clearly identifies the resource ('Mihomo connection/log activity and conntrack state') scoped to one client address. It distinguishes from broader sibling tools like snapshot_network or inspect_flow by emphasizing the single-client focus, though 'bounded' is somewhat ambiguous without referencing the duration parameter.

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 phrase 'one client address' implies this tool is for observing a specific LAN client, providing a clear use case. However, it offers no explicit guidance on when to use it over alternatives (e.g., inspect_flow for general flow inspection) and no exclusions or conditions indicating 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.