Loading ToolBench
Two-layer MCP input engine: a frontier model orchestrates, two small local models chain the inputs.
Strong tool design with clear naming (voltage_* prefix), comprehensive descriptions (avg 180 chars), and complete input schemas with types. All 12 tools have descriptions and parameter schemas. Tool names follow verb_noun pattern well (capture, observe, validate, run, stop, steer, diagnose). However, output schemas are not documented in the visible code, responses are described narratively but lack formal JSON Schema definitions. Error handling descriptions are present but could be more prescriptive about recovery steps. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are well-applied.
Measure the latency of the input path and the vision loop. Runs a short sequence of timed inputs and measurements to establish baseline latency for this machine. Returns the measured values and recommendations for tuning reflex_hz and settle_ms. Call this once per machine before tuning a Playbook.
Take a screenshot and return it to you directly. Use this to see the screen yourself -- before writing a Playbook, to pick coordinates for probes and click regions, or to work out why a run went wrong. This does not involve the local vision model. `region` is [x, y, width, height] in desktop pixels; omit for the whole desktop.
Analyze a failed run and suggest fixes. Examines the journal and observations from a run to identify why it did not achieve its goal. Returns a diagnosis and specific suggestions for fixing the Playbook or the environment.
Check that everything needed for a run is present and working. Reports the session type, input-device permissions, which capture backends work, detected screen geometry, GPU memory versus the selected model profile, and whether both model backends respond. When something is missing it returns the exact command to fix it. Call this before the first run on a machine.
Get the journal of a run. Returns the complete log of decisions, observations, and inputs for a run. Useful for debugging and understanding what happened during execution.
Output schemas not documented. Tool descriptions explain what is returned narratively (e.g., 'Returns the parsed state machine, any parse errors...') but no formal JSON Schema definitions are visible for response structures. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response schema.
Error recovery guidance is implicit. Tools like voltage_run and voltage_steer describe what can go wrong but do not explicitly state 'if X fails, call Y' or categorize errors as retryable vs fatal. Agents cannot self-correct without explicit recovery paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Run one vision pass and return grounded elements in screen coordinates. `watch` is the closed vocabulary the vision model may use -- it can only report labels from this list, so name the things your Playbook's guards will test for. Use this to check that the vision model can actually find what a state depends on before committing to it in a Playbook. If an element does not come back here, a `sees(...)` guard on it will never fire.
Return everything needed to author and iterate on a run. Call this before your first Playbook. Sections: loop **the learning loop** -- how to go from a failed run to a working one, and what each failure mode actually means. Read this second. control **continuous control** -- probes, latched holds and interpolated bursts: the layer that runs at ~20 Hz between decisions. Read this before driving anything with timing in it, including any game. bursts the burst cookbook: how to chain inputs well, timing rules, ready-made patterns for desktop and for games, and the antipatterns that waste cycles. Read this if bursts are coming out one action at a time. burst the raw burst syntax playbook the state-machine JSON schema guards expression functions for transitions and reflexes example a complete working Playbook
Start a Playbook run. Creates a new session and begins executing the Playbook. Returns the run_id immediately; use voltage_status to monitor progress. The run continues until the Playbook reaches a terminal state, a guard triggers the safety policy, or voltage_stop is called.
Get the status of a run. Returns the current state, the last observation, any errors, and statistics. If run_id is omitted and exactly one run is active, returns its status. If no run_id is given and multiple runs are active, returns an error listing them.
Send a burst of inputs during a run. Injects a burst into the active run without changing the Playbook. Useful for recovering from unexpected screen states or testing input sequences. The burst is validated against the burst grammar before sending.
Stop a run. Gracefully stops the Playbook execution. The run transitions to a stopped state and no further inputs are sent. Returns the final status.
Parse and validate a Playbook without running it. Returns the parsed state machine, any parse errors, and whether the grammar is supported by the configured backend. Use this before the first run of a new Playbook to catch mistakes early.
Parameter constraints not fully specified. voltage_capture.max_width defaults to 1280 but no min/max bounds documented. voltage_observe.max_elements defaults to 6 but no range specified. voltage_calibrate.duration_s has no min/max. Unbounded numeric parameters invite invalid LLM inputs.
Playbook parameter type is 'object' with no schema. voltage_run, voltage_validate_playbook, and voltage_steer all accept a 'playbook' parameter typed as object but with no nested schema definition. LLMs cannot validate playbook structure before submission.
Burst parameter type is 'object' with no schema. voltage_steer accepts a 'burst' parameter typed as object but with no nested schema definition. voltage_reference returns burst syntax documentation but the tool itself does not enforce schema validation at the parameter level.