Loading ToolBench
MCP server for controlling Ableton Live 11 on Windows, enabling music generation, device management, automation, and session control via the Model Context Protocol
This server has substantial definition quality gaps that prevent confident production use. Of 18 tools, 15 are music generation/device manipulation functions with adequate schema structure but poor descriptions (under 100 chars, mostly generic). Two search tools are well-described but lack output schema documentation. Critical issues: (1) No output schemas documented for ANY tool, LLMs cannot predict return structure; (2) Descriptions are too brief and generic for complex tools like 'generate_chord_progression_advanced' (171 chars) and 'generate_bassline_advanced' (168 chars) which don't explain WHEN to use them vs similar tools or what makes the 'advanced' variant different; (3) Parameter descriptions lack dependency documentation (e.g., how does 'progression' format differ between 'pop_1' and 'I V vi IV'?); (4) No error handling guidance in any tool; (5) Tools like 'load_drum_kit' expose 'rack_uri' which appears to be an API object reference, unclear if this should be user-friendly or opaque; (6) Multiple generation tools (chords, bass, strings, brass, woodwinds) are near-duplicates with identical parameter sets, naming is verb-noun correct but descriptions don't clarify the musical distinction.
Advanced bassline generator using music theory to follow chords. progression: "pop_1" | "I V vi IV" | None mood: "romantic", "jazz", "blues", etc. style: "walking", "root", "pulse", "arpeggio", "syncopated"
Advanced brass section generator.
Generate chord progression from preset.
Advanced chord progression with 176+ progressions, voice leading, and flexible timing. progression: "pop_1" | "I V vi IV" | None mood: "romantic", "hopeful", "dark", "mysterious", "triumphant", etc. total_bars: Target length (4, 8, 12, 16) - adjusts chord timing to fit rhythm_style: "whole", "quarter", "syncopated", "arpeggio" voice_lead: If True, use inversions for smooth transitions
Generate drum fill variation.
Generate drum pattern from Drummer preset.
No output schemas documented for any of the 18 tools. LLMs cannot predict what fields to expect in responses, forcing them to parse responses blindly and preventing composition of tool chains (e.g., generate_chord_progression output cannot feed to generate_bassline because return structure is unknown).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Generate complete drum section with pattern and fills.
Generate rhythmic pattern.
Generate rhythmic accompaniment pattern.
Advanced string section generator using music theory.
Advanced woodwinds section generator.
List loadable devices from cache or Live.
Load clip by name.
Load drum kit into rack.
Load sample by name (best effort).
Load Sampler and set sample.
Load Simpler and set sample.
Search for available devices/presets by name. Returns names for discovery only - use search_and_load_device to actually load.
Descriptions for 13 of 18 tools are generic or underdescriptive (50-75 chars), lacking actionable guidance. Example: 'Generate drum pattern from Drummer preset.' does not explain WHEN to call this vs generate_drum_fill or generate_drum_section, what parameters control the output character, or what 'Drummer preset' means in context. This violates the 50-200 char LLM-optimized baseline.
Seven near-duplicate generation tools (generate_strings_advanced, generate_woodwinds_advanced, generate_brass_advanced, generate_chord_progression_advanced, generate_bassline_advanced, plus the non-advanced chord and drum tools) have identical or near-identical parameter signatures and minimal descriptive differentiation. LLMs cannot reliably select the correct tool without explicit guidance on the musical/instrumental distinction. Violates the 'When should the LLM call it instead of a similar tool?' requirement.
Parameter 'rack_uri' in load_drum_kit and 'kit_path' in load_drum_kit expose low-level API references that are unclear to LLMs. No explanation of whether these are file system paths, URIs, or opaque handles. Should either (1) accept human-friendly names and resolve internally, or (2) provide discovery tool to list valid URIs/paths with clear semantics.
No error handling guidance in any tool. Tools return JSON or error strings without categorization (retryable vs user-fixable vs fatal). LLMs cannot determine recovery strategy on failure.
Parameter dependency relationships are not documented. Example: 'progression' parameter can be either a preset string like 'pop_1' or a music theory notation like 'I V vi IV', but no description clarifies which format applies, when each is valid, or how the tool handles invalid combinations with 'mood', 'scale', or 'key'. Undocumented dependencies cause silent misuse.
Parameter constraints are incomplete. Example: 'key' parameter defaults to 'C' but no enum is provided listing valid musical keys (C, C#, D, D#, E, F, F#, G, G#, A, A#, B?). LLMs cannot validate input and may hallucinate invalid key values. Same issue with 'scale' (major, minor, pentatonic, dorian, etc.?) and 'style' (walking, root, pulse, arpeggio, syncopated for bassline but what for strings/brass?).