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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the catalog's contents, which is useful but not a major behavioral disclosure (e.g., no side effects, no rate limits). It does not contradict annotations.

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

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

Two sentences with no fluff. The first sentence states what the tool does, and the second provides a usage hint. Every word earns its place, and the structure is front-loaded.

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 (one parameter, no nested objects, output schema present), the description sufficiently covers purpose and usage. It doesn't explain return formatting, but the output schema handles that. Minor gap: no explicit mention of requiring an active analysis session, but that is implied.

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 only mentions 'analysis session' generally, which adds minimal meaning beyond the parameter name. It does not clarify where to obtain the session ID or its format, leaving the agent to infer.

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 ('Get') and resource ('capability catalog of an analysis session'), and lists concrete contents (taps, follow protocols, statistics, columns, encapsulation types). This clearly distinguishes it from sibling tools like analysis_summary or analysis_status.

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 a clear use case: 'Use this to discover what analysis operations are available.' This implies when to use it, though it does not explicitly name alternative tools or exclusions. The context is clear enough for an agent to select this tool when needing capability discovery.

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?

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds 'release resources,' giving a bit more context about the side effect. However, it does not disclose consequences like the session becoming invalid or what happens if the session ID is unknown.

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 that immediately states the action and its purpose. No unnecessary words or 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 parameter and an output schema, so the description need not explain return values. However, it omits crucial context such as the need to have an open session, how errors are handled, or the relationship to analysis_open. It is minimally adequate but lacks completeness for an agent encountering it cold.

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 parameter at all. While the parameter name 'analysis_session_id' is self-explanatory, the description fails to compensate for the lack of schema documentation or provide guidance on how to obtain the session ID.

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 ('Close') and resource ('analysis session'), clearly stating the tool's function. It also adds the effect 'release resources,' which distinguishes it from sibling tools like analysis_status or analysis_open.

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 should be used when an analysis session is no longer needed, but it provides no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or mention prerequisites like having an open session.

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 says 'Download' implying a read-only operation, but the annotations declare readOnlyHint=false, which suggests the tool may have side effects. This is a direct contradiction. Additionally, no further behavioral details are disclosed beyond the annotations already present.

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 sentences long and directly conveys the core purpose and token provenance without unnecessary words. It is well-structured and front-loaded.

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 relatively simple, and an output schema exists, so return values need not be explained. However, the description omits key behavioral details (like how output_mode works) and fails to clarify the analysis_session_id parameter. Combined with the annotation contradiction, the context is incomplete for a reliable agent.

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

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

With schema description coverage at 0%, the description must compensate. It explains the 'token' parameter by describing its sources, but does not clarify 'analysis_session_id' or 'output_mode'. Since only one of two required parameters is meaningfully described, it only partially compensates for the lack of schema 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 explicitly states the action ('Download') and the resource types ('exported object, RTP stream audio, or TLS key log from sharkd'). It clearly distinguishes this tool from siblings by referencing tokens from analysis_get_statistics, which no other tool does.

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 explains that tokens come from analysis_get_statistics or fixed tokens like 'ssl-secrets', which gives clear context on prerequisites. However, it does not explicitly mention when to avoid using the tool or list alternatives, though no direct alternative exists among siblings.

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 does not disclose side effects or state changes; readOnlyHint is false, so the tool may modify state, but the description is silent on this. It provides useful context about obtaining inputs from analysis_get_frame, but beyond that, behavioral traits are not elaborated beyond what annotations already state.

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 sentences long, front-loaded with the primary action and protocol examples. Every word is functional, with no redundant phrasing or unnecessary details.

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 gives the essential purpose and a key usage pointer, and the output schema handles return values. But with 5 parameters and low schema coverage, the lack of explanation for sub_stream and output_mode leaves some ambiguity, so it's not fully 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?

Since schema description coverage is 0%, the description is the only source of parameter meaning. It clarifies that 'protocol' and 'filter' should come from analysis_get_frame, which covers the two most important parameters. However, 'sub_stream' and 'output_mode' are left unexplained, and 'analysis_session_id' is not explicitly described.

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: reassemble and follow a protocol stream, with examples of supported protocols (TCP, UDP, TLS, HTTP). It also distinguishes itself by referring to analysis_get_frame as the source of protocol and filter values, which is not the tool itself.

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 to use analysis_get_frame's follow_filters to obtain the protocol and filter values, providing a clear usage flow. While it doesn't name alternatives, the reference to a sibling tool gives practical guidance on how to prepare inputs.

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 says 'Get' and 'Returns', implying a read-only operation, but the annotations declare readOnlyHint=false, and idempotentHint=true further suggests a side-effect-free read. This is a direct contradiction between the description and annotations, making the behavior unclear and potentially misleading.

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

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

Two sentences, front-loaded with the core purpose, and no redundant wording. Every sentence adds value, making it highly concise and well-structured.

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 with an output schema, the description is insufficient given 8 parameters and the need for an analysis session. It fails to explain the bytes mode options, reference/prev frame semantics, or the meaning of include flags, and lacks guidance on when to use this over sibling tools.

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 compensate. It only hints at include_bytes and frame_number, but bytes_mode, ref_frame, include_columns, and other parameters are left unexplained, leaving the agent guessing about valid values and effects.

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 verb 'Get' and the resource 'complete protocol dissection tree for a single frame', and adds return details (protocol layers, field values, optionally raw bytes). This distinguishes it from sibling tools like analysis_list_frames, which likely provide a broader list.

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 retrieving detailed frame data, but does not provide explicit when-to-use guidance or mention alternatives such as analysis_list_frames for a more general view. No exclusions or prerequisites are 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?

Annotations already cover read-only and idempotent behavior. The description adds that results vary by tap type (table/tree/graph) and that selector shorthands are accepted, which are concrete behavioral details beyond the annotations. It does not cover edge cases like invalid taps, but the addition is meaningful.

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 incredibly tight: three sentences cover what it does, what it returns, how to find taps, and a syntax note. Each sentence adds value, is front-loaded, and there is no 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?

Despite having an output schema, the description under-specifies the operational context. With 8 parameters and no schema parameter descriptions, users cannot determine how tap_token, selector, display_filter, or analysis_session_id interact. The description is too brief for the tool's complexity.

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 must explain the parameters. It only mentions 'selector shorthands' and hints at tap discovery, leaving seven of eight parameters (kind, name, limit, protocols, tap_token, display_filter, analysis_session_id) unexplained. This is insufficient for a tool with this many parameters.

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 ('Execute') and resource ('sharkd tap for statistical analysis'), and mentions output types (table/tree/graph). It also references analysis_catalog for discovering taps, grounding its role. However, it does not explicitly distinguish it from sibling analysis tools like analysis_summary or analysis_iograph.

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 a contextual clue by telling users to 'Use analysis_catalog to discover available taps' and notes the accepted selector shorthands. This implies a workflow but lacks explicit when-to-use vs alternatives or exclusions, so guidance is only partially 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the output content (frame counts and byte stats per interval) but does not disclose additional behavioral traits like interval edge effects or display filter semantics. This matches the bar for annotation-covered 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 exactly two sentences, front-loads the core action, and contains no filler or redundant information. Every word contributes to understanding.

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

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

For a read-only statistics tool with clear annotations and an output schema, the description plus schema provides enough context to use the tool. It does not mention session prerequisites or the meaning of display_filter, but these are minor omissions given the self-explanatory parameter names and existing structured data.

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 parameter meaning. It only hints at interval_ms via 'per time interval' and does not explain display_filter or analysis_session_id. Parameter names are somewhat self-explanatory, but the lack of any description for these fields is a clear gap.

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 ('Get') and identifies an exact resource ('frame count and byte statistics per time interval'), making it clear what the tool does. It also implicitly distinguishes this tool from siblings like analysis_get_statistics by specifying the per-interval breakdown.

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 states a clear use case ('useful for traffic pattern analysis'), giving context for when the tool would be appropriate. It does not explicitly mention alternatives or exclusions, but for a simple statistics tool this is sufficient 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds a useful behavioral constraint: the limit of 10 graph definitions, which is not present in the schema. It also notes optional filters, adding context beyond annotations. No contradiction exists.

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

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

The description is a single sentence that immediately states the action, then elaborates with constraints. Every word is purposeful, with no redundancy. It is concise and front-loaded, making it easy to scan.

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 that the tool has 5 parameters with zero schema descriptions and the description covers only graphs and filters, the input context is poorly specified. The output schema exists, so return values need no explanation, but an agent would struggle to construct valid graph definitions or know valid interval units. The description is incomplete for safe 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 mentions 'graph definitions' and 'optional filters', providing some meaning for the 'graphs' and possibly 'display_filter' parameters. However, it fails to explain interval, interval_units, and analysis_session_id, which are critical for invocation. The description adds minimal value beyond the schema's bare field 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 the tool's function with a specific verb ('Generate') and resource ('I/O graph time-series data'). It also mentions key constraints ('up to 10 graph definitions') and optional filters, making the purpose clear. However, it does not explicitly differentiate from sibling analysis tools, though the resource focus is distinct.

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 generating I/O graphs but gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives, so the agent must infer from context that this is the tool for graph generation.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about return content (frame numbers, column values, metadata flags) and optional filtering/pagination, but does not disclose any other behavioral traits. No contradiction with annotations.

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, well-structured sentence that front-loads the primary action and includes key elements (return values, optional filter, pagination). Every word adds value with no 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?

With an output schema present and annotations provided, the description does not need to explain return structure. However, given the tool has 6 parameters and a sibling list of related analysis tools, the description omits usage guidelines and detailed parameter semantics, making it only minimally 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, so the description must compensate. It does clarify the display filter (display_filter), pagination (skip/limit), and implies column selection via 'column values'. However, it does not explain refs or analysis_session_id, and the meaning of 'metadata flags' is left vague.

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 ('List') and resource ('frame summaries'), and specifies the output content (frame numbers, column values, metadata flags). It is distinguishable from siblings like analysis_get_frame, though it does not explicitly differentiate itself.

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 such as analysis_get_frame or analysis_catalog. The description only mentions optional display filter and pagination, without any context on prerequisites or suitable 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the grouping behavior and example methods/URIs, which are not in annotations. It does not disclose details about limits or filtering, but those are less critical given the read-only nature.

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

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

The description is a single sentence that directly states the tool's action and output. It is front-loaded and contains no unnecessary words.

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 means return values need not be described. The tool's purpose is stated clearly, and annotations cover safety. However, the lack of parameter guidance remains a gap, so the description is adequate but not 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% and the description fails to explain any of the four parameters. The names (limit, max_packets, display_filter) are somewhat self-explanatory but lack critical context such as what max_packets limits or how display_filter is applied. This is a significant gap for an agent to invoke the tool correctly.

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 the verb 'List' with the resource 'HTTP hosts', specifying grouping by request host and inclusion of example methods and URIs. This clearly differentiates it from sibling tools like analysis_list_tcp_conversations and analysis_list_tls_sni.

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

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

The description provides clear context: it is for listing HTTP hosts in an analysis session. However, it does not explicitly state when to avoid using it or mention alternatives. The context is sufficient to infer intended use, but there are no exclusions or comparisons.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the optional status filter but does not disclose additional behavior like pagination, ordering, or default status filter when not provided. This is adequate but not rich.

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, well-structured sentence that immediately states the action and the optional filter. There is no redundant or filler content; every word contributes meaning.

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, strong annotations, and presence of an output schema, the description adequately covers the core functionality. It does not need to explain return values since the output schema exists. Slight room for improvement would be mentioning default behavior with no filter, but overall it is complete for its context.

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

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

Schema coverage for the single 'status' parameter is 0%, with no enum values defined. The description compensates by explicitly naming the valid statuses ('ready, closed, failed'), which gives the agent meaningful guidance beyond the schema's bare string type and default empty value.

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

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

The description clearly states the action ('List all analysis sessions') and the resource ('analysis sessions'), with a specific scope ('all') and an optional filter by status. This distinguishes it from sibling tools like analysis_list_frames and analysis_get_frame, which target different resources or granularity.

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 this tool is for listing analysis sessions, optionally filtering by status, but does not explicitly state when to use it over alternatives or exclusions. The context signal of sibling tools helps, but the description itself lacks direct when/when-not 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the behavioral trait that the tool internally handles sharkd tap syntax, which is useful but not rich context about return behavior or edge cases. There is no contradiction with annotations.

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 core action and a key benefit without any fluff or repetition. It earns its place perfectly.

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?

An output schema exists and annotations are strong, so return values and safety are covered. However, the description omits mention of optional filtering (display_filter) and limit, leaving a gap for agents to understand the full capabilities. It is adequate but not 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 must compensate, but it provides no information about analysis_session_id, limit, or display_filter. The tool name implies session context, but the description does not clarify the meaning or usage of any parameter.

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 the specific verb 'List' with the resource 'TCP conversations', clearly distinguishing it from sibling tools like analysis_list_frames and analysis_list_http_hosts. It also adds a unique benefit (no manual sharkd tap syntax) that further clarifies its scope.

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 'without requiring manual sharkd tap syntax' gives clear context on when this tool is useful (avoiding manual tap commands), but it does not explicitly name alternatives or provide when-not-to-use guidance. This meets the 'clear context, no exclusions' level.

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?

Annotations already establish that the tool is read-only and non-destructive. The description adds only the grouping behavior but does not disclose any additional limitations, ordering, or filtering behavior.

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, focused sentence that is well-structured and front-loaded with the action. No filler words.

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 the annotations and output schema cover safety and return shape, the description lacks essential context about required analysis_session_id and parameter semantics, making it incomplete for a tool with four parameters and a specific grouping behavior.

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 any of the four parameters (analysis_session_id, limit, max_packets, display_filter). Since there are parameters to document, the description fails to compensate for the low schema 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 clearly specifies the operation (List), resource (TLS Server Name Indication values), and grouping criterion (by hostname), distinguishing it from sibling tools like analysis_list_http_hosts and analysis_list_tcp_conversations.

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. The description only states what it does, not when it should be chosen.

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 all annotations false, the description carries the full burden. It discloses that the tool opens a capture file and returns a session ID and summary, but does not mention session lifecycle (e.g., that the session persists until analysis_close is called), potential side effects, or prerequisites like a running capture session. This is adequate but not rich.

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, front-loaded with the core purpose, and includes the key return value. Each sentence earns its place with 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?

Despite having an output schema, the description is incomplete for a tool with 6 parameters and many siblings. It does not cover all parameter semantics, does not mention that this is a prerequisite for dependent analysis tools, and lacks guidance on how to obtain the file_path or capture_session_id. The tool's role in the workflow is only implied.

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 must compensate. It explains the mutual exclusivity of file_path and capture_session_id, but leaves file_name, max_bytes, max_packets, and file_selector undefined. These parameter meanings are not obvious from the schema alone (especially file_selector), so the description is insufficient.

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 ('Open a capture file for analysis') with a specific resource (capture file) and technology (sharkd). It also distinguishes itself from sibling analysis tools by being the entry point that returns a session ID, which is unique 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 description gives some guidance on parameter choice ('Either provide file_path directly or capture_session_id') but does not explain when to use this tool versus alternatives like file_tshark_export or analysis_catalog. It implies usage as the first step for analysis but lacks explicit exclusions or alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, providing strong safety signals. The description adds that the status includes frame count and duration, which is useful context but doesn't disclose error handling or lifecycle states. There is no contradiction with annotations.

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 one sentence, front-loaded with the action, and contains no filler. It's 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?

Given the low complexity, strong annotations, and presence of an output schema, the one-sentence description is sufficient to define the tool's purpose and key output. No critical information is missing for a read-only status lookup.

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 for the single parameter is 0%; the description does not explain analysis_session_id beyond the tool description's reference to 'an analysis session'. The parameter name is self-explanatory, but the description adds no additional meaning about accepted formats, required context, or how to obtain the ID.

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 ('Get'), names the resource ('status of an analysis session'), and adds concrete return elements ('frame count and duration'). This clearly distinguishes it from sibling tools like analysis_summary or capture_status.

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 for retrieving session status, but it doesn't explicitly state when to use this instead of related tools (e.g., capture_status, analysis_summary). No exclusions or alternative recommendations are given, so it's clear but not fully guided.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by specifying the kinds of information the summary includes, which goes beyond the annotations but does not describe failure scenarios or exact output structure (covered by 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 immediately states the purpose and then lists specific details. Every word earns its place with no fluff 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?

For a simple read-only tool with one parameter, strong annotations, and an output schema, the description covers the essential purpose and content. It lacks explicit mention of prerequisites (e.g., a valid analysis session) or error conditions, but these are partially implied and the output schema fills in return details.

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 parameter, analysis_session_id, with no description (0% schema coverage). The tool description does not explicitly explain what this parameter represents or how to use it, only vaguely referring to 'the loaded capture file'. This leaves the parameter semantics primarily inferred from the parameter name, with no added value from the description.

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 ('Get') and resource ('summary of the loaded capture file'), and lists concrete content (frame count, duration, protocols, time range). This clearly distinguishes it from sibling analysis tools like analysis_get_statistics or analysis_catalog, which focus on detailed statistics or file listings.

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 when a high-level overview of the capture is needed, but it does not explicitly state when to prefer this over alternatives such as analysis_get_statistics or analysis_iograph. No exclusions or alternative comparisons are provided, so the usage context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output content (supported link types and timestamp types) but no additional behavioral traits like error handling or interface existence requirements. This is adequate given the annotation coverage, but not richer.

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, focused sentence that front-loads the verb 'Get' and wastes no words. Every element contributes to understanding the tool's function.

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 parameter, and output schema exists, so return values need no explanation. However, the description lacks usage timing and parameter format details, making it serviceable but not fully complete. Annotations cover safety, but the missing guidance on how to specify the interface leaves a 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?

The input schema has 0% description coverage for the only parameter, 'interface', and the description only refers to it as 'a specific network interface' without specifying the expected format (e.g., name, ID, index) or providing examples. This does not compensate for the lack of schema 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed capabilities of a specific network interface'). It also specifies the kind of capabilities (supported link types and timestamp types), which distinguishes it from sibling tools like capture_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?

The description implies the tool is used after identifying a specific interface, but it provides no explicit guidance on when to use it vs. alternatives, no prerequisites, and no mention of the need to call capture_list_interfaces first. Usage context is only implied, 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?

Annotations already establish read-only, idempotent, and non-destructive behavior. Description adds a meaningful behavioral detail: in ring buffer mode, multiple files may exist, which helps set expectations about the result set. No contradiction with annotations.

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?

One concise sentence that front-loads the primary purpose and adds a relevant qualifying note. No redundant or obscure 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?

Given the low complexity (one parameter), the presence of annotations, and an output schema (not shown but indicated), the description adequately covers the core behavior and an important edge case. It does not describe return values, but the output schema covers that. Slight room to mention common usage context (e.g., after capture_start), but not necessary.

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?

Single parameter capture_session_id is self-explanatory in name and type. Schema coverage is 0%, but the description does not elaborate on the parameter; however, the parameter is simple enough that little extra is needed. The description adds no additional semantic nuance.

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?

Clear verb 'list' with specific resource 'files produced by a capture session'. Differentiates from sibling tools like capture_list_sessions (lists sessions) and capture_list_interfaces (lists interfaces). The scope is well-defined.

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?

Implies use case (listing files for a capture session) and adds context about ring buffer mode, but does not explicitly state when to use this tool versus alternatives or when not to use it. No comparison with capture_list_sessions or file listing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well covered. The description adds value by specifying what is returned (interface names, display names, addresses), but does not disclose any potential edge cases such as empty results or permission requirements. Acceptable given the annotations.

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 and the expected output. Every word contributes to understanding, with no filler.

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

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

For a zero-parameter, read-only list tool with an output schema and detailed annotations, the description is complete enough. It mentions the key return fields (names, display names, addresses). A small gap is not mentioning that the output may be empty or require specific permissions, but this is minor given the simple nature of 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 tool has 0 parameters and the schema covers all properties (empty object). With no parameters to explain, the baseline is 4. The description correctly avoids inventing parameter 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 the verb 'List', the resource 'available network interfaces for packet capture', and the specific return values (interface names, display names, addresses). It is specific and distinct from sibling tools like capture_list_files, which lists files, not 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?

The description clearly implies use before starting a packet capture to see available interfaces. It does not explicitly name alternatives or exclusions, but the context 'for packet capture' provides clear usage context. The sibling tool capture_get_interface_capabilities is distinct in purpose, so no confusion.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds the behavior of optional status filtering, which is a useful but minimal addition. No contradiction with annotations.

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 clearly states the action, resource, and optional modifier.

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 good annotations and an output schema, so the description doesn't need to explain return values. However, it lacks details on status values and does not explicitly differentiate from a similar sibling tool (analysis_list_sessions), making it only minimally complete for a broad toolset.

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 description states that 'status' is an optional filter, giving basic meaning beyond the bare schema (which only shows a string type and default). However, it does not specify possible status values or how filtering behaves, leaving the parameter semantics partially unspecified given 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 uses the specific verb 'List' with a clear resource ('capture sessions') and mentions optional filtering by status. It does not explicitly distinguish from the sibling tool 'analysis_list_sessions', but the resource is named clearly enough to infer the difference.

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. It does not mention exclusion criteria or alternative tools, leaving the agent to infer usage from the tool name and sibling context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds context that the log is dumpcap's stderr output, but does not disclose behaviors such as tail handling or session requirements.

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 a parenthetical clarification; no redundant or unnecessary words.

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 annotations and output schema cover safety and return values, the description lacks guidance on the tail parameter and when to use this tool, making it minimally adequate but incomplete for a full understanding.

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 description does not mention either parameter (capture_session_id or tail). With 0% schema description coverage, it fails to compensate by explaining that tail controls the number of lines retrieved, leaving the agent to infer parameter meanings.

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 tool's function with a specific verb ('Read') and resource ('capture session log'), and clarifies it as 'dumpcap stderr output,' distinguishing it from sibling tools like capture_status and capture_list_sessions.

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; it lacks any mention of prerequisites, exclusions, or comparison to capture_status or capture_list_sessions.

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?

Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds value by specifying the privilege requirement and the return of a session ID, providing behavioral context beyond what annotations convey.

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 sentences with no redundant information. It front-loads the primary action and includes the two most critical details (privilege and return value), making it highly concise.

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 existing, the description lacks guidance on the many optional parameters and does not set expectations for resource usage or lifecycle (e.g., needing to stop the capture later). For a tool with 11 parameters, this is under-specified.

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 11 parameters. It only mentions the 'interface' parameter implicitly, leaving autostop, ring_buffer, output_format, capture_filter, and others unexplained. This is a significant gap for a complex parameter set.

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 ('Start live packet capture') and the resource ('network interface'). It also notes the returned session ID, which distinguishes it from sibling tools like capture_stop or capture_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?

The description provides a prerequisite (root or cap_net_raw capability) which is useful but does not explicitly say when to use this tool vs alternatives like capture_list_interfaces or capture_stop. The usage context is implied rather than directly 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context by specifying the output content ('packet counts and file information') and the notion of 'current' status, which is useful beyond the annotations. However, it does not address error cases or session lifecycle (e.g., stopped sessions).

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 directly states the purpose and key output details. There is no unnecessary information or 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?

For a simple getter with an output schema and safe annotations, the description is largely sufficient. It tells exactly what the tool returns and implies the session identifier. Minor gaps like behavior for nonexistent sessions or whether it works on completed sessions are not critical but could be added.

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 capture_session_id parameter or how to obtain it. While the parameter name is self-explanatory, the description adds no semantics beyond the schema, failing to compensate for the lack of schema 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 clearly states a specific verb ('Get') and resource ('capture session'), and adds outcome details ('packet counts and file information'). This distinguishes it from sibling tools like capture_list_sessions (listing sessions) and capture_stop (stopping).

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The name and description imply use for a single session's current status, but no alternatives or exclusions are mentioned. Context from sibling tool names helps but the description does not direct the agent.

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 annotations already provide destructiveHint=true and idempotentHint=true. The description adds a human-friendly restatement of idempotency ('safe to call multiple times'), but does not add new behavioral context beyond what annotations already provide, such as effects on captured files or finalization details. It does not contradict annotations.

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: two short sentences with no filler. The purpose is front-loaded, and the additional idempotency note earns its place. Every word adds value, meeting the standard for excellent conciseness.

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 stop operation with a single parameter and an output schema present, the description covers the core purpose and idempotency. It slightly misses the opportunity to mention where to get capture_session_id, but overall the tool is low-complexity and the description is sufficiently complete for typical usage.

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% for the single required parameter, capture_session_id. The description does not explain what the session ID is, how to obtain it, or its format. The parameter name is somewhat self-explanatory, but the description does not compensate for the lack of schema-level documentation, leaving the agent to guess about session identification.

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 ('Stop') and a clear resource ('a running packet capture'), immediately distinguishing it from sibling tools like capture_start, capture_status, and capture_list_sessions. There is no ambiguity about what tool it is or what action it performs.

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 clearly states the context for use: stopping a running capture. It also notes that it is idempotent and safe to call multiple times, which tells the agent it can be used without concern for whether the capture is already stopped. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for a simple stop operation.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavior by noting the dependency on an active analysis session, but does not disclose what happens with an invalid field_id or session, nor any details about the returned data beyond being 'detailed'.

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 sentences, front-loaded with the main action, and contains no filler. Every sentence adds value: the first states the purpose and examples, the second gives the workflow and prerequisite.

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 read-only retrieval tool with annotations and an output schema present, the description covers the essential usage flow (get id from field_list, require active session). It does not mention error behavior or output format, but the output schema likely handles that, making the description sufficiently complete for the tool's complexity and sibling 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?

With 0% schema description coverage, the description must compensate. It clarifies field_id by explaining it refers to a protocol field abbreviation and references field_list results, but does not explicitly describe analysis_session_id beyond the prerequisite of an active session. The examples help, but the session parameter semantics remain inferred from name and 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 uses the specific verb 'Get' with the resource 'detailed information about a specific protocol field', giving clear scope. It provides concrete examples ('ip.src', 'tcp.port') and distinguishes itself from sibling field_list by focusing on a single field's details rather than listing 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 gives a clear usage prerequisite: 'Use the 'id' value from field_list results', establishing the expected workflow between field_list and field_get. It also states the requirement for an active analysis session, providing context for when the tool is valid to use, though it does not explicitly mention alternatives or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating the implementation ('Uses tshark -G fields') and the absence of a session requirement, which is useful behavioral context. It also mentions pagination behavior. No contradiction with annotations.

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 sentences, front-loaded with the verb 'List', and every clause adds information: what is listed, optional filtering, pagination, and the underlying command/session requirement. No unnecessary words.

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 and has an output schema, so the description need not explain return values. The description covers the key usage points: listing fields, prefix filter, pagination, and no-session requirement. Minor details like ordering or match semantics are absent but not critical for a list operation.

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 descriptions are absent (0% coverage). The description explains that 'prefix' filters the list and that pagination is supported, implying 'limit' and 'cursor' are pagination controls. However, it does not clarify the exact meaning of 'cursor', whether 'limit' defaults or caps results, or how prefix matching works. It partially compensates for lack of schema descriptions but leaves gaps.

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 protocol fields') with an optional filter ('by prefix'). It distinguishes from siblings like field_get (which presumably retrieves a single field) and filter_complete (completion of filters). The resource is explicit: 'protocol 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 provides clear context for when to use the tool: to list fields with optional prefix filtering, with pagination support, and explicitly notes 'no session required', implying it can be used independently of an analysis session. However, it does not explicitly mention when not to use it or name alternative tools for similar tasks.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description aligns without contradiction. The description adds little behavioral context beyond noting optional hashes, which is parameter-driven, so the value is 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 that covers the core capability without filler or redundancy. 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?

With an output schema present and strong annotations, the tool is adequately contextualized for a simple read-only operation. However, it omits any mention of preconditions (e.g., files must exist) and the machine_readable parameter's purpose, leaving some 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?

Schema description coverage is 0%, so the description must compensate. It only loosely covers include_hashes via 'optionally file hashes', but leaves the files parameter's format and the machine_readable flag semantically unexplained, creating a clear gap for a 3-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 uses a specific verb ('Get') and resource ('capture file metadata'), and enumerates concrete data (packet count, duration, file type, optionally hashes). This clearly distinguishes it from siblings like file_detect_type, which focuses solely on file type detection.

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

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

No explicit when-to-use or alternative guidance is provided. The purpose implies usage for metadata retrieval, but there is no mention of when to choose this over file_detect_type or capture_list_files, nor any exclusion criteria.

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?

Annotations already indicate idempotentHint=true and destructiveHint=false, but the description adds no additional behavioral context. It does not disclose whether the input file is modified in-place or if a new output file is created, nor does it explain any side effects beyond 'remove duplicate packets.'

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, direct sentence with no extraneous words. It is well-structured and front-loaded, delivering the core purpose immediately 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 six parameters and no schema descriptions, this description is grossly incomplete. It fails to mention the required input_file and output_file, the optional deduplication settings, or the expected output format, making it insufficient for an agent to 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?

With 0% schema description coverage, the description has the burden of explaining the six parameters, but it mentions none of them. The terms window, ignore_bytes, time_window_sec, and skip_radiotap_header remain entirely undefined, leaving the agent to guess their roles.

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 with a specific verb and resource: 'Remove duplicate packets from a capture file.' This distinguishes it from sibling tools like file_merge, file_slice, and file_write_filtered_capture, which perform different operations on capture files.

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 explicit guidance on when to use this tool versus alternatives. It simply states the action without any context about prerequisites, exclusions, or scenarios where this tool is preferred over other file-processing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no behavioral context beyond the format examples, such as error handling or return behavior. It does not contradict annotations.

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 the verb front-loaded. It is immediately clear what the tool does with no verbose or redundant content.

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 one-parameter, read-only tool with an output schema and strong annotations, the description is largely complete. It covers the tool's purpose and format examples, and the output schema handles return values. The only gap is usage guidance, but that is not critical for a simple 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 has 0% description coverage for the single parameter 'file_path'. The description does not explain the expected path format, whether local paths are required, or any constraints. The parameter meaning is only implied by the tool's purpose, adding little value beyond the parameter name.

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 'Identify' and names the resource 'format of a capture file' with concrete examples (pcap, pcapng). This clearly states what the tool does, though it doesn't explicitly differentiate from siblings like file_capinfos or file_merge.

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. Sibling tools like file_capinfos and file_slice exist, but the description does not explain what distinguishes this tool or in which scenarios it should be chosen.

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 annotations already cover idempotency and non-destructiveness. The description adds value beyond annotations by explaining the behavioral difference between 'merge' (interleaves by timestamp) and 'concat' (appends sequentially), which is core to how the tool operates. It does not repeat annotation info, but does not address output overwrite behavior, which would require a lower score.

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 sentences, front-loaded with the main purpose, and every word earns its place. It conveys the core function and mode variants without any 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 the tool's purpose and mode semantics but omits guidance on parameters like snaplen and output_format, which have no schema descriptions. Given the tool's complexity (5 params, no param docs) and the presence of sibling tools, the description is only partially 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?

With 0% schema description coverage, the description is expected to compensate. It explains the 'mode' parameter's values but leaves inputs, output_file, snaplen, and output_format entirely to name inference. This is minimal compensation for a 5-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 explicitly states 'Merge two or more capture files into one' with a specific verb and resource, clearly distinguishing it from sibling tools like file_slice or file_dedup. It also clarifies the two modes ('merge' vs 'concat'), further defining the tool's function.

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 on how to use the tool (combining capture files) and explains the two modes, giving guidance on when to use each. However, it does not explicitly mention alternatives or exclusions for when not to use this tool, 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?

The description adds no behavioral details beyond the annotations. It doesn't explain output behavior, whether the operation is a constant offset, or limitations of the adjustment. The annotations already cover idempotency and non-destructiveness, so the description provides no additional 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 a single concise sentence with no fluff. However, it is so brief that it omits essential parameter and usage details, so it is not optimally sized for this complex 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?

A five-parameter tool with zero schema descriptions needs a much more detailed description to be usable. The one-sentence description leaves critical questions about adjustment specifics and parameter behavior unanswered, making it nearly impossible 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?

Schema description coverage is 0%, and the description does not mention any parameter names or their meanings. The agent would have to guess at the semantics of adjust_sec, strict_adjust_sec, and replacements.

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 and resource ('Adjust packet timestamps'), clearly indicating a timestamp modification operation. This distinguishes it from sibling tools like file_merge or file_slice, which perform different operations.

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, such as file_slice or file_tshark_export. An agent must infer usage entirely from the tool 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?

Annotations already provide idempotentHint=true and destructiveHint=false, reducing the need for safety disclosure. The description adds the selection mechanism (ranges or time window) but doesn't explain output behavior (e.g., overwrite semantics, interaction between ranges and time, effects of keep_selected or snaplen). This is adequate but not rich.

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, focused sentence with a clear action verb and no filler. It is front-loaded and every word contributes to the core function.

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 7 parameters and a complex selection semantics (ranges, time windows, keep_selected, snaplen), but the description covers only the basic idea. It lacks details on input/output file behavior, range formats, time parsing, and return values. Given the 0% schema coverage and no per-parameter docs, this is insufficient for a full understanding.

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 compensate for undocumented parameters. It names 'packet number ranges' and 'time window', which map to packet_ranges and start_time/end_time, but leaves snaplen and keep_selected unexplained, and doesn't clarify the format for ranges (e.g., '1-5,8' strings). The description adds only partial 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 uses a specific verb ('Extract') and names the resource ('packets from a capture file') plus the selection criteria ('by packet number ranges or time window'). This clearly distinguishes it from sibling tools like file_merge, file_dedup, and file_retime, which address different operations on capture files.

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. The description does not mention exclusions, prerequisites, or mention any sibling tools as alternatives, leaving the agent to infer usage solely from the purpose. This is a plain statement of function with no decision context.

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?

Annotations include idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context about output formats (fields, json, ek) and clarifies that it exports structured data, which implies read-only transformation of input without destroying the source. It doesn't contradict annotations. However, it doesn't mention behavior like default output mode or packet limits, but given annotations already cover safety/idempotency, the description adds reasonable value.

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 sentences long, front-loaded with the main purpose and provides a clear pointer to the alternative. Every sentence earns its place with no filler or repetition of schema details.

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 8 parameters, no enums, and no schema description coverage. The description is minimal but the output schema exists (context signal says 'Has output schema: true'), so return values are presumably documented there. The description explains the core purpose and differentiates from a sibling, but lacks deeper guidance on when to use structured export vs other tools beyond the one alternative. Given the tool's moderate complexity, this is a minor gap, so not a perfect 5 but above the 3 minimum.

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 carries the burden of parameter semantics. The description names 'fields' and 'format' as examples but does not explain parameters like decode_as, read_filter, display_filter, output_mode, max_packets. However, the format field is partially clarified by listing 'fields, json, or ek' as format options. Since the schema has 8 parameters and the description only hints at 2, the baseline 3 is appropriate but it doesn't fully compensate for the 0% 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 clearly states the verb 'Export' and the resource 'packet data in structured format', and lists the specific structured formats (fields, json, ek). It distinguishes itself from the sibling tool file_write_filtered_capture by explicitly directing users to that alternative for pcap writing, which differentiates it well.

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 explicit guidance on when to use this tool vs an alternative: it says 'For writing filtered pcap files, use file_write_filtered_capture instead.' This directly tells the agent when not to use this tool and names the specific sibling tool to use instead, fulfilling the highest bar for usage guidelines.

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?

Annotations already declare the tool as idempotent and non-destructive. The description adds that it writes to a 'new capture file', clarifying it does not modify the input. This is useful context, though it omits details like output overwrite behavior or permissions, which are less critical given the annotations.

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 sentences with no filler. It front-loads the main action and then provides a useful comparison, every sentence earning 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?

With six parameters and no schema descriptions, the description is insufficient for confident invocation. The optional parameters (decode_as, max_packets, output_format) lack any explanation of their purpose or defaults, and the presence of an output schema does not mitigate this gap. The core function is clear, but important usage details are missing.

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

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

Schema description coverage is 0%, so the description must compensate. It indirectly explains the three required parameters (input_file, output_file, display_filter) but leaves the optional parameters (decode_as, max_packets, output_format) completely unaddressed, offering little help beyond bare parameter 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 uses specific verbs 'Filter' and 'write' and clearly names the resources: packets, display filter, and a new capture file. It also explicitly distinguishes this from sibling file_slice by stating it filters by protocol content rather than packet ranges.

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 names an alternative (file_slice) and provides the deciding factor: packet ranges vs. protocol content. This tells the user exactly when to choose this tool over that alternative.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the tool's safety profile. The description adds the prerequisite of an active analysis session, which is useful context beyond the annotations. However, it does not disclose details like error behavior or output format, and the bar for additional transparency is lower given the existing annotations.

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 immediately states the action. Every word earns its place, with no filler or redundant information. It is appropriately sized for a simple auto-complete 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 tool is simple, has an output schema (so return values are covered), and annotations already declare safety traits. The description adds the key prerequisite of an active analysis session. It lacks guidance on alternatives, but for a straightforward auto-complete tool with strong structured metadata, the description is nearly 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?

With 0% schema description coverage and only 2 parameters, the description must compensate but only partially does. 'Requires an active analysis session' hints at analysis_session_id, and the tool's purpose implies field_prefix, but the description does not explicitly explain how each parameter is used (e.g., that field_prefix is the text to match against field names). It relies heavily on parameter names being self-explanatory.

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: 'Auto-complete display filter field names.' This distinguishes it from sibling tools like filter_validate_display and field_list, which handle validation and listing respectively. The verb 'auto-complete' plus the resource 'display filter field names' is precise.

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 prerequisite: 'Requires an active analysis session (sharkd command).' This tells the agent when the tool can be used, but it does not explicitly mention alternatives or exclusions, such as when to prefer filter_validate_display or field_list. Usage is implied rather than explicitly contrasted with siblings.

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?

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context about the interface being required due to link type dependency, which is not in the annotations. It does not contradict any annotations.

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

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

Two sentences, both purposeful. The first sentence states the action and object; the second explains a key dependency. There is no redundancy or filler.

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

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

For a simple validation tool with an output schema and clear annotations, the description covers the essential context (interface-link type dependency). It does not describe behavior for invalid filters or interface errors, but these are likely surfaced via errors or output schema, so the description 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?

The schema has zero description coverage, so the description must clarify both parameters. It identifies capture_filter as a BPF expression and interface as a specific interface tied to link type, providing basic semantic meaning. However, it lacks format details or constraints for the filter expression, leaving some gaps.

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 validates a BPF capture filter expression, using a specific verb and resource. The term 'capture' distinguishes it from display filter validation tools like filter_validate_display, and the interface requirement adds specificity.

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 this tool (for BPF capture filters) by naming 'capture filter' and explains the critical interface dependency. However, it does not explicitly mention alternatives or when not to use it, though the sibling context makes this reasonably 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context beyond the annotations: it explicitly says the tool 'returns whether the filter syntax is valid' and that no active session is needed, which clarifies expected behavior without contradicting the annotations.

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 sentences, front-loaded with the action verb, and every word adds value. It states the core function first and then the key contextual detail, with no redundancy or 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?

For a low-complexity validation tool with one parameter, existing annotations, and an output schema, the description is sufficient. It covers the essential purpose, return behavior, and a key prerequisite (no active session), while the output schema handles the return format details. Nothing critical is missing.

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

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

The schema has 0% description coverage, so the description needed to compensate. It clarifies that the tool validates a 'display filter expression,' which implicitly refers to the single 'display_filter' parameter, but it doesn't explain the expected format or provide examples. Since the parameter is a simple, well-named string, the meaning is reasonably clear, but the description adds minimal detail 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 uses a specific verb ('Validate') and a clear resource ('Wireshark display filter expression'), which immediately conveys the tool's function. It also distinguishes itself from sibling tools like filter_validate_capture (which validates capture filters) and filter_complete (which auto-completes filters), making the 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?

The description gives clear context for when to use the tool: to validate a display filter expression. It adds a notable usage condition ('Does not require an active analysis session') that helps decide when this tool is appropriate. However, it does not explicitly mention alternatives or state when not to use it, which would warrant 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the specific categories of information returned, particularly 'allowed file roots,' which is a behavioral constraint not implied by the annotations. This adds useful context without contradicting structured data.

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 immediately states the action and then enumerates the key content areas. Every word carries meaning, with no redundant or filler text. 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?

For a zero-parameter read-only status tool with good annotations and an existing output schema, the description is fully complete. It tells the agent exactly what information will be provided. The output schema can handle return value details, so the description does not need to elaborate further.

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 zero parameters, so the description does not need to explain parameter semantics. The schema coverage is trivially 100%, and the baseline for 0 params is 4. No additional parameter information is necessary.

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: 'Get Wireshark runtime information' with a specific list of content (binaries, versions, features, allowed file roots). This is a specific verb+resource+scope, and it distinguishes from siblings by focusing on runtime environment details rather than capture, analysis, or file operations.

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 usage context is clear: use this to retrieve runtime information about Wireshark. No alternatives are mentioned, but the tool is unique among siblings for this purpose. It lacks explicit when/when-not guidance, but the zero-parameter, self-descriptive nature makes usage obvious.

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