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

No annotations are supplied, so the description bears the full disclosure burden. 'Identify the attached KM003C' implies a read-only, side-effect-free query, and the field list signals it returns metadata rather than measurements. However, it does not state the failure behavior when no device is attached, nor whether the call is safe to repeat freely.

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 sentence with no filler: verb, target device, and the exact contents of the response. Everything an agent needs 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?

For a trivial zero-parameter identity query with no output schema, listing the returned fields covers the essential gap the schema leaves. The only missing piece is the not-attached/error case, which is minor for this 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?

The schema has zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool applies. The description's enumeration of returned fields is a small bonus but not required.

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 ('Identify') and resource ('the attached KM003C'), then enumerates exactly what identity data comes back: model, hardware/firmware version, serial, and trigger port. That makes it easy to separate from siblings like measure or pd_status, though it never explicitly contrasts itself with them.

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 name and the word 'attached' — an agent can infer this is the discovery/enumeration call to make before other operations, but there is no explicit statement of when to call it or what to do if no device is present.

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 meaningful work: it discloses units (V, A, W, °C), that samples are taken interval_ms apart, that mean/min/max are computed for three of the fields, and the sign convention for positive current (receptacle to plug). It stops short of stating how long a multi-sample call blocks or what errors/permissions apply.

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 paragraphs, zero filler, with the measurement set front-loaded and the sampling/aggregation behavior immediately after. Every sentence (units, interval semantics, sign convention) 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?

No output schema exists, so the description must describe returns — it names the measurement channels and the specific fields that get mean/min/max treatment. Combined with the sampling semantics, an agent has enough to call this correctly and interpret the result.

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 two params have only bare titles and defaults, so the description must compensate — and it does: samples is explained via 'with samples > 1 the readings are taken interval_ms apart', and interval_ms is given real meaning as the spacing between samples. Aggregation behavior (mean/min/max) tied to samples > 1 adds semantics the schema entirely lacks.

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?

Opens with a specific verb ('Read') and enumerates the exact resources measured (VBUS/IBUS/power, CC1/CC2, D+/D-, VDD, temperature), so an agent knows precisely what this returns. It does not explicitly distinguish itself from siblings like device_info, pd_status, or stream_samples, leaving the one-shot vs. streaming distinction to be inferred.

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?

Implicit guidance is present: 'with samples > 1' tells the agent when to use averaging mode, and the default samples=1 implies the simple single-reading case. However, there's no explicit statement of when to prefer this over stream_samples or pd_status, and no prerequisites (device connection/claim state) are given.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses pagination semantics but omits whether the tool is read-only, whether reading consumes or clears the capture buffer, and what happens when no more events remain.

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

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

The description is a single front-loaded sentence with no filler. Every element contributes to explaining the pagination model.

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?

There is no output schema and no annotations, and the description does not explain the return shape beyond `next`, the meaning of `decode`, buffer behavior, or prerequisites. It is too sparse for a three-parameter tool with no structured documentation.

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

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

Schema description coverage is 0%, and the description explains only `since` and the output `next`. It leaves `limit` and `decode` completely undocumented, so it fails to compensate for the missing schema descriptions.

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

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

The description states a specific verb, "Page through," and resource, "captured PD events," and explains the pagination index. It distinguishes reading from the capture-start/stop siblings, though "PD" remains somewhat domain-dependent.

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 implies repeated paging by mentioning `since` and `next`, but gives no explicit when-to-use guidance, no prerequisites such as starting a capture first, and no comparison to siblings like pd_capture_start or pd_status.

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 one important trait: capture runs 'in the background' (asynchronous). It says nothing about behavior if a capture is already running, whether prior buffers are overwritten, or permission/preconditions.

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 the verb and scope first, and the background/asynchronous detail appended where it is useful. No wasted words.

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

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

For a zero-parameter start action with no output schema, the core is covered, but the capture lifecycle is not: it does not say how captured data is retrieved or whether a stop is required before reading. That leaves the agent to infer the workflow from sibling names.

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 disambiguate beyond the schema; the baseline for a parameterless tool applies. No misleading parameter claims are made.

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 capturing USB PD traffic') and scopes it to messages and attach/detach events. It is clearly distinguishable from siblings like pd_capture_read and pd_capture_stop, though it does not explicitly name them.

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 begins a capture session and that pd_capture_read/pd_capture_stop are the follow-ups, but the description never says when to prefer it or what to do next. No exclusions or preconditions are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the post-condition that captured events remain readable until the next start, but does not say what happens if no capture is active, whether the operation is idempotent, or what it 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?

It is a single front-loaded sentence with no wasted words. The retention behavior is included immediately after the action, which is the right order.

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, output-less stop action, the description covers what it does and the key post-state. A note about behavior when no capture is running would make it 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?

The tool takes zero parameters, so there is nothing for the description to document beyond the action itself. The baseline for a no-parameter tool 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 states a specific verb ('Stop') and resource ('PD capture'), making its purpose unambiguous. It is naturally distinguished from the sibling pd_capture_start without needing to name it.

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 this to stop an ongoing PD capture. However, it gives no explicit when-to-use guidance, prerequisites, or alternatives such as pd_capture_read before stopping.

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 a non-obvious operational constraint: reads consume captured events, so the tool is mutually exclusive with an active capture. It does not say what the caller actually gets when invoked during a capture (error, empty result, or silent loss), nor whether reading mutates any buffer outside capture mode.

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, no filler, and the core purpose is front-loaded ahead of the constraint. Every sentence 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?

No output schema exists, and the description compensates by naming the five snapshot fields. The key exclusion is documented. Remaining gap is failure-mode behavior when called during a capture, which matters for a tool whose whole caveat is unavailability.

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 disambiguate; baseline 4 applies. The enumerated field list instead documents the return payload, which is a reasonable use of the space.

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?

Specific verb+resource: "Read the PD-side status snapshot" with the returned fields enumerated (timestamp, VBUS, IBUS, CC1, CC2). This clearly separates it from the pd_capture_* and stream_* siblings, though it never explicitly names pd_capture_read as the counterpart.

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 explicit when-not ("Not available while a PD capture runs"), which is real guidance, but never states the positive condition for use or names the alternative tool to call in that situation. The agent must infer that pd_capture_read/pd_capture_stop is the path forward.

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 behavioral burden and falls short. It does not say whether sampling consumes/clears the buffer or is non-destructive, what happens when the buffer is empty or the stream isn't running, or whether the call blocks — all critical for a buffer-reading streaming 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 front-loaded sentence with zero filler; the sampling cap and strategy both appear before the resource clause. 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?

There is no output schema and no annotations, so the description must explain what a returned sample looks like — yet it never does. For a streaming tool where capture timing and buffer state matter, the missing return shape and empty-buffer behavior leave an agent unable to predict results.

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 does some of the work: “up to max_samples” clarifies it's a cap, and “evenly spaced” explains how the subset is chosen — neither is in the schema. But it omits the default of 500 and what the spacing is computed over (time window vs whole buffer).

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 (“Return”), a specific resource (“samples from the running stream's buffer”), and even the selection strategy (“evenly spaced”). It's distinct from siblings like stream_start/stream_stop/stream_status, but it never explicitly contrasts itself with them.

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?

“From the running stream's buffer” implies the stream must already be started, which is a useful precondition delivered implicitly. However, there is no explicit when-to-use guidance, no statement of what happens if the stream is stopped, and no mention of alternatives such as stream_status for inspecting the stream.

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 burden. It does add real behavioral value — the operation is asynchronous ('in the background') and has an optional side effect writing every sample to csv_path — but says nothing about behavior if a stream is already active, buffering/drop characteristics at 1000 sps, or whether the CSV is appended or overwritten.

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 the core action and rate domain, then the optional side effect, then the companion-tool routing. 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?

With no annotations and no output schema, the description should cover start/stop semantics and failure modes; it covers the start and hands off to siblings for status and results, but leaves the agent guessing about re-entry behavior and whether data persists if the stream is never stopped.

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 largely does: it enumerates the allowed rate values (2, 10, 50, 1000 sps) matching the enum and explains csv_path as an optional per-sample CSV sink. It still doesn't state the CSV format or whether the file is truncated on start.

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 high-rate VBUS/IBUS sampling in the background') with concrete rate options, so the agent knows exactly what the tool initiates. It is clearly distinct from stream_status/stream_samples/stream_stop, but never contrasts itself with the sibling 'measure' (single-shot) or 'pd_capture_start', so full sibling differentiation is incomplete.

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 explicit lifecycle routing: use stream_status / stream_samples while running, and stream_stop to collect final statistics. What's missing is when to choose this over 'measure' or 'pd_capture_start', and whether a stream must be stopped before starting another.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It implies a read-only status check by listing running state, errors, statistics, and samples, but it does not explicitly state non-mutation, blocking behavior, permissions, or sample recency.

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 compact sentence with no filler, and it front-loads the most important status fields. The fragment style is terse but efficient.

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 is the only source of return information. It provides useful high-level categories but omits return structure, units, sample count or recency, and statistics names, leaving the agent without a precise return contract.

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 input parameters, so the baseline is 4. The description does not need to add parameter semantics 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 identifies the stream status resource and enumerates returned content: running state, error, live statistics, and recent samples. The purpose is clear, though it does not explicitly distinguish itself from sibling tools such as stream_samples or stream_start/stop.

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 use this tool, when not to use it, or which sibling to choose instead. An agent can infer it is for checking stream state, but tool selection among stream_status and stream_samples is left to inference.

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 a meaningful behavioral fact — that stopping also returns statistics — but says nothing about idempotency, error behavior when no stream is active, or whether the statistics are cumulative or since-last-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 zero filler, sized correctly for a no-argument action 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?

There is no output schema, so the description is the only source of return-value information — and 'its statistics' leaves the shape and content of that payload undefined. For a simple zero-param tool this is adequate but not complete.

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

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

There are zero parameters, so the baseline is 4; nothing about parameter semantics is left undocumented because there is nothing to document.

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 ('Stop the stream') plus the side benefit of returning statistics, which is unambiguous. It does not explicitly name its complement (stream_start/stream_status), but the name and description make the operation obvious.

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

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

No guidance on when to call this versus stream_status or stream_samples, or on preconditions such as whether a stream must be running first. The only hint at usage is the implicit lifecycle pairing with stream_start.

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 behavioral burden. It does not say whether this clears configured trigger state, whether calling it when not in trigger mode errors, or whether it is safe to repeat — all material for a mode-exiting 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?

A single short sentence with the key verb front-loaded and no filler. It is efficient, though the parenthetical CLI reference is the only added detail.

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 mode-exit command with no output schema and no annotations, the definition covers identity but not effect: what state changes, what is returned, and failure conditions are all absent.

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 disambiguate beyond what the empty schema already conveys; 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?

States a specific verb ('Leave') and a specific resource/state ('protocol trigger mode'), and the parenthetical CLI equivalent (`pdm close`) disambiguates. It is implicitly distinguishable from the sibling trigger_enter, though the description never names it.

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 when-to-use or when-not-to-use guidance, and no mention of related siblings such as trigger_enter or trigger_reset. The only cue is the implied pairing with entering trigger mode, which the agent must infer.

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 behavioral burden. It usefully discloses that extended probing is much slower and names the underlying `entry list+` behavior, but it omits whether detection is read-only, what side effects it may have on the charger, and how timeout_s affects execution.

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 primary purpose front-loaded and the extended-mode tradeoff immediately after. There is no wasted verbiage.

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 two-parameter detection tool with no annotations, no output schema, and 0% schema coverage, the description covers the core purpose and the extended-mode cost. It is still missing timeout semantics, expected return shape, and any safety or side-effect context, so it is only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains extended meaningfully by linking it to VOOC/MTK PE probing and increased latency, but it does not explain timeout_s or its units/effect, leaving one of two 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?

States a specific verb and resource: detect fast-charge protocols supported by the attached charger. It is clear what the tool does, but it does not explicitly distinguish itself from nearby trigger tools such as trigger_fast_charge or trigger_pd_source_caps.

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

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

The description gives conditional guidance for extended=True, noting that it probes VOOC/MTK PE and takes much longer. However, it does not state when to use this tool instead of sibling tools or when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a state change by saying "Enter," but does not state whether the device mode changes, whether it is reversible, what permissions are needed, or what happens on failure.

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

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

The description is a single front-loaded sentence with no filler, and the protocol list is placed where the agent will see it. Its brevity is efficient, though the protocol abbreviations are cryptic.

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 annotations and no output schema, the description needs to explain side effects and return behavior, but it does not. It also leaves the optional timeout_s parameter undocumented, making it insufficient for an agent to call this confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It does list allowed protocol strings, which is useful beyond the schema, but it never explains what pd, ufcs, qc, or the other abbreviations mean, and it completely omits the timeout_s parameter.

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

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

The description states a specific action and resource ("Enter a trigger protocol") and lists protocol identifiers, so the agent can infer this selects a trigger protocol mode. However, "enter" is vague about what actually happens, and it does not distinguish this tool from siblings such as trigger_fast_charge, trigger_pd_request, or trigger_reset.

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

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

The description provides no guidance on when to use this tool versus the many sibling trigger_* tools, nor any prerequisites or when-not conditions. It only enumerates protocol values, leaving selection between alternatives to inference.

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 the key side effect: the attached charger raises VBUS. The safety warning is valuable, but it omits reversibility, reset requirements, error behavior for unsupported protocols, and whether voltage/current are requested or guaranteed.

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

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

The description is two tightly written sentences with no filler. The purpose is front-loaded, followed immediately by the physical effect and safety warning.

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 hardware-control tool with no annotations, no output schema, and 0% schema description coverage, the definition provides the core purpose and a strong safety warning. It remains incomplete because it does not cover reset semantics, expected return/status behavior, supported voltage ranges, or the meaning of all 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 0%, so the description must compensate. It usefully enumerates valid protocol strings such as qc, qc3, fcp, afc, sfcp, scp, vfcp, tfcp, and ufcs, but leaves the request and current_ma parameters unexplained and gives no voltage range or units context beyond the parameter name.

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

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

The description states a specific verb and resource: requesting a voltage through a named set of fast-charge protocols. It also clarifies the physical effect, raising VBUS on the meter's output, which distinguishes it from status or measurement siblings.

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

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

The warning to disconnect sensitive loads first gives an important usage precondition for this hardware-control tool. However, it does not explicitly say when to use this instead of sibling tools such as trigger_pd_request, trigger_raw, or trigger_reset.

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 well: it discloses the physical side effect (charger raises VBUS) and a genuine safety warning about sensitive loads. It omits permissions, failure behavior for an invalid position, and reversibility, keeping 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?

Two short sentences, front-loaded with the core request semantics and followed by the effect/safety note. No redundant restatement of the name or 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?

For a hardware-mutating, three-parameter tool with no annotations and no output schema, it covers the essential effect and safety warning. However, current_ma semantics and the expected outcome/return behavior are missing, leaving a real gap for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It usefully explains that position is 1-based and that voltage_mv is required for PPS/AVS PDOs, but current_ma is entirely unexplained and no value ranges or units beyond the name hints are given.

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 action (request a PDO at a given position) and its physical effect (raise VBUS on the meter's output). The 'PDO position (1-based)' framing distinguishes it reasonably from trigger_pd_source_caps or trigger_fast_charge, though it never names those siblings 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?

Provides one concrete precondition ('disconnect sensitive loads first') and a conditional hint ('voltage_mv is needed for PPS/AVS PDOs'), which is useful. But it gives no guidance on when to choose this over trigger_fast_charge, trigger_pd_source_caps, or trigger_raw.

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, yet it doesn't say whether this is a safe read/query or has side effects on the charger state, whether results are returned directly or must be read via pd_capture_read/pd_status, or whether it can disrupt an active PD session.

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 key noun up front and zero filler. It could be tightened further only by adding missing routing/result information, not by removing anything.

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-param, no-annotation, no-output-schema tool, the description should at minimum say how the resulting capabilities become available (direct return vs. subsequent read) and any session prerequisite. Neither is covered, leaving the agent unsure what the call accomplishes mechanically.

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 disambiguate; baseline 4 applies. The `pd pdo` hint adds useful framing for what the call maps to.

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 a specific verb ('Ask the charger') and resource ('PD Source_Capabilities'), with the underlying command alias (`pd pdo`) as a concrete anchor. It is distinguishable from siblings like trigger_pd_request (which negotiates) and pd_status, though the distinction is only implied.

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

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

No guidance on when to use this versus trigger_pd_request, pd_status, or the pd_capture_* family. It doesn't state prerequisites (e.g., whether a PD capture session or connection must be active first) or when not to call it.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a real physical effect (raises VBUS on the meter's output) and a safety precaution, which is genuine added value. But it never explains the command string format ('verbatim' from what sheet — hex, ASCII, line ending?), whether unparseable input errors out, or whether prior trigger state persists.

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 primary action front-loaded and the safety caveat after it. Nothing is wasted, though the second sentence arguably belongs in a usage/warning position rather than trailing the purpose statement.

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 two-parameter raw passthrough tool with no output schema and no annotations, the description is reasonably adequate — it names the source of valid commands (ChargerLab's virtual serial port sheet), which is the single most useful piece of context a caller could get. The remaining gap is command syntax and failure behavior, which is notable but not disqualifying.

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. The word 'verbatim' faintly implies `command` is a literal string copied from a vendor sheet, but neither its syntax nor the unit/behavior of `timeout_s` (per-command wait? abort threshold?) is described anywhere. The description leaves the caller guessing on the one required parameter.

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

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

A clear verb+resource: 'Send any trigger command ... verbatim', which positions it as the raw escape hatch among the structured trigger_* siblings (trigger_pd_request, trigger_fast_charge, etc.). It does not explicitly name those siblings or say 'use this only when the structured tools cannot express the command', so the differentiation is inferred rather than stated.

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

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

The second sentence is a hazard warning, not usage guidance. It never says when to prefer trigger_raw over the many structured trigger_* siblings, nor what happens if the command is rejected, nor what prerequisites (device connected, mode entered) must hold. The only actionable instruction is 'disconnect sensitive loads first'.

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 that the trigger returns to its initial state and can be re-opened by the next trigger call, but it does not mention permissions, side effects on other trigger state, or whether the reset is reversible or idempotent.

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

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

The description is a single front-loaded sentence with no wasted words. The core action is stated first, and the parenthetical adds relevant behavioral context efficiently.

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 reset action with no output schema, the description is largely complete: it says what is reset and what happens next. It leaves out some surrounding state and side-effect context, but that is secondary for a tool this simple.

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, so there are no parameter semantics to explain. The empty schema is consistent with the description, and the baseline for zero-parameter tools is 4.

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

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

The description states a specific verb and resource: 'Reset the protocol trigger.' It also explains the resulting state, which helps distinguish it from a permanent close, though it does not name any sibling tool 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?

The description gives no explicit guidance on when to use this tool versus alternatives such as trigger_close or trigger_enter. The parenthetical about re-opening on the next trigger call hints at behavior after reset, but not at tool selection.

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