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

With no annotations, the description carries the full burden. It usefully discloses that the operation is offline, requires no device connection, and lists return metrics, which is real behavioral context. However, it omits error behavior (invalid capture_id), whether the op is purely read-only, and any resource constraints.

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 compact sentences with the core purpose front-loaded and return values secondary. Little waste, though the parenthetical unit annotations add minor clutter.

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?

No output schema exists, so the description appropriately enumerates returned values (mean/min/max/median/charge/energy and envelope). Combined with partial parameter coverage, it is nearly complete for this tool, with the envelope_points gap the main omission.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies start_s/end_s semantics (sub-window selection), but says nothing about envelope_points or units, leaving one of four parameters undocumented everywhere.

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

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

States a specific verb+resource (offline analysis of historical captures) and clarifies scope (full window or [start_s,end_s] sub-window). The '无需连接设备' clause distinguishes it from the acquisition siblings (capture/start_capture/stop_capture), though it doesn't name an alternative explicitly.

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

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

Usage is implied — analyze stored captures offline — but there is no explicit when-to-use vs alternatives (e.g., detect_activity_segments also analyzes data) and no when-not guidance or prerequisites stated.

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

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

With no annotations, the description carries the full burden and delivers meaningful behavior: it is blocking, capped at ≤60s, persists an npz to disk, reports dropped-sample counts in meta, and constrains capture_id to alphanumerics/._-. It omits error/failure behavior and permission requirements, which keeps it short of a 5.

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

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

Front-loaded with the core verb and flow in one line, then return payload, then the id constraint. Every sentence carries information; only minor tightening is possible.

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

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

For a tool with no output schema and no annotations, the description explains the return payload (stats, envelope, meta, path) and the side effect (npz on disk), which is what an agent needs. The main remaining gap is not routing the agent between this blocking capture and the start/stop/status trio.

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% with two parameters, so the description must compensate. It documents the capture_id charset constraint but says nothing about duration_s (default, units beyond the implied seconds, allowable range), leaving half the parameter surface unexplained.

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

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

The description names a specific operation (定长采集) and spells out the full pipeline: 采样→落盘 npz→返回统计+包络+路径. It distinguishes itself implicitly as a blocking fixed-duration capture rather than a streaming flow, but it never names the sibling tools (start_capture/stop_capture/get_capture_status) it is contrasted against.

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?

'这是功耗分析的主入口' and '定长采集(阻塞,≤60s)' imply the context in which it is used (a bounded, blocking single-shot capture), but there is no explicit when-to-use guidance nor any statement of when to prefer the start/stop/get_status capture siblings instead.

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

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

With no annotations, the description must carry behavioral disclosure. It reveals the connection side effect and that metadata is read, plus the auto-discovery default. It does not state idempotency (reconnect while connected), permission requirements, or failure behavior, leaving meaningful gaps.

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

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

Three short sentences, front-loaded with verb+resource, then the metadata returned, then the port default and follow-up hint. No redundant restatement of the name or title.

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 connect tool with no output schema and no annotations, it covers the essentials (what it returns, port behavior, next step). It omits error/duplicate-connection semantics and any caveat about reconnecting, so it is adequate but 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?

Schema coverage is 0% for the single optional 'port' parameter, and the description compensates by explaining that omitting it triggers auto-discovery. That is genuine semantics beyond the schema's type/default. It still does not state the port's expected string format, preventing a 5.

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

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

States a specific verb (连接) and resource (PPK2), and clarifies the secondary effect (reading calibration coefficients, Calibrated flag, VDD). This makes it easy to distinguish from sibling disconnect. It does not explicitly contrast with any sibling, keeping it at 4 rather than 5.

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

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

It establishes context (port auto-discovery) and names a follow-up (get_status for calibration status), which implies the typical flow. However, it gives no when-not guidance, no alternatives (e.g., list_devices before connecting), and no prerequisites for the connection itself.

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

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

With no annotations, the description carries the full burden, and it partially meets it by disclosing the return contents (per-segment start/end/mean/charge and active duty-cycle) and the glitch-filtering behavior of min_duration_s. It does not state that the operation is read-only/non-mutating, nor mention permissions, rate limits, or how results are scoped. Adequate but incomplete for a zero-annotation tool.

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

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

The text is compact and front-loads the mechanism and threshold parameter before the return values and optional filter. Every clause carries information; only minor polish (no explicit delimiter between mechanism and output description) keeps it from 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?

Since there is no output schema, the description's enumeration of returned fields (start/end/mean/charge, duty cycle) is genuinely necessary and present, which is a strength. But it omits the meaning of capture_id and the start_s/end_s window for a 5-parameter analysis tool, leaving a gap an agent would need filled elsewhere.

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% across 5 parameters, so the description must compensate. It explains threshold_ua (the segmentation threshold) and min_duration_s (filters out short/glitch segments), covering 2 of 5. It says nothing about capture_id, start_s, or end_s, leaving the time-window semantics of the analysis range 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 names a specific operation (power-consumption segmentation) and the mechanism (threshold hysteresis dividing into active/sleep segments keyed on threshold_ua), which is more informative than a generic 'analyze' label. It differentiates itself implicitly from the broad analyze_capture sibling by describing the segmentation method. It stops short of explicitly naming the alternative, so it is not a 5.

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

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

It gives an implied usage frame by stating it answers questions like 'what is the sleep current / active duty cycle', which tells the agent when this tool is relevant. However, there is no explicit when-not guidance and no mention of analyze_capture or estimate_battery_life as alternatives, so the agent must infer the boundary.

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

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

With no annotations, the description carries the full burden. It does disclose one genuinely useful behavioral trait — that an in-progress sampling session is stopped first — which is an important side effect. However, it says nothing about error behavior (e.g. disconnecting when not connected), resource cleanup, or reconnect 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?

A single short sentence with the action front-loaded and the side effect parenthetically appended; nothing is wasted. It is arguably too terse for a state-mutating operation, but it is 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?

For a zero-parameter, annotation-free tool with no output schema, the description covers the core action and the key side effect (stopping sampling). It omits what state results after disconnection and whether the call is idempotent or errors when already disconnected.

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 takes zero parameters, so there is nothing for the description to add; baseline for a no-parameter tool is 4. The schema is vacuously complete.

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

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

States a specific verb and resource: disconnecting the serial port. It is a clear, unambiguous action, but it never differentiates itself from the sibling 'connect' or explains how it relates to the capture/sampling siblings it interacts with.

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

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

Usage is only implied by the tool name; there is no explicit statement of when to use it versus alternatives such as 'connect', nor any prerequisites or exclusions. The parenthetical hints at the sampling context but does not give selection guidance.

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

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

With no annotations, the description carries the full burden. It clarifies the tool is a computation producing hours/days and that capture_id triggers automatic window-mean averaging, which is useful behavioral context. But it omits what happens when both sources are given or neither is, whether start_s/end_s bound the averaging window, and any error 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?

Two short, front-loaded paragraphs: the purpose first, the input-mode rule second. No filler text, and the default for capacities_mah is stated compactly. It is efficient, though the two language-register switch (Chinese body vs. English identifiers) slightly interrupts flow.

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 5-parameter tool with no annotations and no output schema, the description covers purpose, the two data sources, and one default, which is the essential shape. It still leaves the start_s/end_s semantics and the both/neither-source behavior unexplained, and gives only partial output detail (hours/days), so completeness is adequate but not full.

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, and it explains three of five parameters: capture_id (auto window mean), mean_ua (direct value), and the default for capacities_mah. It never explains start_s or end_s, leaving the window boundaries undocumented, so it only partially closes the coverage 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 gives a specific verb and resource: estimating battery life (hours/days) across several capacities from a mean current. This is unambiguous, and no sibling tool performs anything comparable, so an agent can select it correctly without opening the schema. It stops short of explicitly differentiating from siblings, but none conflict.

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 the two mutually exclusive input modes ('数据来源二选一: capture_id ... 或直接给 mean_ua'), which is real guidance on how to source the current value. However, there is no guidance on when to prefer this tool over the capture/analyze tools or prerequisites for obtaining a capture_id. Usage context is implied rather than 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?

No annotations exist, so the description carries the full disclosure burden. It does state the key behavioral trait — this reflects a live, ongoing capture and reports sample/loss/rate/duration counters — but omits what happens when no capture is running (error vs empty) and does not confirm it is a non-mutating read.

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

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

A single, front-loaded sentence with a label-then-fields structure ('real-time status of in-progress capture: samples/lost/rate/duration'). No filler and 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 no output schema and no annotations, the description usefully enumerates the four returned metrics, which is the main thing an agent needs. It leaves a small gap around behavior when no capture is active, but is otherwise complete for a zero-parameter status probe.

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 takes zero parameters, so there is no parameter semantics to document; the empty argument schema is self-explanatory and the description needs no compensation. Baseline 4 applies.

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

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

The description names a specific verb+resource combination (real-time status of an in-progress capture) and enumerates the returned metrics (samples captured/lost/rate/duration), so an agent can tell it apart from list_captures at a glance. It never explicitly names a sibling, so it stops short of the top score.

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?

"进行中采集" (in-progress capture) implies the appropriate usage window and distinguishes it from historical listing tools, but there is no explicit when/when-not statement and no alternative named for checking finished captures.

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

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

No annotations are provided, so the description carries the burden. It usefully enumerates the state domains the snapshot covers, but never states that this is a read-only, side-effect-free operation, which is the key behavioral fact for a zero-arg status tool.

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

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

A single compact sentence that front-loads the core concept ('会话快照') and then lists the covered state. Every element earns its place, though the terse colon-list style leaves no room for 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?

With no output schema and no annotations, the description does the heavy lifting by enumerating the returned state fields, which is exactly what is needed. Only the read-only/side-effect behavior and sibling differentiation 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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly adds no parameter-level detail because none exists.

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

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

States a specific verb+resource: a session snapshot enumerating connection/identity/mode/VDD/capture/calibration state. Clear what it returns, but it does not differentiate itself from the sibling get_capture_status, with which it explicitly overlaps via '采集进行中状态'.

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 when-to-use, when-not-to-use, or alternative routing is given. An agent is left to infer that this is a general status check, and the overlap with get_capture_status is not resolved.

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

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

With no annotations, the description carries the burden, and it does disclose two behavioral traits: the output is an npz metadata table and results are ordered newest-first. However, it says nothing about pagination, filtering, auth, or volume, which matters for a listing operation over accumulated history.

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

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

A single front-loaded sentence whose parenthetical puts the return content inline, followed by the ordering constraint. Every clause earns its place with no waste.

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 trivial no-arg listing tool with no output schema, the description does the heavy lifting by naming the metadata fields the table contains and stating the sort order. What is missing is only speculative extras like pagination or row limits.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter discussion.

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

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

States a specific verb (列出/list), a specific resource (历史采集/historical captures), and even enumerates the returned metadata fields (duration/rate/dropped samples/path). This distinguishes it from status-oriented siblings like get_capture_status and get_capture_status, but it does not explicitly name those siblings, so it falls short of a 5.

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

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

Usage is only implied: an agent can infer it is for browsing past captures, but the description gives no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_capture_status or analyze_capture. Adequate but with a clear gap.

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

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

With no annotations, the description must carry behavioral disclosure, and it does add real context: the probe mechanism, that the return is a list of candidate ports, that an empty list means no hardware, and the mock-mode escape hatch. It omits anything about scan duration, timeouts, or whether it opens/locks the ports it finds.

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

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

Two short clauses, front-loaded with the action and followed by the return contract and the mock note. Nothing is padded, though both clauses sit in a single terse block.

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 compensates for the absent output schema by describing the return value (candidate port list, empty on no hardware). For a zero-parameter discovery tool this covers what an agent needs, with only timing/port-locking details left unstated.

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 takes zero parameters, so the baseline is 4; the schema has nothing to document and the description correctly does not invent 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?

States a specific verb and resource: scans serial ports and probes for a PPK2, identifying the command port via the 0x19 metadata response. The purpose is unambiguous, but it never references a sibling (e.g., connect, list_captures) to sharpen its boundary.

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

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

Usage is only implied — an agent can infer this is the discovery step before connect, and the mock hint (PPK2_MOCK=1) suggests a demo/no-hardware path. There is no explicit statement of when to call it versus alternatives or of prerequisites.

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 present, the description carries the full burden and does well: it discloses a dangerous side effect (0x20 = RESET, which triggers USB re-enumeration) and an operational precondition (unusable during sampling). It does not describe response format or error behavior, but the key destructive trait is surfaced.

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

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

Two short sentences, front-loaded with the purpose, followed by the two constraints. Every clause carries operational information 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 low-level escape-hatch tool with no output schema and no annotations, the definition covers input format, the destructive case, and the unavailability window. Missing only return-value or failure-mode expectations, which is a minor gap for an escape hatch.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and largely does: data_hex is described as hex bytes with an example, and confirm is tied to a precise trigger condition (presence of 0x20). Encoding details are only partially specified, so it stops short of a 5.

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

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

States a specific verb and resource: send raw command bytes (hex) and retrieve the response, plus a concrete example ("19" reads metadata). The "逃生舱" (escape hatch) framing plus "raw" distinguishes it from the high-level siblings like set_mode or capture, though no sibling is named explicitly.

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

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

Gives two concrete conditions: confirm=true is required when the payload contains 0x20, and the tool is unavailable while a sampling/capture is in progress. This tells the agent when it may and may not call it, though it does not explicitly say to prefer a higher-level sibling whenever one exists.

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

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

No annotations are provided, so the description carries the full burden. It does disclose useful behavior: mode-dependent return shapes, pagination via offset/limit, edge direction via level_after, and the valid channel range 0-7. It never states the operation is read-only, nor how start_s/end_s scope the sample window, so the disclosure is only partial for a 7-parameter 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?

Very compact, front-loaded statement of purpose followed by a per-mode breakdown. No filler sentences; every clause carries information. Slightly cryptic notation (level_after 判向) costs a little clarity but nothing is wasted.

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

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

With no output schema and 0% schema coverage across 7 parameters, the description supplies the essential mode semantics and pagination but omits the meaning of capture_id and the start_s/end_s window and gives no hint about the response shape of 'stats'. Adequate but noticeably incomplete 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?

Schema description coverage is 0%, so the description must compensate. It clarifies mode values, offset/limit pagination, channel bounds (0-7), and level_after's direction meaning, but leaves capture_id, start_s, and end_s entirely unexplained and gives no format examples for the time bounds.

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?

Names the specific resource (8 logic input channels) and its key trait (sampled synchronously with current), and breaks the tool into two output modes. The verb is only implicit via the tool name, and there is no explicit differentiation from siblings like analyze_capture or detect_activity_segments, but an agent can tell this reads logic-channel data from a capture.

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

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

Explains what each mode yields ('stats' = high-level ratio/edge count, 'edges' = paginated edge table), which implicitly tells the agent which mode to pick based on desired output. However, there is no guidance on when to use this tool at all versus analyze_capture, detect_activity_segments, or list_captures.

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

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

No annotations are provided, so the description carries the full burden. It conveys the effect (接通/切断输出) and app-equivalence, but says nothing about side effects on an in-progress measurement, whether the state persists, whether a mode precondition causes failure, or what errors/auth are involved for what is clearly a state-mutating operation.

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 compact sentence with the core action front-loaded and the mode/app context in parentheses. Every clause earns its place; only the slightly terse parenthetical framing keeps it from being ideal.

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 tool with no output schema, the essentials (what it toggles, in which mode) are present. But with zero annotations and no return/error description, an agent cannot predict failure conditions or side effects on ongoing captures, leaving meaningful 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 coverage is 0% and the single required boolean 'on' has no schema description. The description partially compensates by pairing 接通/切断 (connect/cut) with the output concept, implying on=true energizes the DUT, but it never explicitly binds true/false to those states.

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

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

States a specific verb+resource: toggling DUT power output, and clarifies it only makes sense in SOURCE mode and mirrors the official app's power button. This is far clearer than a bare name, though it does not explicitly distinguish itself from siblings like connect/disconnect or set_mode beyond the SOURCE-mode qualifier.

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 'SOURCE 模式下' implies the precondition that the device must already be in SOURCE mode, which is useful routing context. However, there is no explicit when-to-use guidance, no exclusion of alternatives (e.g., connect/disconnect), and no statement of what to do if the mode is wrong.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cross-tool dependency (SOURCE requires set_source_voltage before capture), but says nothing about whether switching modes interrupts an active capture, whether the setting persists, or what permissions/connection state are needed for this mutation.

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

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

Two tight sentences with the mode choices front-loaded and the SOURCE prerequisite appended as a second, actionable sentence. No filler, though the phrasing is terse enough that a reader may want slightly more framing.

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

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

With no output schema and no annotations, the description covers the essential facts an agent needs: the two valid modes, their semantics, and the SOURCE-mode prerequisite. Missing only peripheral state/edge-case behavior (mid-capture switching, persistence), which is a minor gap for a single-parameter setter.

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 schema defines no enum for `mode`, so the description is the only source of accepted values. It compensates well by naming and explaining both legal values, though it does not state case-sensitivity or 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?

States a specific verb+resource (设置测量模式) and immediately enumerates the two valid values, AMPERE and SOURCE, with a short gloss of each. An agent can distinguish this from siblings like set_source_voltage or set_dut_power without opening the schema.

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?

Explains the condition that selects each mode (AMPERE = external supply, SOURCE = PPK2 powers the DUT) and adds the prerequisite that SOURCE mode requires set_source_voltage before capturing. It stops short of stating when *not* to use the tool, whether mode can be switched mid-capture, or the default mode, so it is clear context rather than full routing guidance.

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

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

With no annotations provided, the description carries the full burden and does disclose a genuinely non-obvious behavior: the firmware has no native auto-restore command, so rng=null is implemented by re-switching the current mode. This is valuable side-effect information an agent would otherwise not know. It does not say whether the mode re-switch disturbs other settings, ongoing captures, or requires an active connection, leaving some behavioral gaps.

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

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

Two short sentences, front-loaded with the core action and value mapping, followed by the null/auto behavior. Every clause carries information; 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 single-parameter setter with no output schema and no annotations, the description covers the value domain, defaults, and the restore quirk. It leaves unstated whether the change persists, what happens on invalid input, or whether it interferes with an in-progress capture, which keeps it just under 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 — and it does fully: it explains the 0-4 integer scale, the physical meaning of each end of the scale, and that null means restore auto. Nothing about the single parameter is left 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?

States a specific verb+resource ('锁定量程' / lock the range) and immediately defines the value domain: 0 = most sensitive (~nA), 4 = maximum (~A). An agent can distinguish this from sibling setters like set_mode or set_source_voltage without opening the schema.

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?

Gives clear context: the device defaults to auto range, and this tool is used to lock it. It also specifies how to return to auto (rng=null), which is actionable usage guidance. No explicit when-not or comparison against sibling setters, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose important behavior: the 800-5000 mV range and that out-of-range values are automatically clamped rather than rejected. It stops short of noting permissions, persistence, or interaction with mode 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?

Two tight lines with the range and clamping front-loaded, then the mode-dependent interpretation. Every sentence carries information; only the mode clause is slightly terse and could be clearer.

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 tool with no output schema or annotations, the description covers units, bounds, clamping, and mode-dependent effect, which is enough to call it correctly. It could note the dependency on set_mode having been invoked, but no critical information is missing.

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

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

Schema description coverage is 0%, so the description must compensate; it supplies the unit (mV) and a concrete numeric range plus clamping semantics for the single parameter. That meaningfully exceeds the bare "integer" schema type.

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

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

States a specific verb+resource ("设置电压" / set voltage) with units and valid range, so the agent knows exactly what the tool does. It does not explicitly differentiate itself from siblings like set_dut_power, but the resource and constraint set are 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?

Explains that meaning depends on the active mode (SOURCE = actual regulator output, AMPERE = VDD estimate for current conversion), which is genuine usage context. However, it never says when to prefer this over alternatives or whether a mode must be set first, so guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It does disclose two useful behavioral facts—that the official default is enabled, and that the setting affects smoothing of range-switching spikes (换程尖峰的平滑). It does not say what disabling does, whether the change persists, or what the toggle returns.

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 compact sentence with the resource front-loaded, followed by the default and effect in parentheses. No wasted words, though the parenthetical stacking slightly compresses two distinct facts.

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 toggle with no annotations or output schema, the description covers the default state and the setting's effect but omits what changing it does operationally and when an agent should choose to toggle it. Adequate but with visible 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 for the single 'on' boolean. It partially does so by stating the default state is enabled, which informs the parameter's effect, but it never explicitly maps true/false to enabling or disabling the filter.

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

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

The description names a specific resource and action: a switch (开关) for hardware spike filtering (硬件尖峰滤波), which maps directly to set_spike_filtering. It is clear what the tool operates on, though it does not differentiate itself from sibling toggles like set_mode or set_resistor_range.

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

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

There is no explicit guidance on when to toggle this versus leaving it alone, and no alternatives are named. The note that it is on by default (官方默认开) faintly implies changes are optional, but this is not stated as usage guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: the operation is asynchronous, background, non-blocking and may run longer than 60s. It also implies the data lands on disk only when stop_capture is called. However, it says nothing about error conditions (e.g. a capture already running), permissions, or what happens to any in-progress capture.

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 compact sentences with zero filler, front-loading the operation and its async nature before the follow-up tool routing. Nothing could be removed without losing 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?

For a zero-parameter tool with no output schema and no annotations, the description supplies the essential context: async execution, expected duration, and the start/status/stop lifecycle. Missing only edge-case behavior for repeated invocation, which would round it out fully.

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 accepts zero parameters, so there is no argument semantics to explain; the baseline for a parameterless tool applies. The description correctly adds no redundant parameter talk.

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

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

States a specific verb and resource ('start a long capture') and immediately adds the defining traits (background, non-blocking, can exceed 60s). It clearly separates itself from stop_capture/get_capture_status by naming them as the follow-up steps, though it does not explicitly contrast with the ambiguous 'capture' sibling.

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 workflow routing: start here, then use get_capture_status to poll, then stop_capture to finish and persist. This tells the agent when to reach for the neighboring tools. It stops short of stating the condition under which the plain 'capture' sibling should be chosen instead.

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

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

With no annotations, the description carries the full burden. It usefully discloses that stopping persists data to disk and returns a capture-like summary, but omits permissions, error behavior, idempotency, and what happens if no capture is running.

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 compact sentence that is front-loaded with the action and side effect, with no filler 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 mutation tool with no annotations, no output schema, and an undocumented optional parameter, the description is incomplete. It should clarify capture_id semantics and the behavior when capture_id is omitted.

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 single optional capture_id parameter has 0% schema description coverage, and the description never mentions it. The agent cannot learn what it identifies, whether it can be omitted, or what a null value means.

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

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

States a specific verb and resource: stops a long capture, persists it to disk, and returns the same summary as capture. The 'stop' action clearly distinguishes it from start_capture and capture, though it does not name sibling tools explicitly.

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

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

Usage is implied: call it to stop an in-progress long capture. However, there is no explicit when-to-use, no prerequisites, and no routing against alternatives like get_capture_status or analyze_capture.

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