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

With no annotations, the description must carry the behavioral disclosure burden. It explains the high-level classification behavior but never says whether the tool reads a capture file, how it detects 'silent timeouts', whether it is read-only, or what the analysis consumes/produces beyond the output 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?

The description is a single, front-loaded sentence that communicates the core distinction with no filler. Every word adds meaning, making it an efficient opener for the tool.

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 may cover return structure, but the tool is missing critical input semantics and behavioral context. The path parameter is unexplained, there are no annotations, and the description does not state what kind of input is expected, leaving an agent uncertain before calling 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?

The only parameter, 'path', has no schema description and the tool description does not mention it at all. At 0% schema coverage, an agent has no way to know whether path refers to a pcap file, a directory, a remote endpoint, or something else.

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 analytical action—separating reset/refused TCP connections from silent timeouts—and names the exact resource (handshake failures) plus the context (service unreachable). This clearly distinguishes the tool from siblings like find_tcp_anomalies or measure_rtt.

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 'when a service is unreachable' gives a clear invocation context and the intended diagnostic distinction. It does not explicitly name alternatives or when-not-to-use cases, but the condition is concrete enough to guide 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 provided, the description carries the full burden of behavioral disclosure. It only describes the high-level inventory/highlighting function and does not reveal whether the tool is read-only, whether it requires a file path to a capture, how it handles malformed input, or what side effects or limitations exist.

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 concise sentence with no wasted words, and the key function is front-loaded. It loses a point because it is so sparse that it omits necessary context about the required parameter and usage boundaries.

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?

Even though an output schema exists, the description is incomplete for practical invocation: the required 'path' parameter is unexplained, there is no guidance on input type, and there is no differentiation from related TLS/security-analysis siblings. An agent would need to inspect external documentation or guess to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention the required 'path' parameter at all. The agent is left to guess whether 'path' is a file path, directory, URL, or something else, and no guidance is given about acceptable formats or 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 states a specific verb ('Inventory'), a specific resource ('TLS handshake versions and SNI'), and a clear goal ('highlighting legacy protocols'). However, it does not explicitly distinguish this tool from related siblings such as analyze_handshake_failures or show_protocol_hierarchy, so it stops short of full 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 gives no guidance on when to use this tool versus alternatives like inspect_http_requests, inspect_dns_queries, or analyze_handshake_failures. It implies a TLS security posture use case, but it never states conditions, exclusions, or relevant scenarios.

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 an important behavioral trait: results are heuristic leads, not verdicts, and require manual review. This is meaningful transparency, though it does not discuss input requirements or potential false-positive behavior in more 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 two short sentences that front-load the tool's purpose and immediately add a critical usage/interpretation rule. There is 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?

Although the tool is relatively simple and an output schema exists, the description leaves the sole required input parameter undefined and provides no sibling-selection guidance. The clear purpose and lead-framing do not compensate for the missing path semantics.

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% and the description never mentions the required 'path' parameter. An agent sees only a generic string property named 'path' with no indication of whether it should be a file, directory, URL, or how it relates to the detection task.

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 first sentence states a concrete action and resource: 'Find heuristic port-scan, periodic beacon, and DNS-tunnel leads.' It names three specific pattern categories and frames the output as leads, which clearly differentiates this tool from the more targeted sibling inspection 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 implies a triage use case—heuristic detection for manual follow-up—but it does not explicitly say when to prefer this tool over siblings like inspect_dns_queries or find_tcp_anomalies, nor does it state when not to use it.

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 transparency burden. It discloses a key behavioral guarantee: credential values are never returned, which is a safety-relevant trait beyond the tool name. It also implies heuristic, non-exhaustive matching via 'likely'. It does not mention what is returned instead, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence conveys the core function and an important constraint. Every word 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?

The tool is simple with one required parameter and an output schema, so return-value details are covered. However, the description leaves unspecified what 'path' should point to (e.g., a capture file, directory, or system path) and offers no usage context, which is a noticeable gap given no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain the 'path' parameter at all. The parameter name is self-explanatory, but with low schema coverage the description should compensate, and it does not.

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 precise action ('Locate likely cleartext credentials') and adds a critical qualifier ('without ever returning credential values'). This clearly differentiates it from credential-extraction or inspection tools and makes the tool's purpose 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?

No guidance is provided about when to use this tool versus any of the sibling tools. The description does not mention alternatives, exclusions, or prerequisites, leaving the agent to infer usage from the 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?

With no annotations, the description itself must signal behavioral traits. The verb 'Find' clearly indicates a read-only inspection, and enumerating the anomaly types tells the agent what kind of evidence to expect. It does not state side effects or prerequisites, but the non-mutating nature is apparent from the wording.

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 short sentences, with the tool's function front-loaded and the usage context immediately following. No redundant or vague wording.

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 presumably covers return values, and the description provides clear purpose and usage. However, the unaddressed meaning of 'path' leaves a gap for correct invocation: an agent cannot be certain what path type or format to supply, which is a meaningful omission for a single-parameter 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 schema defines a single 'path' string with no description (0% schema description coverage), and the description never mentions this parameter. The agent is left to infer that 'path' likely refers to a packet capture file, but the description does not compensate for the schema's silence.

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 ('Find') and names four concrete anomaly types (retransmission, reordering, zero-window, duplicate-ACK), which clearly distinguishes it from sibling tools focused on DNS, HTTP, RTT, handshakes, and other network aspects. The scope is instantly clear.

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 second sentence gives explicit context: 'Use this for slow or unreliable transfers.' It does not name alternative tools or exclusions, but it provides a clear conditional use case that helps an agent decide when this tool is appropriate.

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. 'Inspect' implies a read-only operation and the description usefully lists the inspected fields, but it does not state side effects, data scope, or any operational limits. It is adequate but not fully 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 a single, front-loaded sentence that states the action, the inspected data, and the use case without any wasted words. It is concise while containing meaningful substance.

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 only the single 'path' parameter and 0% schema description coverage, the description leaves a critical gap: what path should point to and how it relates to DNS inspection. The output schema may cover return shape, but the input is not sufficiently specified for reliable 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%, and the description never mentions the 'path' parameter. The schema only says it is a required string, leaving an agent to guess what path refers to. The description does not compensate for this ambiguity.

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 identifies a specific action ('Inspect'), a precise resource ('DNS names, response codes, and frequency'), and a clear investigative context ('resolution or domains'). This clearly distinguishes it from sibling tools focused on HTTP, TCP, TLS, and other protocol areas.

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 an explicit usage context: use when investigating resolution or domain-related issues. It does not explicitly name alternatives or exclusions, but the subject matter is distinct enough among the siblings that the intended use is clear.

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. 'List' implies a read-only operation and the warning to treat all returned strings as untrusted peer data is a useful behavioral/safety disclosure. However, it does not describe limits, authentication, or how boundedness is applied.

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 terse sentences front-load the purpose and add a security note without waste. Every word 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?

Despite an output schema and low complexity, the description leaves the primary parameter undocumented and provides no usage context beyond the bare list operation. More guidance is needed for a complete tool definition.

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% for the only parameter (path), and the description adds no meaning to it. An agent cannot tell whether path is a file path, URL path, filter, or something else.

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 clear verb (List) and resource (bounded HTTP request metadata), which distinguishes it from siblings focused on DNS, TCP, or TLS. The term 'bounded' is slightly vague, so not a perfect 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 guidance on when to use this tool versus alternatives like inspect_dns_queries or detect_suspicious_patterns, and no exclusions or alternative conditions 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 core behavior: ranking conversations by byte count and targeting the largest flows. However, it does not state whether the operation is read-only, whether there are side effects, or what the ranking order/return format is, though 'largest flows' implies descending order.

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 with no filler. It conveys the action, resource, criterion, and use case efficiently, earning its place without unnecessary elaboration.

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 three parameters, no annotation coverage, and zero schema descriptions, this description is too thin. It fails to define the required path, the meaning of top_n, or the expected protocol value format, and the presence of an output schema does not compensate for missing input semantics.

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 partially covers the 'protocol' parameter by naming TCP, UDP, and IP, and it hints at the ranking metric. But it does not explain the required 'path' parameter or the 'top_n' behavior, leaving critical input semantics undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific action ('Rank'), resource ('conversations'), scope ('TCP, UDP, or IP'), and criterion ('by bytes'), with a clear use case ('identifying the largest flows'). It does not explicitly distinguish itself from sibling tools, but the function is clear and unique enough among the listed 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?

The phrase 'when identifying the largest flows' gives an explicit context for when this tool is appropriate, and the protocol qualifier narrows the applicability. It does not mention alternatives or exclusions, but the stated use case is sufficient for an agent to select it.

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 disclosure burden. It reveals the operation is a measurement, but does not describe input requirements, output semantics, performance implications, or any constraints. The agent is left to infer behavior from the tool name.

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 with no filler. It efficiently conveys the core purpose and the two scoping modes, though it sacrifices necessary parameter context for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The presence of an output schema reduces the need to describe return values, but the required 'path' parameter is left ambiguous and there are no annotations to fill any behavioral gaps. For a tool with one required parameter, this is a significant completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only adds meaning to 'tcp_stream' ('globally or for one TCP stream'). The required 'path' parameter is completely unexplained — it is not stated to be a capture file path or what formats are supported. The description does not adequately compensate for the schema's missing 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 states a specific action ('Measure RTT distribution and jitter') and resource scope ('globally or for one TCP stream'). It clearly distinguishes the tool from siblings focused on DNS, HTTP, TLS, and anomaly detection, though it doesn't explicitly name 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 description implies two usage contexts: measure across the whole capture or narrow to one TCP stream via the 'tcp_stream' parameter. However, it doesn't explicitly say when to prefer this tool over the sibling analysis tools or what conditions justify the per-stream option.

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. 'Bounded' hints at output or execution limits, and 'extract named fields' describes the core operation. However, it does not explain what happens on invalid filters, whether the capture is modified, or how results are limited.

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 with no filler. Every word contributes to the tool's core purpose, making it easy to scan and understand 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?

Given zero parameter descriptions and no annotations, this description is too thin to fully equip an agent. It conveys the general action but omits prerequisite knowledge about the path, filter syntax, field extraction format, and behavioral constraints beyond the vague word 'bounded'.

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 for undocumented parameters. It connects 'named fields' to field extraction, but it does not clarify that 'path' is a capture file path, how display_filter syntax should be formed, or the format of fields_csv beyond what the parameter name already suggests.

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 specific verbs ('Run', 'extract'), a clear resource ('Wireshark display filter'), and a clear outcome ('extract named fields'). This distinguishes it from the sibling tools, which are specialized analyses like inspect_dns_queries or detect_suspicious_patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not state when to prefer this tool over sibling alternatives, nor does it give exclusions or conditions. 'Bounded' implies a scoped query, but no explicit guidance is provided about using it for custom field extraction versus specialized 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 of behavioral disclosure. It only says 'show' the hierarchy, which implies a read operation, but it does not explain what the path parameter does, what the output contains, or whether any processing or side effects occur.

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 concise sentence and leads with the core action. However, the trailing clause 'when protocol composition matters' is ambiguous and adds limited value, slightly reducing structural quality.

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 fails to explain the path parameter or provide clear usage context. For a simple one-parameter tool this is still incomplete because parameter semantics are entirely absent and the usage condition is vague.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description never mentions the required 'path' parameter. The agent receives no guidance on what value to provide for path, which is a critical gap for a single-parameter tool.

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 action and resource: showing Wireshark's protocol hierarchy. This clearly distinguishes it from siblings like list_conversations or summarize_capture. The qualifier 'when protocol composition matters' is somewhat vague but does not obscure the core purpose.

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 'when protocol composition matters' implies a usage context, but it is vague and does not explicitly state when to prefer this tool over siblings or when not to use it. No alternatives are named, leaving the agent to infer applicability.

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 behavioral burden. It implies a read-only, high-level summarization operation and lists what the tool reports, but it doesn't disclose whether there are side effects, performance considerations on large captures, or how 'top talkers' is defined. There is no contradiction, but behavioral detail is minimal.

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 with no wasted words. It places the directive first and packs the key output categories into a compact list. Every element contributes to understanding the tool's role.

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 (one parameter, no nesting) and has an output schema, so the description doesn't need to explain return values. It covers the purpose and the starting-point context well. It could add a bit more guidance on what to do next (e.g., use a sibling tool for deeper analysis), but the description is adequate for the tool's simplicity.

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 one required parameter, 'path', with 0% description coverage in the schema, and the tool description does not explain what 'path' refers to. The context ('capture investigation') hints that it is a path to a capture file, but the ambiguity remains: file path vs directory, supported formats, local vs remote. The description adds no value beyond the parameter name itself.

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 role with a specific verb and resource: 'Start every capture investigation here' establishes it as an entry-point summarizer. It enumerates concrete outputs (file metadata, protocols, top IP talkers), which distinguishes it from the more specialized sibling tools like inspect_dns_queries or show_protocol_hierarchy.

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 tells the agent when to use this tool: 'Start every capture investigation here.' This is a clear usage directive. However, it doesn't explicitly mention alternatives or scenarios where this tool would not be appropriate, leaving some room for inference about when to switch to a specific sibling tool.

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