Loading ToolBench
MCP server exposing music21 workflows for strict-template MusicXML generation aimed at DAWs.
music21-mcp has well-structured tool definitions with complete JSON schemas and descriptions for all 9 tools. All tools use @mcp.tool(structured_output=True) and declare input parameters with types and descriptions. However, descriptions are often terse (10-50 chars), parameter descriptions lack actionable guidance on constraints and formats, and error handling is not visible in the code. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Output schemas are inferred from Pydantic models but not explicitly documented in tool definitions. Naming is clear and verb-driven (list_, get_, validate_, export_, generate_, analyze_, make_). Composition is sound, tools are single-responsibility and chainable.
Analyze MusicXML part names, measures, tempos, time signatures, and note counts.
Write MusicXML to a file, optionally validating exact part names first.
Generate, validate, and write dark techno MusicXML to a file.
Generate dark minimal/industrial techno MusicXML validated against a strict DAW template.
Return a strict DAW template contract by id.
List available dark techno rhythmic vocabularies.
List built-in DAW template contracts.
Tool descriptions are terse (10-50 chars) and lack actionable context. E.g., 'List built-in DAW template contracts' does not explain WHEN to call this tool or what the agent should do with the result. Descriptions should be 50-200 chars and answer: what does it do, when to use it, what does it return?
Parameter descriptions lack constraint guidance. E.g., 'root' parameter has pattern '^[A-G](#|b)?$' in schema but description only says 'Root note (e.g., F, C#, Bb)', does not state the pattern rule or that only these 21 values are valid. LLMs cannot read JSON Schema patterns; they rely on description text.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. export_to_file and generate_and_export_techno are WRITE operations and should declare destructiveHint=true. This helps agents reason about side effects and retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Generate a tiny MusicXML file containing every exact part name in a template.
Validate that MusicXML <part-name> values match a template exactly.
Error handling is not visible in tool implementations. No try-catch blocks, validation error messages, or recovery guidance in the provided code. If musicxml parsing fails or template_id is invalid, the agent receives a raw exception rather than actionable guidance like 'Invalid template_id. Available templates: [list]'.
Output schemas are inferred from Pydantic models (DawTemplate, MusicXMLAnalysis, TechnoGenerationResult) but not explicitly documented in tool definitions. LLMs cannot see the Pydantic class definitions, they only see the tool description. Document return field names and types in the tool description or via a schema annotation.