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

No annotations are provided, so the description carries the full burden. It discloses detection methodology (time-delta variance, CoV, jitter%, median interval), benign infrastructure filtering, and confidence ratings (HIGH/MEDIUM/LOW). However, it does not state read-only nature, permissions, rate limits, or output format, leaving meaningful behavioral gaps.

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?

Two sentences, front-loaded with the core detection technique and followed by filtering and confidence details. No redundant or filler language; every part earns its place.

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 packet analysis tool with no output schema, the description explains detection logic and confidence output but omits crucial input requirements (at least one of input or filePath is needed despite zero required parameters) and the return structure. This is adequate but incomplete for correct invocation.

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 100%, so all four parameters are fully documented in the schema. The description mentions filtering benign infrastructure (relating to includeBenign) and confidence ratings, but adds no syntax or constraints beyond what the schema already provides. Baseline 3 is appropriate.

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?

States a specific verb 'Detects' and resource 'periodic C2 beacon communications', plus the statistical method used. However, it does not differentiate from the sibling packet_detect_dns_tunneling or clarify how it relates to other packet_* tools.

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 gives no when-to-use guidance, no prerequisites, and no alternatives (e.g., when to choose this over packet_detect_dns_tunneling). Usage is only implied by the tool name and detection purpose.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the detection methodology (Shannon entropy, label lengths, hex/base32/base64 encodings, CDN heuristics), which is genuine behavioral context, but says nothing about I/O format, cost/performance, whether it is read-only, or how a detection is reported.

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?

Two dense sentences, front-loaded with the purpose and then the technique list. No filler or restatement of the name.

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 stateless PCAP analyzer with a fully documented schema and no output schema, the description is nearly sufficient: it explains what it detects and how. It stops short of noting input requirements or result shape, which for a no-output-schema tool would have been a useful addition.

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 100%, so input, filePath, and minSubdomains are all self-documented, and the description adds no parameter-level detail. Baseline 3 applies when the schema does all the work.

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?

States a specific verb ('Identifies') and a narrow resource ('DNS data exfiltration and tunneling channels') with named threat examples (dnscat2, iodine, Cobalt Strike DNS beacons). This inherently separates it from packet_extract_dns (record extraction) and packet_entropy, but it never explicitly addresses overlap with the sibling packet_detect_beacons, which also covers DNS beacons.

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 threat examples imply when the tool is relevant (hunting for covert DNS channels), but there is no explicit 'use this when / use X instead' guidance and no mention of the prerequisite PCAP input. With packet_detect_beacons as a close sibling, routing guidance would materially help.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explains the output range (0.0 to 8.0 bits/byte) and the interpretive meaning, which is useful, but does not disclose critical behavioral traits: whether it processes an entire PCAP or a single packet by default, whether it requires a local file or accepts base64, any rate limits or size constraints beyond what the schema states, or whether the operation is read-only or has side effects. For a tool with zero annotation coverage, this is a significant gap.

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, front-loaded sentence that states the purpose and interprets the metric's output range and meaning. Every clause earns its place; there is no redundancy or filler.

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 tool's moderate complexity (3 optional parameters, no output schema) and the presence of no annotations, the description covers the core concept and output range but omits behavioral details such as default scope (single packet vs. full PCAP), performance constraints, and usage context relative to sibling detection tools. It is minimally viable but leaves gaps for an agent to infer correct invocation.

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 100%, so the schema already documents all three parameters (input, filePath, packetIndex) with clear descriptions including type, format, and constraints. The description adds no parameter-level detail beyond what is in the schema, so the baseline of 3 is appropriate.

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?

States a specific verb (calculates) and resource (Shannon entropy of packet payloads), and explains its analytical role: distinguishing plaintext, structured data, and encrypted/compressed malware or C2 traffic. This differentiates it from siblings like packet_detect_beacons or packet_ja3_fingerprints by framing the output as a randomness metric rather than a detection or extraction result.

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 entropy is useful (evaluating payload randomness), but does not explicitly state when to choose this tool over alternatives such as packet_detect_beacons or packet_ja3_fingerprints, nor does it provide any exclusions or prerequisites. No guidance on input selection (PCAP bytes vs. file path vs. packetIndex) is given beyond what the schema provides.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses output structure (sent/received packet and byte counts, duration, TCP flag lifecycles) and the ranking rule (total bytes transferred), which is real behavior beyond the schema. However it says nothing about the input vs filePath trade-off, resource/latency behavior, or error handling.

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?

Four sentences, zero waste, front-loaded with the core identity before the computed metrics and the ranking clause. Every sentence contributes information.

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?

There is no output schema, so the description correctly compensates by describing what is returned (counts, duration, flag lifecycles, ranking). The remaining gap is operational: no guidance on choosing between the base64 'input' and on-disk 'filePath' modes, and no note on cost limits beyond the schema's stated 10MB.

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 100%, so the schema already documents input, limit, and filePath fully. The description adds no parameter-level meaning (e.g., which input mode is preferred, interaction between limit and ranking). Baseline 3 applies when the schema does the heavy lifting.

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 states a specific verb and resource ('Aggregates and tracks bidirectional 5-tuple conversations') and then enumerates exactly what is computed. The flow/conversation framing cleanly distinguishes it from the protocol-specific siblings (packet_extract_dns, packet_extract_http, packet_extract_tls_sni, etc.).

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?

No explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. Usage is only implied by the description: use it for flow-level, conversation-oriented analysis rather than payload extraction. An agent gets the gist but no routing rules.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the targeted credential classes ('cleartext and recoverable'), which tells the agent what findings to expect. It omits anything about output structure, false-positive behavior, or requirements (e.g., that one of input/filePath must be supplied), leaving meaningful gaps for a no-annotation tool.

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?

A single dense sentence that is front-loaded with the purpose and then lists the coverage areas. Every clause earns its place; nothing is redundant.

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 annotations and no output schema, the description should do more work: it never states that exactly one of input/filePath is required, nor what a finding/result looks like. The protocol coverage is thorough, but the operational and return-value context is thin for an extraction tool.

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 100%, so the two parameters (base64 PCAP bytes, absolute filePath) are already fully documented by the schema. The description adds no parameter-level detail, so the baseline of 3 applies.

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?

States a specific verb (hunts for/extracts) and resource (credentials) and enumerates the exact protocols and carrier fields it inspects: HTTP Basic/Digest headers, URL query params, POST bodies, FTP USER/PASS, SMTP auth. This level of scope detail lets an agent distinguish it from the generic packet_extract_http sibling immediately.

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 enumerated protocol/field scope implies when the tool is applicable, which is useful context. However, there is no explicit when-to-use vs when-not guidance and no named alternative (e.g., use packet_extract_http for raw HTTP extraction, this tool for credential-focused hunting). Usage is inferred, not stated.

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

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

With no annotations, the description carries the full burden. It discloses useful behavioral traits—label pointer loop protection and aggregated output—but omits safety/read-only status, permissions, and input handling constraints (e.g., the 10MB limit is only in the schema).

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?

Two tight sentences with zero waste: the core extraction purpose is front-loaded, and the second sentence efficiently lists the aggregation and transaction details. No redundancy or filler.

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 steps in to describe return aggregates and transaction details. Combined with full schema coverage for parameters, it is nearly complete for a simple extraction tool, though it lacks any usage-routing 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 description coverage is 100%, so the schema already documents all parameters including input, limit, filePath, and queryType. The description adds no parameter-level detail beyond listing DNS record types, so the baseline 3 is appropriate.

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 ('Extracts and parses') and resource ('DNS queries and responses'), and adds scope (RFC 1035) plus extra parsing features. It does not, however, differentiate from siblings like packet_detect_dns_tunneling or packet_summary, so it falls short of a 5.

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?

No explicit when-to-use, when-not-to-use, or alternative tool routing is provided. The purpose implies extraction, but the description gives no guidance on choosing this over related DNS or summary tools.

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

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

With no annotations, the description carries the full burden. It does disclose genuine behavioral traits: TCP stream reassembly, HTTP/1.x only, chunked transfer handling, and a 4KB body preview cap. However, it omits anything about error behavior on non-HTTP or malformed streams, or what happens when no transactions are found, so the disclosure is partial.

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?

Two tight sentences, front-loaded with the core action, with no wasted preamble. The trailing phrase 'cognitive guidance hints' is vague filler that does not clearly describe an output, slightly weakening an otherwise efficient structure.

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, the description usefully enumerates what is extracted (method, URI, headers, status codes, chunked transfers, body previews), effectively standing in for return-value documentation. It is nearly complete for a 4-param extraction tool, lacking only guidance on empty/failed extraction results.

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 100%, so all four parameters (input, limit, method, filePath) are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 states a specific verb and resource: 'Reassembles TCP streams and extracts HTTP/1.x requests and responses.' The HTTP/1.x focus cleanly distinguishes it from siblings like packet_extract_dns, packet_extract_tls_sni, and packet_extract_websocket.

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?

There is no when-to-use guidance, no prerequisites, and no named alternatives. An agent must infer that this is the HTTP tool from the name and the protocol mention alone, with nothing about when to prefer it over packet_extract_conversations or packet_filter_export.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that only RFC 9001 Initial-packet secrets are AEAD-decrypted, implying post-handshake QUIC packets are not recoverable, and bounds scope to QUIC v1. It does not state failure behavior, permission/read-only status, or payload size limits beyond the schema.

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?

A single front-loaded sentence with no filler, and the core scope (SNI/ALPN/Connection IDs from QUIC Initial) leads. It is jargon-dense with a long trailing technical clause, but every element is informative rather than padding.

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 annotations and no output schema, the description must justify both the tool's behavior and its results. It adequately frames the input scope and decryption method but never hints at the shape of the returned handshakes (fields, per-packet grouping) nor the interaction between the input and filePath parameters.

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 100%, so input, limit, and filePath are already fully documented. The description adds no syntax, format, or exclusivity guidance (e.g. input vs filePath) beyond the schema, so the baseline 3 applies.

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?

States a specific verb (Extracts) and precise resource (SNI hostnames, ALPN tags, DCID/SCID) scoped to QUIC v1 / HTTP/3 Initial packets over UDP 443. The protocol qualifier cleanly distinguishes it from the sibling packet_extract_tls_sni.

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?

No explicit when-to-use or when-not-to-use statement, and it never names the sibling packet_extract_tls_sni as the alternative. Usage is only implied by the protocol/port scope, leaving the agent to infer that QUIC traffic (not TLS-over-TCP) is the trigger.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that no payload decryption occurs and that output is frequency-ranked, which is real added context. It omits whether the operation is read-only, any size/permission constraints, and the local-only vs base64 input tradeoff.

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?

Two tight sentences, front-loaded with the extraction target and closed with the non-decryption constraint and ranking behavior. No wasted text.

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 read-only extraction tool with no output schema, the description conveys the essential return shape (ranked domains plus client metadata). It could say more about what 'client metadata' includes, but nothing critical to invocation is missing.

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 100%, with each of input, limit, and filePath fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail (e.g., that input and filePath are alternatives).

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?

States a specific verb (extracts) and resource (SNI hostnames / client metadata from TLS ClientHello), plus a secondary behavior (frequency ranking). It implicitly separates itself from packet_extract_quic_sni by scoping to TLS, but never names siblings explicitly.

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?

No guidance on when to choose this over packet_extract_quic_sni, packet_ja3_fingerprints, or packet_extract_http. The reader must infer from the protocol name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses useful processing details (TCP reassembly, frame parsing, unmasking, decoding), but omits safety profile (read-only vs destructive), auth requirements, output format, error behavior, and resource limits.

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?

A single dense sentence with no wasted words, front-loading the core actions before the triage context. It is efficient and readable, though slightly run-on due to multiple comma-separated clauses.

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 packet extraction tool with no annotations and no output schema, the description covers the processing pipeline but leaves return shapes, output size considerations, and sibling selection criteria unstated. The schema handles inputs, but the agent lacks guidance on interpreting results.

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 100%, so the schema already documents input, limit, and filePath thoroughly. The description adds no parameter-level detail, syntax, or constraints beyond the schema, which is the baseline expectation in this case.

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?

States specific verbs and resource: reassembles TCP streams, parses RFC 6455 WebSocket frames, unmasks client payloads, decodes text/JSON messages. The WebSocket scope inherently distinguishes it from siblings like packet_extract_http or packet_extract_tls_sni, but it does not explicitly contrast alternatives.

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 'for persistent C2 or chat triage' implies a use case, but there is no explicit guidance on when to choose this over sibling extractors, no prerequisites, and no exclusions or conditions for use.

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

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

With no annotations, the description carries the full burden. It usefully discloses the output side effect (base64 inline or written to disk) and the guaranteed output format (RFC-compliant classic PCAP), but says nothing about permissions, overwrite behavior, or that PCAPng input is re-encoded to classic PCAP.

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?

A single front-loaded sentence that states the filter criteria first and the export artifact second, with no filler. It is efficient, though the list is slightly inaccurate as noted above.

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 6-parameter, 0-required, no-output-schema tool, the description covers the high-level purpose and output format, but omits what happens when no filters are supplied, the phantom 'time window' input, and any constraints on the disk-write path.

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 the baseline would be 3, but the description adds a 'time window' filter that does not exist among the six schema properties, which is actively misleading rather than additive. The other named filters (IP, port, protocol) merely restate schema fields.

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 gives a specific verb+resource pair: it filters PCAP/PCAPng traffic and exports a classic PCAP binary. It implicitly separates itself from the packet_extract_* siblings by producing a PCAP artifact rather than structured logs, but it never names or contrasts with any alternative tool.

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?

There is no when-to-use guidance and no mention of when this is preferable to the many siblings (e.g., packet_list, packet_extract_conversations). Usage is only implied by the phrase 'Filters ... and exports', leaving the agent to infer routing on its own.

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

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

With no annotations the description carries the full burden, and it does disclose a real behavioral trait: output is enriched with correlations against known C2 frameworks and automation tools. However it says nothing about which input form is required (input vs filePath), capture size or performance limits, or the shape/reliability of the correlation results.

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?

Two sentences, no filler, and the core extraction capability is front-loaded ahead of the enrichment detail. Every clause earns its place.

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 three-parameter forensic tool with no annotations and no output schema, the description covers what is produced (fingerprints plus C2 correlation matches) but omits which of the two input parameters is expected and any indication of result structure. Adequate but visibly short of what the tool's complexity warrants.

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 100%, so the schema already documents input, filePath and the limit/default/maximum constraints. The description adds no parameter-level semantics such as format expectations or how limit interacts with aggregation, so the baseline 3 applies.

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 names a precise verb pair (extracts and aggregates) and a precise resource (JA3, JA3S and JA4 TLS client fingerprints), then adds the C2-correlation step. An agent can immediately distinguish this from packet_extract_tls_sni, which deals in SNI names rather than fingerprint hashes.

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?

It never states when to reach for this tool versus siblings such as packet_extract_tls_sni or packet_detect_beacons, nor any prerequisite or exclusion. Usage is only inferable from the threat-hunting framing of the second sentence.

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

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

With no annotations, the description carries the full behavioral burden. It discloses pagination defaults and context-limit enforcement, but omits what it returns per record, whether the operation is read-only (implied but unstated), and how the mutually exclusive 'input' vs 'filePath' sources behave when both or neither are supplied.

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?

Two tight sentences with the core action front-loaded and no filler. The limit recital mildly duplicates the schema, but the phrasing is efficient overall.

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 five-parameter tool with no output schema, no annotations, and zero required parameters, the description should clarify that a source (input or filePath) must be provided. It also says nothing about the return record shape or pagination continuation, leaving real gaps for the agent.

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 100%, so the schema already documents all five parameters thoroughly, including limit bounds and offset semantics. The description adds the rationale for the limit (context protection) but no new syntax or format detail, matching the baseline 3.

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?

States a specific verb ('Returns'), resource ('packet summary records'), and source ('from a PCAP capture'), so the agent knows exactly what it gets back. However, it never distinguishes itself from the sibling 'packet_summary', leaving ambiguity about which list/summary tool to choose.

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 gives no when-to-use guidance, no mention of alternatives like packet_summary or packet_filter_export, and no prerequisites. The only guidance is about pagination limits, which is operational detail rather than tool selection.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose meaningful traits: a bounded output size (<2KB JSON) and, importantly, a coverage limitation — that SMB, Kerberos, and SSH are flagged as unparsed rather than analyzed. It stops short of stating performance/capture-size limits for large inputs or confirming the read-only nature explicitly.

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?

Two dense sentences with zero wasted words, and the key scoping facts (L3–L7, <2KB, reconnaissance) are front-loaded before the content enumeration.

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 read-only summary tool with no output schema, the description covers what the agent needs: the return contents (totals, talkers, per-protocol volumes), the size bound, and the notable limitation on unparsed protocols. Nothing critical to correct invocation is missing.

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 100%, so both parameters (base64 input and the local-only filePath) are already documented in the schema. The description adds no incremental parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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?

States a specific verb+resource (triage summary over packet data) with explicit scope 'L3–L7' and enumerates the contents: packet totals, talkers, DNS/HTTP/TLS volumes, and warnings. This clearly differentiates it from the sibling tools, which are targeted extractors, positioning it as the high-level overview rather than a focused dissection.

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?

Calls itself 'fast reconnaissance,' which clearly signals when it should be reached for first, before drilling into specific extractors. However, it does not explicitly name an alternative or state when NOT to use it (e.g., when a specific protocol extraction is the goal), leaving that routing implicit.

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

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

With no annotations, the description carries the full burden; it usefully discloses the output format and a key negative constraint (no Zeek scripting engine execution). However, it omits whether output is written to disk or returned inline, what happens on malformed/oversized PCAP, and any size limit beyond the schema's 10MB note.

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?

Two tight sentences: the primary capability with format and target sinks is front-loaded, and the parenthetical limitation follows. Every clause earns its place with no filler.

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 no annotations and no output schema, the description should say more about the return contract (file paths written? TSV returned?) and note that one of input/filePath must be supplied, since both are optional in the schema. The format disclosure partially compensates, but a key operational gap remains.

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% – both input (base64, 10MB cap) and filePath (absolute path, local stdio only) are already documented in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.

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?

States a specific verb (exports) and a concrete resource (connection/DNS/HTTP events) plus the exact output shape (Zeek-compatible TSV: conn.log, dns.log, http.log). It is distinguishable from packet_extract_dns/http because of the multi-protocol Zeek TSV framing, though it never explicitly draws that contrast with those siblings.

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?

Usage context is implied through the SIEM-ingestion framing (Splunk, ELK, Wazuh) and the caveat that it does not run Zeek scripting. There is no explicit when-to-use-vs-alternative guidance, so an agent must infer that this tool supersedes the single-protocol extract siblings for Zeek pipelines.

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