analyze_anomalous_calls_by_process

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

With no annotations, the description fully discloses behavior: it returns per-process data and suggests suppression rules, including the logic for auto-proposing process-wide rules for VPN processes. It does not mention side effects or permissions, but the tool appears read-only.

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 paragraph but well-organized: first the goal, then specific guidance, then return details. It is informative without being overly verbose, though could be slightly more concise.

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 no output schema, the description fully explains the return structure: per-process count, distinct endpoints, distinct direct IPs, sample detections with dashboard links, and a suggested suppression rule. It also covers the logic for VPN processes. Sibling tools provide additional context.

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 100%, so baseline is 3. The description adds no extra meaning beyond what's in the schema for the two parameters (customer and minCount). The mention of env var fallback is already in the schema 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 that the tool groups anomalous network-call detections by process, aiming to identify VPN/mesh-networking daemons. It distinguishes from siblings like list_anomalous_network_calls and create_suppression_rule by specifying it returns per-process statistics and suggests suppression 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?

Explicit guidance on when to use (spot VPN daemons) and when not to (do not auto-propose process-wide rules for other processes like dockerd). It also explains that for VPN processes, a single rule suppresses both domain and direct-IP anomalies.

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