Loading ToolBench
Teach your AI to play piano and guitar, sing, and listen. 53 MCP tools, 108 annotated songs with redistributable MIDI, 6 engines, a browser cockpit, and an audio inspector. Ships two public tool-use datasets over symbolic and acoustic music.
This server has 6 tools with moderate definition quality. Tool schemas are present and mostly well-formed (JSON Schema with types and descriptions), but parameter descriptions are inconsistent in depth. The tool names follow verb_noun conventions (view_, play_, list_, compose_, auto_, mute_) which is good for LLM parsing. However, several tools lack detailed error handling guidance, and output schemas are not documented. The compose_panel tool has an overly complex schema with nested objects (systems, judges, anchors) that lack sufficient inline documentation. The auto_reharmonize tool accepts a string measure range ('1-8' or 'N') but the description could be clearer about the exact format expected. Overall, definition quality is fair but uneven, some tools are well-described while others would benefit from more actionable parameter docs.
Reharmonize a section of a song using best-of-n sampling with chord proposal and verification
Run a cross-family voice-leading discrimination panel over chord progressions with injected systems and judges
List available songs from the music library with metadata
Mute left or right hand on a playback
Play a song or song excerpt with built-in audio engine
Observe a song's piano roll notation (notation view of MIDI events in a measure range)
compose_panel has excessively nested schema with insufficient documentation. 'systems' and 'judges' parameters lack type definitions and descriptions for their nested object structures. LLMs will struggle to construct valid inputs.
No output schemas documented for any tool. LLMs cannot know what structure to expect in responses, making it impossible to plan downstream tool calls or extract chaining IDs.
list_songs has an empty input schema (no properties) but lacks explanation of what it returns. The description should state the structure of the song list and what metadata fields are included.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
auto_reharmonize accepts 'measures' as a string in format 'N' or 'start-end' but the description does not clarify this format requirement. Should use regex pattern or enum constraints with examples.
mute_hand tool description is minimal (14 words). No explanation of when to use it, what it affects, or whether the mute state persists across calls.
No error handling guidance in any tool description. Tools do not explain what errors can occur, whether they are retryable, or what recovery steps an LLM should take.
compose_panel description does not explain when to use this tool or what 'discrimination panel' means in the context of music analysis. Requires domain-specific knowledge not provided.