Loading ToolBench
Professional multi-interface music analysis server built on music21, providing MCP Server, HTTP API, CLI tools, and Python library interfaces for comprehensive music analysis and composition.
The music21 MCP server demonstrates moderate definition quality with both strengths and notable gaps. All 5 tools have names starting with action verbs (chord_analysis, counterpoint_generator, delete_score, export_score, harmonization) and structured input schemas with typed parameters. However, descriptions vary significantly in depth and actionability, and critical parameter-level documentation is inconsistent. The tool signatures are well-formed but descriptions often lack the specificity needed for LLM tool selection and error recovery guidance. Output schemas are not documented in the visible code.
Tool for analyzing chord progressions with Roman numeral analysis
Counterpoint generator providing all five species of counterpoint with strict Fux rules or relaxed modern rules, multiple voice support (2-4 parts), above or below cantus firmus, and rule violation checking with explanations
Tool for deleting scores from memory
Tool for exporting scores to various formats
Intelligent harmonization tool providing analysis of melodic contour and implied harmony, multiple harmonization styles (classical, jazz, pop, modal), voice leading rule compliance, constraint support (diatonic only, specific progressions, etc.), and explanations for harmonic choices
delete_score lacks actionable description. Description states only 'Tool for deleting scores from memory' (38 chars), insufficient context for tool selection or understanding consequences. Does not warn of irreversibility or explain when to use vs other removal patterns.
No output schemas documented for any tool. Code does not show what fields/structures are returned from chord_analysis, counterpoint_generator, export_score, or harmonization. LLMs cannot plan downstream calls or extract required data without knowing return types.
delete_score accepts '*' to delete all scores but description does not warn of this destructive capability or suggest confirmation flow. Pattern for confirmation-request not implemented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
counterpoint_generator parameter 'custom_rules' is an array with no description of valid rule names, format, or constraints. LLM will hallucinate rule values. Parameter descriptions state only 'List of specific rules to enforce if rule_set is \'custom\'', insufficient detail on valid rule syntax.
harmonization tool 'constraints' parameter is an array but valid constraint names are not enumerated or described (e.g. 'diatonic_only', 'no_parallels' are mentioned in tool description but not in parameter definition). Without formal constraints, LLM will guess or reuse examples literally.
export_score 'output_path' parameter described as 'Optional custom output path' but does not specify: allowed directory structure, naming conventions, file existence handling (overwrite vs error), or format-specific path requirements. LLM cannot safely construct paths.
chord_analysis 'segment_length' parameter lacks units clarity in description, states 'Segment length for chordify (in quarter notes)' but does not specify valid range, whether fractional values are allowed, or what happens if the value exceeds score length.
All tools reference 'score_id' parameter but do not explain how scores are created, stored, or identified. No discovery tool (e.g. list_scores, get_score_info) documented to help LLM understand the score lifecycle. Dependency hint missing: 'Call create_score or import_score first.'
No error handling guidance in tool descriptions. Tools do not document retryable vs fatal errors, what to do if score_id is not found, or whether operations are idempotent. Pattern recovery-guide not implemented.