Loading ToolBench
MCP server for Ableton Live 12: .als analysis + LOM bridge for assisted track creation and finishing.
ABLE-MCP has 15 well-named tools with clear descriptions and proper input schemas. Naming follows verb_noun convention (als_summary, live_get_tempo, live_set_tempo). All tools have descriptions (avg ~100 chars, within 10-1024 range). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented, responses are inferred from code (e.g., als_summary returns dict, als_list_tracks returns list[dict]). Error handling is minimal: _resolve() raises FileNotFoundError and ValueError, but no recovery guidance. No tool annotations (readOnlyHint/destructiveHint). WRITE tools (live_set_tempo, live_play, live_stop, live_continue) lack confirmation patterns despite having a 'confirm' parameter, the parameter exists but error handling for confirmation is not visible. Missing: pagination for list tools, output schema documentation, error recovery guidance.
Extract MIDI notes from one clip (by track index and clip index) as pitch/start/duration/velocity tuples.
Heuristic suggestions about what looks unfinished in a set: missing instruments, empty MIDI clips, no master limiter, etc.
List clips on one track (by index) or every track (omit track_index).
List all tracks in an .als file with their kind, name, mute/solo state, and device count.
Summarize an Ableton .als file: tempo, time signature, track and clip counts.
Check whether the AbleMCP M4L bridge is running. Returns the bridge's ping payload on success, or guidance on how to install the device.
Output schemas not documented. Code shows responses are dicts/lists (e.g., als_summary returns asdict(analysis.summarize()), als_list_tracks returns list[dict]), but no formal schema is declared. LLMs cannot plan downstream tool calls or extract fields without knowing response structure.
List tools lack pagination. als_list_clips and als_list_tracks return unbounded lists. No limit, offset, or cursor parameters. Large projects could return hundreds of items, exhausting context window.
Error handling lacks recovery guidance. _resolve() raises FileNotFoundError and ValueError with minimal context. No guidance on what to do next (e.g., 'Try live_check_bridge for setup help'). BridgeError/BridgeUnavailable are caught but error messages are not visible in the provided code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Continue playback from the current position.
The currently selected track and scene in Live's view.
Current Live tempo in BPM.
Whether Live's transport is currently playing.
List all tracks in the running Live set with kind, name, mute/solo/arm state.
Start Live's transport. Defaults to confirm=True.
Set Live's tempo (BPM, 20..999). Defaults to confirm=True.
Live transport state: tempo, time signature, playing flag, song position, track count.
Stop Live's transport. Defaults to confirm=True.
WRITE tools (live_set_tempo, live_play, live_stop, live_continue) have a 'confirm' parameter but no visible confirmation-request pattern. Parameter defaults to True, which could allow unintended state changes if LLM omits it. No dry-run or explicit confirmation flow.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot distinguish safe (read-only) tools from risky (write) tools without explicit annotations.