analyze_blocked_traffic

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral detail: logs are raw text with pattern-matched IPs, results are grouped and scored, and there is a specific known failure mode (pfSense REST API OOM at 512 MB PHP limit) with a fallback suggestion. This is rich, honest 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 concise, front-loaded with the core purpose, then details behavior, and finally flags a critical warning. Every sentence carries useful information and the warning is clearly separated.

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?

With an output schema present and read-only annotations already set, the description covers the essential operational context: inputs, processing approach, output grouping, and a known failure condition. An agent has enough information to invoke it correctly and handle likely failures.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds general context about raw logs and grouping, but does not add meaning beyond what the schema already explains for limit or group_by_source. It is adequate but not compensatory.

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 a specific action and resource: 'Analyze blocked traffic patterns from firewall logs' and details grouping by source IP, hit counts, destination IPs, and threat score. However, it does not explicitly distinguish itself from similar siblings like diagnose_blocked_traffic or search_logs_by_ip, so it stops just short of full 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?

The description implies when to use the tool (when blocked traffic analysis is needed) but provides no explicit guidance on when to prefer it over alternatives, nor any exclusions. The warning suggests an SSH/web UI fallback on failure, but does not mention sibling tools as alternatives.

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