trigger_raw

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.