Loading ToolBench
HTTP API for Claude Code / OpenCode integration with FL Studio beat making and generative AI music tools. Provides music generation, analysis, and FL Studio control capabilities.
This server exposes 31 music generation and audio processing tools. While schemas are present for most tools, the implementation reveals significant quality issues: (1) Many tool descriptions are generic and lack actionable guidance for LLM selection. (2) Parameter descriptions are sparse or missing entirely. (3) Output schemas are not documented, we cannot verify what structure clients should expect. (4) Error handling is not evident in the code samples provided. (5) Tool names are mostly verb_noun, which is good, but some are ambiguous (e.g., 'generate_melody' appears twice with different signatures). (6) No evidence of permission gating, secret injection, or audit trails. The server appears to be a proof-of-concept or hobby project rather than production-grade tooling. Conservative scoring reflects these gaps.
Apply 3-band parametric EQ
Analyze reference audio for loudness, peak, and frequency content
Apply chorus effect
Apply dynamic range compressor
Apply tape delay effect
Detect BPM from audio using autocorrelation
Detect key from audio chromagram analysis
Apply filter to audio samples
Output schemas not documented. No visible documentation of what tools return, forcing LLMs to guess at response structure. This breaks tool chaining and makes it impossible for clients to parse results reliably.
Many parameter descriptions are missing or trivial. Parameters like 'root', 'scale', 'length', 'frequency', 'duration' lack context on their meaning, valid ranges, or units. This violates the pattern that 'every parameter needs a description explaining what it controls.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Find scale from notes
Generate bass line
Generate bass line with multiple pattern types
Generate chord progression for style and length
Generate chord progression
Generate drum pattern with full rhythm data
Generate drum pattern (kick, snare, hihat)
Generate melodic phrase
Generate melodic phrase with configurable range and density
Generate a complete music track with drums, bass, melody, and chords
Get all notes in scale
Generate melody in key using LSTM-style neural network
Generate notes from Markov chain trained on sequences
Create new pattern in FL Studio
Open piano roll editor in FL Studio
Generate waveform over duration with advanced oscillator
Start playback in FL Studio
Enable recording in FL Studio
Apply convolution reverb effect
Save FL Studio project
Stop playback in FL Studio
Transfer musical style between genres to input melody
Suggest mix settings based on reference audio analysis
Duplicate tool names with different signatures: 'generate_melody' appears in both flstudio_mcp_server_v2.py (with note_range, rhythm_density) and advanced_ai_composer.py (different params). LLMs cannot disambiguate and will select the wrong one.
Tool descriptions lack 'when to use' guidance. Descriptions state WHAT a tool does but not WHY an LLM should choose it over similar tools. For example, 'generate_drums' vs 'generate_drum_pattern', no guidance on which to use when.
Control plane tools (play, stop, record, new_pattern, open_piano_roll, save_project) have minimal descriptions (20 chars or less). No documentation of what state they modify, whether they are reversible, or what preconditions they require.
No evidence of error handling or recovery guidance. Code samples show no try-catch blocks, error messages, or guidance on what to do if a tool fails. Pattern 'recovery-guide' requires errors to tell the LLM what to do next.
Parameter naming ambiguity: 'root' is used to mean MIDI note number in some contexts (generate_bass, range 24-60) but as a pitch name in others (get_available_notes, type string). No consistent convention; forces LLMs to reason about implicit type conversions.
Generic tool names: 'EQ' is a single-letter acronym that LLMs may struggle to parse. Should be 'apply_eq' or 'apply_parametric_eq'. Similarly, single-word names like 'play', 'stop', 'record' lack context about what system they operate on.
No permission gating or scope declarations. Tools like save_project and new_pattern modify FL Studio state without any visible permission checks or audit trails. No pattern:scope-declaration or pattern:audit-trail implementation.
No evidence of idempotent operation handling. Destructive tools like save_project and record have WRITE/REVERSIBLE risk but no dry-run, confirmation, or idempotency guarantees. Pattern 'idempotent-operation' and 'confirmation-request' are not implemented.