wireshark_index

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds real behavioral context beyond that, namely that the index is built once and persists for reuse by aggregate/extract_fields and can be exported to Parquet. It still omits what the drop and status actions do, where the index lives, and whether re-building overwrites an existing index.

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?

Every fragment carries information and the key reuse rule is front-loaded, so nothing is filler. But the telegraphic style ("query: SELECT on packets/pkt/flows/captures") is cryptic enough that an agent must parse meaning out of fragments rather than sentences, costing clarity for brevity.

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 tool with seven distinct actions, six undocumented parameters, and no output schema, the description is substantially too thin. Two actions (status, drop) go entirely unmentioned and one parameter (display_filter) has no explanation anywhere, leaving an agent unable to call several modes correctly.

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 carry the load, and it partly does: more_files is explained as extra captures with capture_id, sql is grounded with "SELECT on packets/pkt/flows/captures," and compare_filter is tied to diff. But display_filter is never mentioned, pcap_file (the only required parameter) is left implicit, and the status/drop enum values are undocumented.

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 bracketed tag [Index] plus "Build once" implies an indexing/caching step, but the description never states the resource it operates on (a pcap file) or that it is a multi-action dispatcher. The per-action fragments (query, timeline, diff, export) sketch the capabilities without a clear headline verb+resource statement, unlike a definition that would read "Index a pcap file for reuse by aggregate/extract_fields."

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?

"Build once; aggregate/extract_fields reuse it" gives a genuine prerequisite rule and "diff: vs more_files/compare_filter" routes one parameter correctly. However, there is no guidance on when NOT to index, no mention of the status or drop actions, and no comparison to the sibling open_file/read_packets path an agent might otherwise take.

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