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

With no annotations, the description carries the burden of behavioral disclosure. It explains that fields plus frame.len are extracted, grouping and summing are performed, and results are ranked by bytes. This is good transparency, though it omits potential performance implications or error handling, which prevents a 5.

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 well-structured with a one-sentence summary, followed by concise explanatory paragraphs and a Returns section. Every sentence carries useful information, and it is front-loaded with the core purpose.

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 4 parameters and no annotation support, this description is complete: it covers all parameters, default behavior, grouping logic, and return value summary. The output schema exists, but the description still adds clarity on ranking and table contents.

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 input schema has 0% description coverage, but the description fully compensates with an Args section that explains every parameter: file_path, group_by (with default and examples), display_filter, and top_n (with default and ranking meaning). This is exemplary parameter documentation.

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 opens with a specific verb and resource: 'Aggregate packet flows grouped by arbitrary tshark field combinations.' This clearly distinguishes it from sibling tools like get_conversations or get_flow_matrix by emphasizing arbitrary field grouping and aggregation, not just predefined flow views.

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 provides clear usage context through defaults and examples, such as grouping by ip.src,ip.dst,ip.proto and the optional display_filter. However, it does not explicitly state when to use this tool over alternatives or mention exclusions, so it falls short of full guidance.

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 provided, the description carries the full burden of behavioral disclosure. It explains that the tool extracts per-query details and summarizes top domains and NXDOMAIN failures, and it mentions reading a PCAP file. However, it does not disclose the read-only nature explicitly, nor does it mention potential side effects, performance considerations, or handling of large files. This is adequate but not deeply transparent.

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 and well-organized: a purpose sentence, a process sentence, and a structured Args/Returns breakdown. Every sentence adds value with no redundancy, making it efficient and easy to parse.

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?

The description covers the tool's inputs and outputs clearly, including the return summary content and purpose of each argument. It lacks edge-case details or caveats about large files or performance, but given the presence of an output schema and the straightforward nature of the analysis, it is reasonably complete. Minor gaps in behavioral context prevent a perfect score.

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 input schema has 0% description coverage, providing only types and defaults. The description's Args section fully compensates by clearly explaining each parameter: file_path as the PCAP path, display_filter as an optional extra filter, and top_n as the number of top domains. This adds significant semantic meaning beyond the schema.

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 the tool performs deep DNS traffic analysis with specific outputs like query patterns, response times, and error rates. It identifies the resource (DNS traffic) and the action (analyze), though it does not explicitly distinguish itself from sibling tools like extract_packet_details or analyze_pcap_file. The verb+resource is specific enough for strong purpose clarity.

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 the tool is used for analyzing DNS traffic from a PCAP file, providing some context for when to use it. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. This is adequate but minimal guidance.

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 takes on the burden of explaining behavior. It states what is extracted and the returned output (operation frequency table, per-IMSI summary) and gives the protocol stack context. It implies a read-only analysis but doesn't explicitly say so; still, it provides more behavioral context than most descriptions.

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 well-structured with a clear purpose, use case, protocol stack, parameter list, and return summary. Every sentence adds value, and it's appropriately sized for the tool's complexity.

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 specialized SS7 traffic analysis tool, the description provides protocol stack, use cases, parameters, and return summary. An output schema exists, so return details are covered. Minor gap: it doesn't mention behavior for non-MAP traffic or error conditions, but overall it's quite complete.

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's Args section is essential. It explains file_path as a PCAP path, display_filter as an optional extra filter, and top_n with its default. Each parameter is covered, though the filter syntax could be more precise.

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 explicitly states 'Analyse GSM MAP (Mobile Application Part) operations from SS7 traffic' with a specific verb and resource. It also lists extracted entities (operation codes, IMSI, MSISDN) and clearly differentiates from sibling tools like analyze_dns by focusing on MAP protocol.

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?

Provides clear context: 'Useful for telecom network auditing and SS7 security analysis' and gives a typical protocol stack (SCTP->M3UA->SCCP->TCAP->MAP), which helps identify when to use it. However, it does not explicitly mention exclusions or alternative tools, so it stops short of a 5.

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 full burden for behavioral disclosure. It mentions using TShark, supporting TLS decryption via keylog file, and default max_packets, which is useful. However, it does not describe the output format, potential resource usage, or edge cases, leaving the tool's behavior partially opaque.

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 appropriately sized and structured: a one-sentence overview followed by a clear Args list and a Returns line. Every sentence provides necessary information with no waste or redundancy.

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?

The tool has 4 parameters and no annotations, and the description covers the basics but lacks guidance on when to use it among many siblings. The return value is only described as 'Packet analysis output,' which is vague, though an output schema exists. More context about output format and use cases would improve completeness.

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 has no parameter descriptions (0% coverage), but the description provides an 'Args' section that explains each parameter: file_path, display_filter, keylog_file, and max_packets, including the default value for max_packets and the purpose of keylog_file. This fully compensates for the lack of schema descriptions.

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 the tool analyzes a PCAP file using TShark, which is a specific verb and resource. However, it does not differentiate from sibling tools like extract_packet_details or get_packet_statistics, so it lacks explicit sibling 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 usage through its parameter explanations (optional display filter, TLS keylog decryption, packet limit), but it does not explicitly state when to use this tool versus alternatives like get_packet_statistics or extract_packet_details. Usage context is present but no exclusions or alternative recommendations are given.

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 discloses the side effect of saving a PCAP file, the decryption mechanism, the need for the keylog file, and the return of decrypted content. It could mention the need for elevated permissions, but for most use cases the behavioral disclosure is solid.

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 well-structured and efficient: a one-sentence summary, a numbered workflow, a compact args list, and a returns line. Every element adds value, and there is no filler or repetition of the schema.

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 complexity (6 parameters, no schema descriptions, no annotations), the description covers all necessary aspects: purpose, prerequisites, workflow, parameter meanings, and output. The output schema is present, so the description appropriately summarizes return values rather than detailing them.

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?

With 0% schema description coverage, the description fully compensates by explaining every parameter: interface, keylog_file, output_pcap, packet_count (with default and max), duration (with default and max), and display_filter. This goes well beyond the schema's bare titles and provides actionable meaning.

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 opens with a specific verb+resource: 'Capture live TLS traffic and immediately show decrypted plaintext.' This clearly differentiates it from siblings like capture_live (which likely only captures) and follow_tls_stream (which decrypts from existing captures). The workflow makes the unique value obvious.

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 provides clear context for use: it requires the target app to write session keys to a keylog file and explains the prerequisite SSLKEYLOGFILE environment variable. It does not explicitly mention alternatives or when not to use this tool, but the workflow makes the appropriate usage scenario evident.

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 provided, the description carries the full burden of behavioral disclosure. It lists defaults and max values but does not disclose whether the capture stops at packet_count, duration, or whichever comes first, nor does it mention permission requirements, blocking behavior, or error handling. The 'Returns' line only says 'Captured packet summary' without detailing its contents.

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 and well-structured: a single-purpose opening line, a clearly labeled Args block, and a Returns section. Every sentence provides necessary detail with no redundancy or fluff, making it easy for an agent to parse quickly.

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?

While an output schema exists, the description misses several contextual elements for a network capture tool: when to choose this over capture_and_decrypt, the capture termination logic (packet count vs. duration), and any system-level prerequisites (e.g., admin rights). The parameter details are solid but the body of behavioral and usage context is insufficient for full confidence.

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 has 0% description coverage, so the description compensates by explaining each argument: interface is named and points to list_interfaces, packet_count has default and max, display_filter is described as optional, and duration has default and max. This adds meaningful context beyond the bare schema titles and defaults.

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 opens with a specific and clear statement: 'Capture live packets from a network interface.' This pinpoints the exact resource (network interface) and distinguishes it from offline analysis tools like analyze_pcap_file. The verb 'capture' is precise and action-oriented.

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 one practical hint: 'use list_interfaces to find names' for the interface parameter. However, it does not explicitly state when to use capture_live versus siblings like capture_and_decrypt or analyze_pcap_file, nor does it mention any exclusions or prerequisites beyond listing valid interfaces.

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?

The description discloses the snapshot-based BPF filter construction, automatic inclusion of new connections sharing the same ports, and the requirement that keylog_file must exist. It lacks disclosure of permission requirements (e.g., root) or error behavior for invalid PIDs, so it is informative but not exhaustive.

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 well-structured with a clear purpose, mechanics, prerequisites, Args, and Returns sections. Each sentence adds functional detail without redundancy, though the length is justified by the tool's complexity.

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?

The tool has a rich output schema, and the description covers capture mechanics, parameter semantics, and return summary. It omits error handling, permission requirements, and edge cases (e.g., process not found), leaving some context unaddressed.

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?

With 0% schema description coverage, the description compensates fully by explaining the meaning, defaults, and constraints of all six parameters, including the keylog_file format and pre-existence requirement.

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 'Capture network traffic from a specific process by its PID,' which is a specific verb, resource, and scope. It clearly distinguishes from siblings like capture_live or capture_and_decrypt by focusing on process-specific capture.

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 instructs to use list_processes() to find the PID and list_interfaces() for the interface, providing clear prerequisites. However, it does not explicitly contrast with alternative capture tools or state when not to use it, so guidance is implied rather than explicit.

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 burden. It discloses that files are reconstructed and written to output_dir, that output_dir must exist, and that returns a list with sizes or an error. It doesn't mention overwrite behavior or permissions, but the core side effects are clear.

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 compact and well-structured, leading with the tool's purpose, then a use-case sentence, followed by Args and Returns sections. Every sentence earns its place with no fluff.

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?

The description covers purpose, parameters, return value, and a key prerequisite (output_dir exists). Given the tool has an output schema, return details are sufficient. It lacks edge-case info like overwrite behavior or error handling specifics, but overall it is complete enough 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 0%, so the description must compensate. It does so fully: file_path is 'Path to the PCAP file', protocol is 'Protocol layer to extract from — one of: http, smb, tftp, imf, dicom', and output_dir is 'Directory where extracted files will be written (must exist)'. This adds crucial detail and enum values.

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 the tool extracts transferred files from a PCAP using tshark's --export-objects and writes them to a directory. It names specific protocols (http, smb, tftp, imf, dicom), distinguishing it from sibling tools that analyze packets or 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?

It explicitly states the tool is useful for forensic recovery of HTTP downloads, SMB transfers, FTP, and TFTP, providing clear context for when to use it. It does not explicitly exclude alternatives or name when-not-to-use scenarios, but the context is solid.

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 behavioral disclosure burden. It explains that TLS traffic can be decrypted when keylog_file is provided and that the output is JSON-formatted packet data. Minor gaps remain (e.g., file size implications, error cases), but the main behavior is well covered.

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 well-organized with Args and Returns sections. No filler or redundant wording; each sentence contributes useful information about the tool's purpose or parameters.

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?

All parameters and the return value are described, and an output schema exists. The description lacks details like display filter syntax or error handling, but for a straightforward export tool with an output schema, it is adequately complete.

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 0%, yet the Args section provides meaningful explanations for all four parameters: file_path, display_filter, max_packets, and keylog_file. This fully compensates for the missing schema descriptions and adds clear usage semantics.

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 'Export packets from a PCAP file as JSON' with a specific verb, resource, and output format. This differentiates it from siblings like extract_packet_details or extract_fields, which focus on different extraction or formatting behaviors.

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 structured analysis' implies when to use the tool, but there is no explicit guidance on alternatives or when not to use it. Sibling tools exist, but no comparative direction is provided.

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 provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by specifying the tab-separated output format, one packet per line, and the use of a keylog file for TLS decryption with example fields. It does not explicitly state read-only behavior, but this is strongly implied by the extraction nature and the provided examples.

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 well-structured with a summary, Args, and Returns sections. Every sentence contributes meaningful information, and there is no redundant or filler content. The length is appropriate for the tool's complexity.

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?

The description covers the tool's purpose, all parameters, return format, and decryption capability, making it largely complete for the given complexity. However, it lacks any mention of when to use this tool relative to siblings or potential limitations (e.g., handling very large files), which prevents a perfect score.

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 has 0% description coverage, but the description compensates thoroughly. Each parameter is explained in the Args section: file_path (path to PCAP), fields (comma-separated, with examples), display_filter (optional), and keylog_file (optional, for TLS decryption). It also clarifies the expected field syntax and decryption usage, adding meaning far beyond the bare schema.

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 the tool's purpose with a specific verb ('Extract') and resource ('packets in a PCAP file'), and adds the qualifier 'specific fields' which distinguishes it from broader tools like extract_packet_details or export_to_json. This makes the intent unambiguous.

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 guidance on when to use this tool versus sibling tools such as filter_and_save or extract_packet_details. The description explains how to invoke the tool but not the context in which it is preferred over alternatives, nor any exclusions.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only reveals that packet_number is 1-based and fails to mention error handling, file type requirements, or what constitutes 'detailed packet information.' This is a significant gap for an extraction 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?

The description is concise and well-structured with Args and Returns sections. Every sentence contributes value, and there is no fluff or repetition. It is appropriately sized for the tool's simplicity.

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?

Although an output schema exists, the description lacks contextual completeness. It does not explain how this tool fits among the many siblings, and the 'Returns: Detailed packet information' is vague and unhelpful for an agent trying to choose the right tool. The missing usage guidance is a significant omission.

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 input schema has 0% description coverage, but the description compensates by providing plain-language meaning for both file_path ('Path to the PCAP file') and packet_number ('The packet number to analyze (1-based)'). This exceeds the baseline for low-coverage cases and adds useful context.

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 the action ('Extract') and resource ('detailed information about a specific packet'), which distinguishes it from sibling tools that operate on aggregates or whole files. However, it does not explicitly name any alternative tools, so it misses the highest level of 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 provides no guidance on when to use this tool versus alternatives like extract_fields, analyze_pcap_file, or get_packet_statistics. It does not mention any exclusions or conditions, leaving the agent without direction for 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the input, output, and return value, but does not mention whether existing output files are overwritten, any permissions required, or potential side effects on the source file. The return status ('packet count written') is a useful behavioral detail.

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 efficiently structured with a one-sentence summary, an Args list, and a Returns note. Every line adds value and there is no filler or repetition of schema 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?

For a simple three-parameter tool with an output schema, the description covers the main input/output contract and return value. Minor gaps remain, such as overwrite behavior or error conditions, but the core functionality is well-specified for an agent to select and invoke the 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?

With schema description coverage at 0%, the description must add meaning to the bare parameter names. It does so with concise Arg definitions: 'Path to the source PCAP file', 'Path where the filtered PCAP will be saved', and a clear example for display_filter. This exceeds the baseline for parameters with no schema descriptions.

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 the action ('Filter packets from a PCAP file') and the outcome ('save the result to a new PCAP file'). This specific verb+resource structure distinguishes it from sibling tools like get_packet_statistics or export_to_json, which have different outputs.

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 you need a filtered PCAP file) but provides no explicit comparisons or exclusions relative to sibling tools. There is no 'use this instead of X' guidance, though the clear purpose makes the context evident.

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 present, so the description carries the full behavioral burden. It discloses the return format ('Reconstructed stream content as ASCII text') and the keylog_file caveat, indicating a limitation. However, it does not mention behavior for non-ASCII or binary stream content, which could be relevant. Still, it provides more transparency than many tools.

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 well-structured with a clear purpose statement, Args section, and Returns section. Every line provides necessary information without redundancy. The format is efficient and front-loaded with the core action.

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 4 parameters, no annotations, and an output schema that isn't detailed in the description, the description covers the essential aspects: what it does, parameters, return type, and the TLS alternative. It is slightly incomplete regarding edge cases like invalid file paths or protocol handling, but it is sufficiently complete for an agent to select and invoke the tool 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?

The input schema has no per-parameter descriptions (0% coverage), so the description must compensate. It does so by explaining each parameter: file_path, protocol (including the sctp option), stream_index with default, and keylog_file with its alternate-tool direction. This adds meaningful context beyond the bare schema.

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 opens with a specific action 'Follow and reconstruct a TCP or UDP stream', naming the tool's resource type. It also distinguishes itself from the sibling tool follow_tls_stream by directing users to that tool for decrypted TLS content, demonstrating clear 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?

Provides explicit guidance on when to use an alternative tool: 'When provided, use follow_tls_stream instead for decrypted TLS content.' This clearly communicates the boundary of the current tool and directs the agent to the correct sibling. Also implies this tool does not decrypt TLS, setting expectations.

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 provided, the description carries the transparency burden and does well: it discloses the dependency on an external keylog file, how to generate it, and the return format (ASCII plaintext). It does not explicitly state that the tool is read-only or what happens on keylog mismatch, but the disclosed information is substantial for a read-only analysis 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?

The description is well-structured with sections for purpose, keylog generation, args, and returns. Every part earns its place; the keylog examples are slightly verbose but necessary for usability. It is front-loaded with the main purpose.

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?

The tool has moderate complexity (TLS decryption with external keylog) and an output schema exists. The description covers prerequisites, parameters, and return type. It lacks discussion of edge cases (e.g., unsupported TLS versions), but overall it is complete enough for an agent to select and invoke 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?

The schema description coverage is 0%, so the description must compensate. It does: the 'Args' section explains the meaning of each parameter, including the default for stream_index. This adds clear value beyond the minimal schema titles.

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+resource construction: 'follow and reconstruct a decrypted TLS stream as plaintext.' It clearly distinguishes itself from sibling tools like 'follow_stream' by specifying TLS decryption and the need for a keylog file.

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 states the key prerequisite (TLS key log file) and provides concrete instructions for generating one across multiple browsers/runtimes. It implies when to use this tool (when you have TLS traffic and a keylog) but does not explicitly name alternatives or when not to use it, so it falls short of a 5.

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?

There are no annotations, so the description must convey behavior. It specifies the return as a 'conversation statistics table' and lists protocol options, but it does not mention potential errors, file requirements, or explicitly confirm that the operation is read-only (though 'Get' implies this).

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 and well-structured, with a clear one-sentence summary followed by Args and Returns sections. Every line adds useful information, and there is no redundant 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?

The output schema exists, so the description does not need to detail return values. It covers the key inputs and options, but could be more complete by mentioning error conditions or prerequisites like file accessibility.

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 input schema provides no descriptions for the parameters, and schema description coverage is 0%. The tool description compensates by explaining file_path as a PCAP file path and protocol as having a specific set of options (eth, ip, tcp, udp, sctp), adding meaning beyond the raw schema.

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 the tool's function: 'Get conversation statistics from a PCAP file.' It uses a specific verb ('Get') and resource ('conversation statistics'), and the mention of 'PCAP file' distinguishes it from sibling tools like get_packet_statistics and get_flow_matrix.

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 conversation stats are needed from a PCAP file) but does not explicitly compare it to alternatives or state when not to use it. No sibling tool is mentioned.

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 provided, the description carries the full burden of behavioral disclosure. It clearly explains the aggregation logic (group by src/dst, sort by total bytes descending) and identifies the specific fields used, giving the agent a good sense of what happens during execution, though it omits edge-case behavior like handling missing files or empty 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?

The description is well-structured with clear sections for Args and Returns, and the prose is efficient. The first paragraph and second paragraph share some redundancy (both mention aggregation), but the extra detail about field extraction and sorting is valuable and not excessive.

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?

The description covers the tool's purpose, parameters, and return value, making it functionally complete for invocation. It lacks explicit usage guidelines versus sibling tools, which is a minor gap, but given the output schema exists and the description provides all necessary details, it is overall complete.

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 has 0% description coverage, but the description compensates fully by providing a dedicated Args section that explains each parameter with concrete details (e.g., file_path is a PCAP, display_filter example 'not arp', top_n default 20). This exceeds the schema's sparse structure and gives the agent complete parameter understanding.

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 it builds a host-pair communication matrix showing traffic volume, with specific details about extracting ip.src, ip.dst, and frame.len fields. This distinguishes it from sibling tools like get_packet_statistics or aggregate_flows by focusing on host-pair aggregation and byte totals.

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 usage for analyzing host-pair traffic volume but does not explicitly state when to use this tool over alternatives. No exclusions or comparative guidance are provided, leaving the agent to infer based on the tool's name and description.

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 provided, the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, does not mention error conditions or side effects, and only vaguely says 'Returns: Packet statistics' without detailing behavior beyond the operation itself.

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 short, front-loaded docstring with a clear top-line purpose and clearly separated Args/Returns sections. Every sentence is purposeful and no filler is present.

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 simple one-parameter interface and the presence of an output schema, the description provides enough context for basic selection and invocation. It falls short only in missing explicit caveats or when-not-to-use guidance, but overall it is complete for a simple read-analyze 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?

The Args section adds meaning to file_path by describing it as 'Path to the PCAP file', which is absent from the schema's bare 'File Path' title. This compensates well for the 0% schema description coverage.

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 ('Get statistics about packets in a PCAP file'), making the basic purpose clear. However, it does not distinguish this from sibling tools like analyze_pcap_file or extract_packet_details, so it misses the last bit of 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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The only implicit context is that the tool is for packet statistics, but it lacks any comparison to sibling 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 provided, the description carries the full burden. It explains that the tool extracts specific tcp.analysis.* fields and computes aggregate statistics, which is useful. However, it does not disclose potential side effects (though likely none), error conditions, or prerequisites such as file accessibility. The return type is mentioned at a high level, but more behavioral detail could be added.

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 well-structured and concise. The opening sentence states the purpose, the second explains the underlying fields, and the Args/Returns sections provide essential input/output details without redundancy. Every sentence adds value.

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?

The tool is simple (2 params, 1 required) and has an output schema, so the description need not detail return structure. It covers input meaning, purpose, and usage context. However, it does not explicitly mention any constraints or caveats (e.g., PCAP must contain TCP traffic), which would make it more complete.

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 has zero descriptions for the two parameters, but the description compensates fully. It explicitly defines file_path as 'Path to the PCAP file' and display_filter as an optional filter with a concrete example ('ip.addr == 10.0.0.1'). This adds significant meaning beyond the raw schema types.

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 verb ('Analyse') and a specific resource ('TCP performance') with concrete metrics (RTT, retransmissions, window size, lost segments). This distinguishes it from sibling tools like get_packet_statistics or get_flow_matrix, which address different aspects of packet analysis.

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 clear context on when to use the tool: for diagnosing network quality via TCP performance analysis. It lists the relevant fields and the type of output (aggregate statistics). However, it does not explicitly state exclusions or alternatives, so it does not fully meet the highest bar.

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 burden. It discloses that the tool 'Uses tshark's io,stat to bucket traffic into fixed-width time windows,' which explains the underlying mechanism and output structure. It does not mention potential error conditions or file-modification behavior, but for a read-only analysis tool this is sufficient.

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 compact and front-loaded, with a clear purpose, mechanism, usage hint, and parameter list. Every sentence earns its place, and there is no redundant 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?

Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the essential aspects: what it computes, how it works, and parameter meanings. It doesn't explain return format details, but the output schema presumably handles that.

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 0%, so the description compensates by explaining all three parameters: file_path is 'Path to the PCAP file,' interval_seconds is 'Bucket width in seconds,' and display_filter is 'Optional display filter to restrict which packets are counted' with an example. This adds meaning beyond the raw schema definitions.

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 specifies the tool's function: 'Compute traffic volume over time — packets and bytes per interval.' It uses a specific verb ('Compute') and resource ('traffic volume over time'), and the time-series focus distinguishes it from siblings like get_packet_statistics and get_flow_matrix.

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 provides a clear use case: 'Useful for identifying bursts, sustained flows, and periodic patterns.' This implies when to choose this tool over others, though it doesn't explicitly state when not to use it or name alternative 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?

No annotations are provided, so the description carries full burden. It only states 'List available network interfaces' without disclosing any behavioral traits such as read-only nature, platform dependencies, or privilege requirements. The operation is simple but the description adds no safety or side-effect 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 extremely concise, consisting of two short sentences. It includes a 'Returns' section that clarifies the output, and every word earns its place without unnecessary fluff.

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 low complexity (no parameters), an output schema exists to define the return structure, and the sibling tools clearly indicate the capture context, the description is mostly complete. However, it could have briefly mentioned that this is intended to be used before starting a capture, which would provide slightly more 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?

This tool has zero parameters, so the baseline of 4 applies. The description adds no parameter-specific meaning, but that is unnecessary here since there are no parameters to explain.

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 ('List available network interfaces') and the resource ('for capture'). It distinguishes itself from sibling tools like capture_live or analyze_pcap_file, as listing interfaces is a distinct pre-capture step.

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 is provided on when to use this tool versus alternatives. While it's presumably used before capture tools, the description doesn't explicitly state this context or mention any alternatives.

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 the output format (table of PID and name) and the case-insensitive substring filtering, but does not mention whether it lists all system processes or only user processes, nor any permission requirements. It's not misleading, but lacks some behavioral depth.

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 compact and well-organized: purpose first, then usage guidance, then args and returns. Every sentence adds value without redundancy. Ideal structure for agent consumption.

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 simple tool with one optional parameter and an output schema, the description is nearly complete. It tells the purpose, how to use it, the parameter meaning, and the return shape. It lacks minor details like edge cases (no matches) or scope of 'running processes', but overall it is sufficient 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?

Despite the reported 0% schema coverage, the description provides rich semantics for the only parameter: 'Optional substring to filter process names (case-insensitive)' with examples. This fully compensates for the bare schema and gives the agent exact usage guidance.

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 ('List') and resource ('running processes with their PIDs'), and immediately links to a distinct use case ('find the PID to pass to capture_process'). This clearly distinguishes it from sibling tools like capture_process or list_interfaces.

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?

Explicitly states when to use the tool: 'Use this to find the PID to pass to capture_process.' This provides a clear contextual trigger and names the downstream tool. Though it doesn't list exclusions, the guidance is specific and actionable.

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 burden of behavioral disclosure. It explains the mergecap mechanism, timestamp ordering, and post-merge summary, and notes the return value. Missing are side effects like potential overwriting of the output file and 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?

The description is well-structured with a summary line, context, and dedicated Args/Returns sections. Every sentence contributes value, and there is no redundant or filler 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?

Given the tool's moderate complexity and the presence of an output schema, the description covers inputs, behavior, and return value sufficiently for selection and invocation. It could mention overwrite behavior or file format limitations, but these are minor gaps.

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 descriptions are absent, but the description fully compensates by explaining each parameter: comma-separated input paths with a minimum of 2, output file path purpose, and optional display filter. This adds clear meaning beyond the bare property names.

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: merging multiple PCAP files in timestamp order and analyzing the result. It distinguishes itself from sibling tools by focusing on multi-file correlation and mentions the underlying mergecap utility.

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 provides an explicit use case ('correlating events across different capture points') and explains when this tool is appropriate. However, it does not explicitly discuss alternatives or exclusions, so it stops short of full guidance.

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 transparency burden. It discloses the grouping behavior, inclusion of MAP op codes 'when present', and the return structure (per-dialogue message sequence with timestamps, message types, and MAP ops). It does not cover edge cases or failure behavior, but the core behavior is transparent.

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 well-structured with a purpose statement, protocol stack line, Args section, and Returns section. Every sentence adds value, and there is no repetition 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?

For a complex tool like SS7 TCAP reconstruction, the description covers purpose, parameters, and return values. The output schema exists and the Returns section adds useful detail. It lacks usage examples or caveats about malformed captures, but is generally complete.

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 input schema has 0% description coverage, so the docstring must compensate. It explains all three parameters: file_path, display_filter (with a concrete example), and max_dialogues (with its default). This adds real meaning beyond the bare schema.

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 opens with 'Reconstruct SS7 TCAP signaling dialogues from a PCAP file' – a specific verb and resource. It further explains the grouping by transaction IDs and inclusion of MAP operation codes, which clearly distinguishes this tool from siblings like analyze_map_operations or 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?

The description clearly implies the intended use case (reconstructing TCAP dialogues from PCAP files) and gives protocol stack context. However, it does not explicitly mention alternatives or exclusion criteria (when not to use), stopping short of a 5.

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 must carry the safety/behavior context. It states the tool executes tshark and returns output, but does not disclose potential side effects (e.g., file writes, capture activity), shell interpretation/quoting, privileges, or error handling. This is a meaningful gap for a command-execution 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?

The description is brief and structured with Args/Returns, containing no filler. It is appropriately sized but not excessively terse, and the Returns section is useful.

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 power as a raw command runner and the existence of many specialized alternatives, the description is incomplete: it lacks usage guidance, failure behavior, security caveats, and exact return semantics. The output schema helps but does not cover these.

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 has 0% description coverage, and the tool description's Args line adds only 'The command line arguments to pass to tshark', which largely restates the property name. It does not specify how multiple arguments are delimited, whether quoting is required, or whether shell features are available. Critical details for correct invocation are missing.

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 identifies the action: run a TShark command with user-supplied arguments. It uses a specific verb and resource, but does not explicitly distinguish this raw wrapper from the many specialized tshark sibling 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?

There is no guidance on when to use this instead of the specialized siblings (follow_stream, analyze_pcap_file, etc.), nor any exclusions or prerequisites. The only hint is 'with the given arguments,' implying a generic escape hatch, but 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 discloses that the tool returns instructions (not actual decryption) and specifies the content. It doesn't detail output format, but for a zero-parameter manual tool, this is sufficiently transparent.

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 concise sentences: the first states the tool's purpose and content, the second gives a clear usage directive. No filler or repetition.

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 simplicity (zero parameters) and the presence of an output schema, the description covers all necessary information: what it provides and when to call it.

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?

There are no parameters, so parameter semantics are not applicable. The baseline of 4 for zero-parameter tools 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 clearly states the tool provides 'detailed workflow instructions' for TLS/SSL decryption setup, including x64dbg key extraction. This distinguishes it from sibling tools like capture_and_decrypt that would actually perform decryption.

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 explicitly says 'Call this tool BEFORE attempting to decrypt TLS traffic,' providing clear timing guidance. It doesn't name alternatives but gives a definitive usage context.

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