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

With no annotations provided, the description carries the full burden. It successfully discloses the return structure ('matched_fields and match_reasons') and the compact nature of summaries. However, it fails to mention operational characteristics like the scan_limit behavior, read-only safety, or filtering capabilities implied by the extensive parameter set.

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 consists of three well-structured sentences with zero waste: purpose declaration, return value specification, and workflow guidance. Information is front-loaded appropriately given the complexity of the tool.

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

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

Given the high complexity (23 filter parameters, output schema, no annotations), the description is inadequate. While it mentions the output structure, it omits any explanation of the filtering capabilities (host/path/header/body filters), which constitute the primary interaction model for this tool. The 0% schema coverage makes this omission critical.

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 23 parameters with 0% description coverage (titles only). The description completely fails to compensate for this gap, not mentioning any parameters, the filtering paradigm, or even the 'preset' enum which defines the analysis mode. Users have no guidance on how to construct valid queries from the description alone.

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

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

The description clearly identifies the action ('Analyze'), resource ('saved recording snapshot'), and output format ('compact summaries'/'TrafficSummary items'). It distinguishes this tool from the sibling 'get_traffic_entry_detail' by positioning this as the summary/overview tool versus the drill-down tool.

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

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

The description provides explicit workflow guidance: 'Use get_traffic_entry_detail to drill down into a specific entry_id afterwards.' This clearly indicates the sequence of operations. However, it does not distinguish when to use this versus the similarly-named 'query_recorded_traffic' sibling.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what it checks but omits whether this is a read-only operation (though implied), whether it affects performance, rate limits, or what specific status indicators are returned. For a tool with no annotations, this lacks necessary behavioral 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, efficient sentence of seven words with zero waste. It is front-loaded with the action verb and immediately specifies the scope, making it appropriately sized for a zero-parameter status 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?

Given the tool has zero parameters and an output schema exists (covering return values), the description adequately covers the conceptual purpose. It establishes the domain (connectivity and capture state) sufficiently for an agent to select it correctly, though it could be improved by mentioning it's a safe diagnostic 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?

With zero parameters, the baseline score is 4 per the evaluation rules. The description appropriately requires no additional parameter context since the input schema is empty.

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 ('Check') and resources ('Charles connectivity', 'active live-capture state') that clearly distinguish it from action-oriented siblings like start_live_capture or analysis tools like analyze_recorded_traffic. However, 'Check' is slightly less precise than 'Retrieve' or 'Get', and 'Charles' assumes context from the server rather than being self-evident.

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, nor does it mention prerequisites (e.g., checking connectivity before starting a capture). While the purpose implies diagnostic usage, there are no explicit when/when-not statements or comparisons to siblings like peek_live_capture.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to clarify whether 'filter' implies a destructive operation or simple querying, what the return format contains, or performance characteristics (e.g., regex execution limits). It does not disclose whether filtered results are removed from source or merely returned.

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 11-word sentence that is efficiently structured with the verb front-loaded. However, it is arguably underspecified for a 6-parameter tool with complex filtering capabilities, leaving insufficient semantic weight to guide proper invocation without heavy reliance on the schema.

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

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

Given the tool's complexity (6 parameters including regex filtering, boolean retention flags, and historical/live data modes) and the presence of an output schema, the description remains incomplete. It fails to explain the filtering logic, prerequisites (e.g., existing capture requirements), or behavioral implications of the keep_request/keep_response parameters.

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

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

Schema description coverage is 67% (4/6 parameters). While capture_seconds, host_contains, http_method, and keyword_regex are well-documented in the schema, 'keep_request' and 'keep_response' lack descriptions. The tool description provides no compensation for these gaps, nor does it explain the interaction between filtering criteria (AND/OR logic) or the impact of the boolean flags.

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 filters traffic from either a 'fixed capture window' or 'latest saved history package', providing specific verb (filter) and resource (traffic). However, it does not explicitly differentiate this from sibling tools like 'query_recorded_traffic' or 'analyze_recorded_traffic' which may perform similar 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 description implies usage context by specifying data sources (capture window vs history package), suggesting when to use it based on data availability. However, it lacks explicit 'when not to use' guidance or named alternatives, leaving ambiguity regarding when to choose this over 'query_recorded_traffic' or other analysis tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'coarse' hints at granularity limitations, the description omits critical behavioral details: what the 'scan_limit' parameter controls, the computational cost of analysis, whether presets filter input or output, and any side effects on the capture 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?

Single sentence of 10 words that efficiently conveys the core function. Front-loaded with the action verb 'Return'. However, given the tool complexity (5 parameters with 0% schema coverage), this brevity constitutes under-documentation rather than effective 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?

Despite having an output schema (reducing the need to describe return values), the description is inadequate for a tool with 5 parameters and complex input logic. Missing: clarification of parameter relationships (capture_id vs recording_path), enumeration semantics for 'preset', and behavioral constraints. Requires significant inference from parameter names alone.

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%, requiring the description to compensate for 5 undocumented parameters. While 'live capture or saved recording' hints at the domain for 'capture_id' and 'recording_path', it fails to explain the required 'source' parameter, the enum values for 'preset' (api_focus, errors_only, etc.), or the purpose of 'scan_limit'. Insufficient compensation for zero 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 states a specific action ('Return') and resource ('traffic class counts') with clear scope ('live capture or saved recording'). The qualifier 'coarse' provides useful granularity context. However, it doesn't explicitly distinguish when to use this versus sibling tools like 'analyze_recorded_traffic' or 'group_capture_analysis'.

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

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

No guidance provided on when to use this tool versus alternatives like 'query_recorded_traffic' or 'get_recording_snapshot'. Critically missing: explanation of the relationship between 'capture_id' and 'recording_path' parameters (mutually exclusive? complementary?) and when each should be used.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully clarifies the data source (saved snapshots vs. live), but fails to explicitly state safety properties (read-only status), side effects, or whether loading affects current session 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 consists of two efficient sentences with zero waste. The primary purpose is front-loaded in the first sentence, while the second sentence provides essential behavioral context.

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 tool has an output schema (covering return values) and a simple single-parameter structure, the complete lack of parameter documentation in both schema and description, combined with absent annotations, leaves critical usage information gaps.

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

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

The input schema has 0% description coverage, and the description fails to compensate by providing any semantics for the 'path' parameter. It does not explain what the path represents, acceptable formats, or the behavior when null (the default).

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 provides a specific verb ('Load') and resource ('saved recording snapshot'), clearly defining the tool's function. It explicitly distinguishes the tool from live-capture siblings by stating it 'never reads the live Charles session.'

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 contextual guidance via the negative constraint 'never reads the live Charles session,' implicitly defining when not to use this tool (vs. live capture tools). However, it does not explicitly name alternative tools like 'read_live_capture' for that use case.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It provides useful workflow context (dependency on prior calls) and a performance warning about include_full_body implying large payloads. However, it lacks disclosure on safety profile (read-only vs. destructive), rate limits, or what occurs if both capture_id and recording_path are provided.

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

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

The description is efficiently structured with five sentences: purpose first, prerequisites second, conditional parameter logic next, and performance warning last. Every sentence earns its place with zero redundancy or filler text. Information is appropriately 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 has 6 parameters with conditional logic and an output schema (which excuses return value explanation), the description is incomplete. The gaps in 'source' and 'max_body_chars' documentation with 0% schema coverage, combined with no safety annotations, leave the agent without sufficient context to fully understand required inputs and side effects.

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 successfully adds semantic context for entry_id, recording_path, capture_id, and include_full_body (explaining relationships and when to use them). However, it completely omits explanation for the required 'source' parameter and 'max_body_chars', leaving 2 of 6 parameters undocumented.

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

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

The description clearly states the tool 'Load[s] one traffic entry detail view for drill-down inspection,' specifying the singular resource and action. However, it does not explicitly differentiate from similar siblings like read_live_capture or get_recording_snapshot, requiring the agent to infer the distinction from 'detail view' versus other 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?

Excellent explicit guidance: it states the prerequisite ('Requires entry_id from a prior summary/query call'), provides conditional logic for mutually exclusive parameters ('For history entries... For live entries...'), and gives a clear when-not recommendation ('Keep include_full_body=false unless...'). This directly addresses the workflow sequence and parameter selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and successfully communicates the token efficiency trait ('lower token cost'). However, it fails to disclose safety characteristics (e.g., whether read-only), performance limits, or what constitutes a 'hot spot' in this 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 consists of a single 12-word sentence that is efficiently worded without redundancy. However, for a tool with 25 parameters and complex filtering capabilities, this length is inappropriately brief and fails to front-load critical parameter guidance.

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 high complexity (25 parameters, 0% schema coverage) and presence of an output schema, the description remains inadequate as it omits all parameter semantics and operational constraints. The mention of 'hot spots' and token cost provides minimal context for the extensive filtering capabilities available.

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 contains 25 parameters with 0% description coverage, yet the description mentions none of them, not even the required `source` or `group_by` fields. The single sentence provides no syntax guidance, filtering examples, or explanations for complex parameters like `request_json_query` or `resource_class_in`.

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 'Group[s] analyzed traffic' and specifies the benefit of 'lower token cost' for inspecting 'hot spots.' While it effectively conveys the aggregation purpose, it does not explicitly differentiate from sibling tools like `analyze_recorded_traffic` or `get_traffic_entry_detail` beyond the efficiency hint.

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 context by mentioning 'inspect hot spots' and emphasizes the 'lower token cost' benefit, suggesting when to choose this over detailed analysis tools. However, it lacks explicit when-not-to-use guidance or named alternatives among the 17 sibling tools.

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

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

No annotations are provided, so the description carries the full disclosure burden. It fails to mention whether this is read-only, idempotent, performant, or what scope of recordings are returned (all vs. filtered). The agent gets no behavioral hints beyond the basic action.

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?

While brief, the second clause ('using an explicit history-oriented tool name') is meta-commentary about the tool's naming convention that provides zero value to an AI agent trying to select or invoke the tool. This constitutes wasted space in a short description.

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

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

Given zero input parameters and the existence of an output schema, the description adequately covers the minimal input requirements. However, it lacks domain context about what constitutes a 'recording' in this system (e.g., Charles Proxy recordings vs. sessions) and omits any mention of the output structure despite the presence of an output schema reducing the burden.

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 zero parameters with 100% schema description coverage. Per the scoring rules, zero-parameter tools receive a baseline score of 4 since there are no parameter semantics to describe beyond what the empty schema already conveys.

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 core action ('List saved recording files') with a specific verb and resource. However, it does not differentiate from siblings like 'list_sessions' or 'query_recorded_traffic', leaving ambiguity about when to choose this over similar tools.

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

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

No explicit guidance on when to use this tool versus alternatives like 'list_sessions' or 'query_recorded_traffic'. The phrase 'history-oriented' weakly implies use for historical data but lacks concrete when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries full disclosure burden. It indicates a read operation (List) but provides no details about output format, pagination, filtering behavior, or what distinguishes a 'session file' from a 'recording' (relevant given the sibling tool).

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

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

Single sentence that efficiently conveys the core function. The phrase 'via the legacy tool name' is somewhat cryptic and could be clearer, but the description avoids unnecessary verbosity and places the action verb at the beginning.

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?

Adequate for a zero-parameter tool with an output schema (which handles return value documentation). However, it lacks explanation of the 'legacy' designation's practical implications—whether this tool is deprecated, returns different data than `list_recordings`, or requires specific compatibility considerations.

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?

Input schema has zero parameters, which establishes a baseline score of 4 per the evaluation rules. With no parameters to describe, the description is not penalized for missing parameter details.

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?

Uses specific verb 'List' and resource 'historical session files'. The phrase 'via the legacy tool name' distinguishes it from sibling `list_recordings` by implying this is the older/deprecated interface, though the phrasing is slightly ambiguous about whether the tool itself is legacy or accesses legacy data.

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 'legacy tool name' mention implies this may not be the preferred modern approach compared to `list_recordings`, suggesting implied usage context. However, it fails to explicitly state when to use this versus the alternative or what 'legacy' means for the caller.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It successfully communicates that the operation is non-destructive ('does not consume items'), safe for polling, and returns compact summaries. It does not mention error conditions or authentication requirements, hence not a perfect 5.

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

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

Four sentences with zero waste: opens with the core action, details the return format, explains the safety/behavioral contract, and concludes with sibling differentiation. Every sentence earns its place and is front-loaded with critical information.

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

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

Given the tool's moderate complexity (3 params, simple concept) and the existence of an output schema, the description is appropriately complete. It summarizes the return value sufficiently without duplicating the output schema, though it could have briefly mentioned the limit parameter's role in pagination.

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%, requiring the description to compensate. It successfully explains the 'cursor' semantics ('without advancing the cursor'), which is the most complex parameter (anyOf int/null). However, it omits explicit description of 'limit' and 'capture_id', though these are relatively self-explanatory from their titles 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 clearly states the action (preview incremental traffic), the resource (live capture), and the key mechanism (without advancing the cursor). It effectively distinguishes from siblings by contrasting with query_live_capture_entries and implying the difference from read_live_capture through the 'does not consume items' clarification.

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?

Excellent guidance provided: explicitly states 'Safe to call repeatedly' indicating polling scenarios, clarifies the non-consuming nature (idempotent peek semantics), and directly names the alternative tool 'query_live_capture_entries' for when structured filtering is needed instead of simple preview.

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

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

With no annotations provided, the description carries full burden. It discloses the dual-mode behavior (capture vs read) but omits critical operational details: where captures are persisted, whether they overwrite previous data, what the 'history package' format is, or any side effects.

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?

Single sentence efficiently conveys dual functionality without verbosity. Front-loaded with the primary action. Minor awkwardness in 'saved history package' phrasing prevents a 5.

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 has only one parameter (well-documented in schema) and an output schema exists (per context signals), the description adequately covers the functional scope. The dual-mode behavior is mentioned, though could be elaborated.

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

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

Schema coverage is 100% with detailed parameter descriptions (including Chinese documentation explaining the 0-value behavior and timestamp warnings). The description adds no parameter context, but the schema handles this adequately, warranting the baseline score.

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

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

States two distinct operations clearly: 'Capture traffic for a fixed duration' (time-boxed recording) and 'read the latest saved history package' (retrieval). The 'fixed duration' phrasing implicitly distinguishes it from sibling start_live_capture which likely runs indefinitely.

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

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

No guidance on when to choose capture mode vs read mode (record_seconds=0), nor when to use this versus siblings like start_live_capture, read_live_capture, or get_recording_snapshot. The dual-purpose nature creates ambiguity without selection 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?

No annotations provided, so description carries full burden. It successfully discloses critical cursor behavior ('Does NOT advance the cursor — safe to call repeatedly') and default scanning behavior ('Default cursor=0 scans all captured data'). Missing details on rate limits, auth requirements, or exact return structure, though output schema 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?

Five sentences, zero waste. Front-loaded with purpose, followed by recommendation, behavioral warning, parameter default, and sibling reference. Every sentence earns its place with high information density.

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 24-parameter complex filtering tool, the description covers the unique behavioral aspects (cursor immobility) and sibling relationships adequately. However, given zero schema descriptions, it lacks explanation of the filtering paradigm, preset meanings, or parameter interactions. Output schema exists, mitigating need for return value description.

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 across 24 parameters, the description fails to compensate adequately. It explains cursor behavior specifically but leaves 23 other parameters (host_contains, request_json_query, preset enums, etc.) completely undocumented. No explanation of filtering syntax or preset options provided.

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?

Description opens with specific verb 'Analyze' and resource 'active live capture' plus methodology 'structured summary-first filtering.' It clearly distinguishes from sibling get_traffic_entry_detail by specifying this is for summary analysis versus drilling down.

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

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

Explicitly states 'This is the RECOMMENDED tool for inspecting live traffic' and provides clear alternative guidance: 'Use get_traffic_entry_detail to drill down into a specific entry_id.' Also implies when-not by emphasizing cursor safety for repeated calls.

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

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

With no annotations provided, the description carries the full burden. It discloses the critical behavioral trait of auto-selecting the 'latest' recording (explaining the absence of a recording_id parameter) and the boundary constraint against reading live sessions. However, it omits details about return format, read-only safety, or performance limits.

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

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

Two sentences, zero waste. The first sentence establishes the core function, while the second sentence immediately addresses the critical distinction from live capture tools. 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?

Given the presence of an output schema, the description appropriately omits return value details. It covers the essential scope (saved vs live) and the implicit recording selection behavior. However, gaps remain regarding the filtering capabilities and the undocumented boolean parameters.

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

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

Schema coverage is 60%, with keep_request and keep_response lacking descriptions. The description adds no information about the filtering parameters (host_contains, http_method, keyword_regex) or the boolean flags, failing to compensate for the schema gaps. The word 'Query' vaguely implies filtering but provides no specific 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 provides a specific verb (Query) and resource (latest saved recording), clearly distinguishing it from live capture tools. The explicit statement 'never reads the live Charles session' effectively differentiates this tool from siblings like read_live_capture and query_live_capture_entries.

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 'never reads the live Charles session' provides clear contextual guidance for when to use this tool (saved recordings) versus live capture alternatives. However, it stops short of explicitly naming the sibling tools or stating positive conditions like 'Use this when analyzing historical traffic.'

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

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

With no annotations provided, description carries full burden and succeeds well: discloses cursor advancement (state mutation), return format ('compact entry summaries: host/method/path/status only'), and incremental nature. Minor gap: doesn't explain initial cursor state (null) behavior or error conditions.

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

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

Four sentences, zero waste: (1) purpose, (2) return format, (3) sibling alternative, (4) cursor behavior. Front-loaded with action and resource. Every sentence provides unique value not found in structured fields.

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 has an output schema, the description appropriately summarizes return values without redundancy. Covers the critical 'live capture' cursor mechanics thoroughly. Slight deduction for not clarifying the initial cursor=null state, but overall comprehensive for a streaming/polling tool.

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

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

Schema has 0% description coverage. Description mentions 'cursor' explicitly and its advancement behavior, but doesn't explain 'capture_id' (what it identifies) or 'limit' beyond implied pagination. Mentions cursor semantics but doesn't fully compensate for the schema's lack of parameter descriptions.

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

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

Description opens with specific verb 'Read' + resource 'incremental traffic' and immediately clarifies the core mechanism 'advance the cursor'. It distinguishes from sibling 'query_live_capture_entries' by directing users to that tool for 'structured filtering instead of this tool', and implies distinction from 'peek_live_capture' via the cursor advancement warning.

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

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

Provides explicit alternative: 'Use query_live_capture_entries for structured filtering instead of this tool'. Explains critical usage pattern: 'repeated calls only return new items' due to cursor advancement, which tells the agent when to poll vs when to seek historical data.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive-then-restorative pattern ('Reset... and restore'), implying state reversion rather than clearing to factory defaults. However, it fails to specify what exactly gets reset (active captures? settings? sessions?) or whether unsaved work is permanently destroyed.

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 consists of a single, efficient sentence that frontloads the action verb 'Reset' and immediately qualifies the scope with 'restore the saved configuration.' Every word contributes to understanding the tool's dual-phase behavior without 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?

While the description identifies the general operation, it lacks critical context for a state-resetting tool: it does not specify the scope of the reset, the source of the 'saved configuration,' or warn about destructive side effects. The existence of an output schema reduces the burden to explain return values, but the operational impact remains 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?

The input schema contains zero parameters, establishing a baseline score of 4 per evaluation rules. The description appropriately does not invent parameter semantics where none exist in 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 specific verbs ('Reset' and 'restore') with the resource 'Charles environment' and distinguishes this state-management tool from traffic-analysis siblings like 'analyze_recorded_traffic' or 'query_live_capture_entries'. However, it assumes familiarity with what constitutes the 'Charles environment' without defining 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 description provides no indication of when to invoke this tool versus alternatives, nor does it warn about potential data loss from resetting active sessions. There is no mention of prerequisites (e.g., whether a configuration must be saved first) or safe usage patterns.

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

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

With no annotations, the description carries the full burden. It discloses the return value (capture_id) and the adopt vs. start distinction ('without clearing it'), but omits behavioral details for reset_session/include_existing, session lifecycle, and what 'Charles' refers to.

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?

Three sentences with zero waste: purpose front-loaded, return value stated, and specific parameter usage included. Every sentence earns its place 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?

Adequate for a session initialization tool with an output schema (which handles return documentation), but gaps remain: two parameters lack semantic explanation, and the 'Charles' ecosystem context is only mentioned in passing.

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

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

Schema has 0% description coverage (only titles). The description compensates by explaining adopt_existing behavior, but leaves reset_session and include_existing completely undocumented with no indication of their effects or default behaviors.

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 starts or adopts a live capture session for incremental polling, explicitly mentions it returns a capture_id required by all other live tools, and distinguishes itself as the entry point for the live capture workflow versus recorded traffic 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?

Provides specific guidance on using adopt_existing=true to take over sessions without clearing them, and implies this must be called first for live workflows. However, lacks explicit when-not-to-use guidance or comparison to alternatives like analyze_recorded_traffic.

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

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

With no annotations provided, the description carries the full burden. It adds valuable context about the persistence option and status verification, but fails to disclose mutation characteristics, idempotency concerns, or what occurs when persist=false (e.g., data loss risks).

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 efficiently convey the core action, optional persistence behavior, and critical status-checking guidance without redundancy. Every sentence earns its place and critical information 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 has an output schema (reducing the need to describe return values) and a simple 2-parameter structure, the description covers the primary behavioral concerns. However, gaps remain in parameter documentation and explicit state transition prerequisites.

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%, requiring the description to compensate. It implicitly references the 'persist' parameter via 'optionally persist' but provides no semantics for 'capture_id' (what format, where to obtain it). Partial compensation warrants a below-average score.

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 specific action ('Stop an active live capture') and resource, distinguishing it from siblings like start_live_capture, peek_live_capture, and read_live_capture. The mention of 'filtered snapshot' adds specific context about what is being handled.

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 by specifying 'active' live capture and provides a validation hint ('Only status='stopped' means the capture is fully closed'), but lacks explicit guidance on when to use this versus peek_live_capture or read_live_capture, and omits prerequisites like requiring an active capture_id.

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

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

No annotations provided, so description carries full burden. It fails to disclose whether changes apply immediately to active connections, persist across sessions, or explain behavioral differences between enum values like 'off' vs 'deactivate' vs 'stop'.

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?

Single sentence, appropriately front-loaded with zero 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?

Given low complexity (1 parameter), 100% schema coverage, and existence of output schema, the description is minimally viable. However, lacks behavioral context that would help an agent distinguish between the 'off'/'deactivate'/'stop' states.

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

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

Schema description coverage is 100%, documenting the preset parameter and its allowed values. The description adds no parameter semantics, earning the baseline score for high 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 uses a specific verb ('Set') and clear resource ('network throttling preset'), distinguishing it from sibling analysis/capture tools. However, it assumes familiarity with 'Charles' (Charles Proxy) without context.

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 provided on when to apply throttling vs. analyzing traffic, prerequisites (e.g., active capture session), or how to disable throttling (though 'off'/'deactivate' enum values exist).

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