get_network_summary

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether this is a read-only operation, whether it requires prior capture, or if it consumes/clears data. It also doesn't explain what a 'summary' includes (e.g., counts, URLs, response times). The tool likely is a safe read, but nothing confirms that.

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 sentence, which is concise and front-loaded. However, it is under-specified, but as a standalone sentence it is efficient. Given the need for more detail, one could argue it is too short, but conciseness is not the issue; completeness is.

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 no output schema, no annotations, and 0% parameter description coverage, the description is insufficient. The tool's complexity is moderate (2 params, no required), but the description only provides a high-level statement. The agent lacks information on return format, filtering logic, and preconditions, making complete use difficult.

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%, and the description does not explain the parameters beyond the schema. It says 'filtered' but does not elaborate on what status_filter (e.g., HTTP status code range) or resource_types (e.g., image, script) mean. Without further details, the agent cannot correctly construct filters. The description adds minimal value.

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 'Get a filtered summary of captured network traffic' clearly states the verb and resource, indicating it returns a summary based on filters. However, it does not explicitly differentiate from sibling tools like 'start_network_capture' or 'stop_network_capture', though the summary nature sets it apart. The purpose is clear but lacks detail on what kind of summary (e.g., counts, list) or how it relates to captures.

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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites like needing an active network capture, or contrast with start_network_capture. Since there are many sibling tools, the lack of usage context leaves the agent guessing.

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