Loading ToolBench
An MCP bridge for exact, read-back-verified Bitwig Studio control, with a local status dashboard
Strong tool definitions with comprehensive schemas and clear descriptions. All 18 tools have explicit input schemas with type constraints, enums, and ranges. Descriptions are detailed (avg 120+ chars) and explain WHAT, WHEN, and consequences. Naming follows verb_noun convention (bitwig_*). Key strengths: parameter validation (minLength, maxLength, min/max for numbers), risk classification (READ_ONLY, WRITE, DESTRUCTIVE), and readback verification patterns. Gaps: no parameter descriptions visible in schema (only tool-level descriptions), no output schemas documented, limited error recovery guidance, no tool annotations (readOnlyHint/destructiveHint).
Search Bitwig Studio's native action registry by action id, name, or menu text.
Record existing launcher clips into Bitwig's Arranger across exact requested beat regions, merging contiguous regions and restoring the project tempo afterward.
Create or replace a launcher MIDI clip on one exact instrument track and write its complete note content.
Create an empty Bitwig track without opening the Browser or loading any preset.
List Arranger cue markers, or create/update a named marker set at exact beat positions with Bitwig readback verification.
Delete one exact track. The supplied name must still match, preventing index drift mistakes.
No parameter-level descriptions in visible schema definitions. Tool descriptions explain intent, but individual parameters (e.g., 'panNormalized', 'slotName', 'stepSize') lack inline documentation. LLMs cannot infer parameter semantics from names alone.
Output schemas not documented. Tools return structured data (e.g., bitwig_tracks returns track list with index/name/type/state), but response format is not formally specified. Agents cannot plan downstream calls without knowing what fields are returned.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk classification exists in metadata (READ_ONLY, WRITE, DESTRUCTIVE) but is not exposed via MCP tool annotations. Clients cannot automatically flag dangerous operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
List devices on one exact track. This reads the device chain directly; it does not inspect presets.
Invoke one exact Bitwig action id previously returned by bitwig_actions.
Move one verified top-level device into another device's native nested chain and verify the resulting parent and child chains.
Search Control Deck's local inventory of installed VST3, VST2, Audio Unit, and CLAP plug-ins without opening Bitwig's Browser.
Refresh Control Deck's read-only plug-in inventory after installing or removing audio plug-ins.
Rename one verified Bitwig track without changing its audio or MIDI routing.
Open Bitwig's native Save to Library flow for one verified device and optionally confirm its prefilled name without mouse automation.
Set exact mixer values on one verified track and read the resulting state back from Bitwig.
Check Control Deck Bridge, Bitwig, the current project, transport, and current selection.
Read peak signal activity captured for every Bitwig track, or reset the captured maxima before a playback test.
List Bitwig tracks with exact names, positions, safety references, types, and states.
Read or control Bitwig transport. Tempo changes are read back before success is reported.
Limited error recovery guidance. Tool descriptions state WHAT they do but rarely explain what to do if they fail. E.g., bitwig_invoke_action could fail if actionId is invalid, but no guidance on how to recover or which tool to call next.
No confirmation/dry-run pattern for destructive operations. bitwig_delete_track and bitwig_arrange_launcher_clips modify state irreversibly. No dry-run or confirmation step to prevent accidental data loss.