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 key behavior: values persist to the supply's EEPROM, a firmware version gate applies, and reset=true restores vendor defaults. It stops short of saying whether supplied colors merge with or overwrite existing element settings, and doesn't state error or connection 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?

Extremely dense and front-loaded: action, firmware gate, persistence, value formats, element list, then reset semantics. The telegraphic 'colors: {...}' notation is terse but readable; no sentence 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?

For a 3-parameter nested-object tool with no output schema, the definition covers formats, valid keys, persistence, firmware requirement, and the reset path. Only the merge-vs-replace semantics and confirmation of the response are missing, which are minor given no output schema exists.

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 only 33%, and the description compensates well: it gives the accepted color value syntaxes (#RRGGBB, 0xRGB565, or name) and enumerates all ten valid element keys, which the schema does not. The third parameter, max_wall, is documented in the schema itself, so nothing major is left 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?

States a specific verb and resource ('Set colours of the Digital screen'), which is clearly distinct from generic siblings like set/output/status. It does not explicitly name a sibling alternative, but the resource specificity is enough for an agent to route correctly.

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 firmware prerequisite (>= 1.4.4) and the reset=true default-restore path give implied usage context, but there is no explicit when-to-use vs when-not guidance and no mention of alternatives such as `set` or `output`. Usage is inferable 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?

readOnlyHint=true already tells the agent this is a safe read, but the description adds genuine value by disclosing what the response contains, including failure events like 'link lost' and a summary once the job ends. It says nothing about behavior for an unknown/invalid job identifier or whether it blocks on a running job.

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

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

One sentence, front-loaded with the core purpose and the default behavior, with the return-field enumeration packed into a compact colon list. The '(link lost ...)' ellipsis is slightly loose but overall there is no wasted wording.

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

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

For a read-only, single-optional-parameter tool with no output schema, the description does a fair job of sketching the returned state, which substitutes for a missing output schema. However, the undefined 'job' parameter and the absent differentiation from sibling status tools leave clear 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% and the single 'job' parameter has no description in the schema. The parenthetical '(default: the latest)' hints at omission semantics but does not explain what the parameter accepts (ID vs name vs index) or how to obtain it, so the description fails to compensate for 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 ('State of a log or sequence job') and even enumerates the returned content (running, started event, last sample/step, events, summary), so the agent knows this is a read of job progress. It does not explicitly distinguish itself from the sibling 'status' or 'output' tools, which keeps it from 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?

The only usage hint is '(default: the latest)', which describes omission behavior rather than when to choose this tool. There is no guidance tying it to log_start/sequence_start/job_stop or clarifying how it differs from the sibling 'status' tool.

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 stopping is 'clean', that the default is every running job, that a summary is returned, and that a sequence's output is switched off unless started with end: keep. It does not mention permissions, irreversibility, failure behavior, or what 'cleanly' entails, leaving notable gaps for a stop 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?

The definition is two tightly written sentences with the core action and default scope front-loaded. The parenthetical and the end: keep exception add necessary detail without waste, though the phrasing is slightly dense.

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 annotations, no output schema, and no schema descriptions, the description covers the core action, default scope, and one important side effect. It remains incomplete regarding parameter format, permissions, error behavior, and the exact effect of 'cleanly' stopping a job.

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 schema gives no meaning for the single 'job' parameter. The description partially compensates by indicating that it refers to a log or sequence job and that omitting it targets every running job. It still does not explain the expected format or how to identify a specific job.

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

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

The description uses a specific verb and resource: stopping a log or sequence job. It distinguishes between the two job types and states the default scope (every running job), so an agent can identify the operation without opening the schema. It stops short of differentiating itself from siblings such as job_status.

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

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

Usage is implied by 'Stop' and the default behavior when no job is supplied. However, the description does not say when to prefer this over siblings like job_status or status, nor does it state when not to use it or any 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 at all, the description carries the full behavioral burden and does well: it discloses that logging is asynchronous, that other tools keep working meanwhile, that a job id is returned, and that a job_stop call is required to end it. Gaps remain around file overwrite behavior, error handling, and whether the job survives until 'duration' elapses.

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

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

Two sentences, front-loaded with the action and the column set, then the job lifecycle. Nothing is redundant and the 'other tools keep working meanwhile' clause earns its place by disclosing the non-blocking behavior.

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 four-parameter background job tool with no output schema and no annotations, the description covers the return value (job id), the follow-up workflow, and the non-blocking property. It is nearly complete, with only edge cases like overwrite semantics or default file collision left unspecified.

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 75%, so the schema already explains 'out', 'every', and 'duration'; the description mentions CSV/JSONL format but only restates what the enum in the schema shows. It adds no new meaning for the four parameters, so the baseline of 3 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 opens with a specific verb and resource: 'Log the status to a CSV (or JSONL) file in the background,' and even enumerates the recorded columns, so the agent knows exactly what the tool produces. It does not differentiate against non-job siblings such as 'watch' or 'status', which may overlap in monitoring intent.

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 a clear lifecycle: 'Returns a job id; follow with job_status, end with job_stop,' which tells the agent what to do before and after invoking the tool. It does not state when to prefer this over alternatives like 'watch' or a one-off 'status' read, so the when-not guidance is absent.

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 soft-start wait (~1.1 s, ~1.5 s total), the DELAY/REV >20 s early-return behavior, the immediate shutdown when a bench voltage limit is exceeded (UNSAFE_OPERATION), and that the actual voltage is whatever the supply currently enforces. It does not describe the call's return value or authentication requirements.

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

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

The description is front-loaded with the on/off action and then layers timing, safety, and caution details. It is dense but every sentence carries operational value; parenthetical asides are compact and relevant rather than wasteful.

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 and no output schema, the description covers timing, safety limits, and preconditions well. What remains thin is the return value after the call completes and any permission or error semantics beyond UNSAFE_OPERATION, so it is strong 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 75%, so the schema already documents wait, max_wall, and wait_timeout. The description adds timing context that maps to the wait behavior (soft start + DELAY/REV + 1.5 s) but does not independently explain each parameter's syntax or edge cases. Baseline 3 is appropriate.

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: switching the output on or off, with scope details like soft-start timing and DELAY/REV behavior. It does not explicitly name sibling tools or contrast itself with them, though it references status.vout_v, which gives partial differentiation.

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

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

It gives clear usage context and explicit exclusions: check what is connected before switching on, and do not use while the supply's settings menu is open. It also describes the bench-voltage-limit behavior that triggers UNSAFE_OPERATION. It stops short of naming alternative tools for adjacent operations.

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

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

No annotations are present, so the description carries the behavioral burden; it explains that omitted fields default to 0, that cut-current turns output off after about 6 seconds below the threshold, that cut-time is based on accumulated on-time, and when select is refused. It does not describe the success response or whether writing a list affects other lists, so it is not exhaustive.

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 three dense sentences, front-loaded with the operation and field semantics, and the parentheticals are compact. It is appropriately sized for a 9-parameter tool, though the select-refusal clause is somewhat compressed.

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 9-parameter write tool with no annotations and no output schema, the description covers list semantics, defaults, select behavior, and the Chinese-screen precondition. It leaves return/confirmation behavior and some error semantics to inference, but it is substantially 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 high at 78%, with units and ranges already documented, and the description adds meaning for cut_current (0 = off), cut_time (accumulated on-time), select (sent after the values and subject to refusal), and omission defaults. It does not add detail for max_wall beyond the schema, which is acceptable.

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 write operation ('Write one of the five parameter lists') and scopes it to the Chinese screen, enumerating the values that the list contains. It makes clear that this is a distinct resource (lists 0..4) rather than a general set operation.

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 that the lists are used by the Chinese screen and that the registers act only while that screen is shown, and it gives select refusal conditions. It does not explicitly route the agent between this tool and siblings such as set, so alternative selection guidance is the main 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?

readOnlyHint=true already tells the agent this is safe, so the description's real contribution is the Bluetooth exclusion and the hidden stateful effect: the answering port is cached for later calls. That caching behavior is the kind of side effect an agent needs and cannot get from the annotations, though nothing is said about latency per port or failure when no device responds.

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 no filler; the core action comes first and the caching consequence follows. Every clause carries information: what is listed, what is probed, what is skipped, and what persists.

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-optional-parameter discovery tool with no output schema, this covers the action, the probe target, the exclusion, and the stateful side effect. It falls short only on edge behavior such as returning an empty list or timing out when no PP300S answers.

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

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

Schema description coverage is 100% and max_wall is already documented with bounds and a default in the schema. The description adds no extra meaning about the timeout, so the baseline of 3 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+resource: lists serial ports and probes each USB one for a PP300S status, with Bluetooth ports excluded. An agent can tell this is a discovery/probe tool rather than a control tool like 'set' or 'output', though no sibling is named to sharpen the 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?

The sentence 'The port that answers is remembered for later calls' implies this is the first step before using set/output/status, but the guidance is indirect. There is no explicit when-to-use statement and no when-not or alternative mentioned, such as what to do if you already know the port.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces that with 'Never changes a setting' while adding real behavioral detail: a bad-checksum frame is ignored rather than aborting the test. It does not say how long the run may take or whether a failure is reported as a result or an error, which matters for a multi-check probe.

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 read-only framing, then the checklist, then the non-mutation guarantee. Every clause carries information and nothing is repeated.

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, the description must convey behavior, and it does a good job of listing the checks and the bad-frame tolerance. The remaining gap is that it never indicates the shape of the outcome (per-check pass/fail versus a single verdict), which an agent would want before parsing 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 coverage is 100% and the single 'max_wall' parameter already documents its range and 30 s default, so the schema carries the load. The description adds nothing about the time limit or what happens when it is exceeded, which is the baseline case for fully documented parameters.

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

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

The description names the resource and enumerates exactly what is verified (port, status replies, checksums, latency, voltage/temperature plausibility, power = V x I), so an agent knows this is a diagnostic routine rather than a status read. It never explicitly contrasts itself with the sibling 'status' tool, so it stops short of full sibling differentiation.

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

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

There is no statement of when to run this versus the closely related 'status' or 'watch' tools; the only implied guidance comes from the word 'checks'. The closing 'Never changes a setting' is a safety note rather than a usage rule, so the agent is left to infer selection criteria.

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

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

With no annotations, the description carries the behavioral burden well: it discloses background execution, output switching, default end=off behavior on completion or job_stop, repeat semantics, optional logging, and bench-limit checking before each step. It still omits error handling, concurrency behavior, and how the background job is identified or monitored.

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 compact and front-loaded, stating the core action first and then covering step format, file input, repeat, end behavior, logging, and safety checks. Every segment carries useful information without redundant 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 moderate-complexity background job tool with no output schema and no annotations, the description covers core execution and side effects but leaves gaps around return values, job monitoring, error behavior, and interaction between steps/file. It is adequate but not fully complete for an agent to call and manage the operation 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 only 33%, but the description adds important meaning beyond the schema: the shape and semantics of steps, the CSV-like file format, repeat=0 meaning until job_stop, end=off vs keep, and optional log behavior. It does not explain the `every` parameter or clarify whether `steps` and `file` are mutually exclusive.

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

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

The description clearly states the specific action and resource: run timed steps in the background, with each step setting VSET/ISET and switching output on. It is distinguishable from a simple set/output operation by its sequence semantics, but it does not explicitly name or contrast with sibling tools such as set or output.

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 by describing timed steps, repeat cycles, and end behavior, including repeat=0 until job_stop. However, there is no explicit when-to-use guidance versus alternatives like set, output, or watch, nor are exclusion conditions 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 supplied, the description carries the full burden and does so well: it discloses the safe application order (output-above protections, setpoints, then output-dependent protections), the wait-for-settled behavior, explicit refusal conditions (bench limits, OVP margin, OVP/OCP at current terminal values, OPP/OTP at present power/temperature), and the UNSAFE_OPERATION/NOT_APPLIED error codes.

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?

Everything is crammed into a single dense paragraph, and key clauses like 'OVP closer than max(0.2 V, 1.5 %) above VSET (given now or as sent last)' are compressed to the point of being hard to parse. It also restates the OVP-vs-VSET margin rule that the schema already documents, so some content does not earn 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?

For a mutation tool with 11 optional parameters and no output schema, it covers ordering, safety refusals, screen restrictions, and post-switch-on verification (referencing vout_v). It stops short of describing the success return shape or which fields confirm each applied setting, which matters given there is no output schema.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds value by explaining cross-parameter relationships (OVP margin relative to VSET 'given now or as sent last', the wait flag's settling semantics) that the per-parameter schema text states only in isolation. It does not say whether omitted parameters are left unchanged, which is the main semantic gap for an 11-param partial-update tool.

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

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

The description uses a concrete verb-plus-resource framing ('Send settings in a safe order') and enumerates the actual fields involved (VSET/ISET/OVP/OCP/DELAY/REV), so an agent can tell this configures power-supply setpoints and protections. It does not explicitly contrast itself with siblings like 'output' or 'param_list', leaving that differentiation implicit.

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 real conditional guidance: with the output on, a VSET the output does not follow yields NOT_APPLIED; with the output off nothing can be verified, so check vout_v after switching on. What's missing is explicit routing to alternatives ('use output to enable the rail first'), so the agent must infer sibling usage.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely non-obvious behavior: the supply cannot report its configured settings, the front panel may have changed them, and last_sent reflects values this tool previously sent rather than device truth. That caveat materially changes how an agent should interpret results. It stops short of stating failure modes or how stale last_sent can become.

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 dense sentence with no wasted words, and the measured values are front-loaded. However, it is a sentence fragment with no leading verb phrase, and the parenthetical caveats are packed mid-string rather than leading with the tool's action.

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, the description carries the full burden of explaining return values and does so thoroughly, including which fields are readings versus cached settings. The notable gap is the undocumented max_wall timeout interaction with a blocking status read, which matters for a device that may be slow to respond.

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

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

Schema description coverage is 100% for the single max_wall timeout parameter, so the schema already carries its meaning. The description adds nothing about the call timeout or blocking behavior, which is acceptable given full schema coverage but is not additive.

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 is a bare list of field names ('vout_v, iout_a, pout_w, vin_v, temp_c, mode, output_on...') rather than a verb+resource statement; the reader infers 'report measured readings and state' from the field semantics and the title. It does separate itself from the write-oriented siblings (set, output, sequence_start), but it never explicitly frames the tool as a read of current state, leaving mild ambiguity.

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 when-to-use guidance and no alternative named, despite siblings like watch, job_status, param_list, and ports that could plausibly overlap. The only implicit cue is that this reports measurements rather than settings, which an agent must deduce rather than being told.

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 load. It does disclose the return payload (min/max/mean of vout/iout/pout/vin/temp, modes seen, Ah/Wh, last sample) and that sampling spans a duration, which is genuinely useful. It says nothing about blocking behavior, whether the device must be outputting for the call to succeed, whether samples can be dropped, or what happens when `seconds`/`count` exceed limits.

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

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

Two sentences, both earning their place: the first front-loads the mechanism and the full result shape, the second routes to the alternative. The statistics list is long but necessary because no output schema exists, so it substitutes for structured return documentation rather than adding noise.

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 steps up by enumerating the aggregate statistics returned and noting the last sample is included, which is exactly what an agent needs to decide whether to parse or re-poll. The remaining gap is failure and truncation behavior for long or interrupted sampling runs.

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 75%, with `every`, `seconds`, and `max_wall` documented inline but `count` undocumented. The description compensates by explaining that `count` is an alternative to `seconds` for specifying sample quantity, a relationship the schema alone does not express. Only `max_wall`'s role as a hard call timeout is left to the schema.

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

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

The description names a specific action and scope: poll the status at interval `every` for `seconds` (or `count` samples) and return aggregate statistics plus the last sample. That is concrete enough to separate it from log_start, which it explicitly names. It does not, however, distinguish itself from the sibling `status` tool, leaving one ambiguity in the tool set.

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 alternative and the condition that selects it: 'For longer runs or a file use log_start.' The implication is that this tool is for short, bounded sampling windows, which is reasonably clear. It offers no exclusion against the sibling `status` tool, so an agent has to infer which of the two to reach for on a single check.

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