Loading ToolBench
MCP server for AI-driven music production in REAPER via file-based IPC with a Lua bridge
The server has 8 tools with basic naming, descriptions, and parameter schemas. However, several critical issues limit quality: (1) Tool descriptions are present but brief (10-150 chars), falling below the 194-char production baseline; (2) Parameter schemas exist in JSON but lack depth, descriptions are minimal and some constraints (e.g., valid reference values for analyze_loudness, semitone range for take_set_pitch) are documented only in text, not as formal enums or min/max; (3) No error handling or recovery guidance visible in tool definitions; (4) No output schemas documented; (5) Destructive operations (wipe_all_midi, compose_arrangement with clear_existing) lack confirmation or dry-run patterns; (6) The compose_arrangement tool accepts 'shorthand' syntax ('3|D3:2.5:65') that is poorly documented and non-standard for LLM reasoning. The tool definitions are functional but fall short of production-grade quality for agent reasoning. Schema inspection shows parameters exist but lack richness, e.g., 'reference' parameter in analyze_loudness has no enum declaration despite having a fixed set of valid values (streaming/spotify/apple_music/youtube/broadcast/cinema/club).
Measure integrated loudness (LUFS), true peak, loudness range, and crest factor.
Dump current MIDI data: per-track notes, CCs, timing stats.
Batch-insert MIDI from shorthand or JSON — guarded for small edits only.
List all tracks with detected VSTi names and item counts.
Slice an item at a list of absolute project-time positions.
Slice an audio item at every detected transient.
Pitch-shift a take by N semitones (no time change).
String-as-JSON parameters (item_split_at_positions, wipe_all_midi, analyze_score, compose_arrangement use 'tracks' or 'positions' as JSON-in-string). Forces LLM to serialize JSON into strings, error-prone and non-standard. Should be array or object types in JSON Schema.
compose_arrangement accepts undocumented shorthand DSL ('3|D3:2.5:65|cc1:0-8:35-55') alongside formal JSON. This dual-format design is unmaintainable, ambiguous for agents, and violates single-responsibility. Should use JSON Schema only with explicit field types.
No output schemas documented for any tool. Agents cannot infer return structure (field names, types, nesting). Required for downstream tool chaining and context efficiency per pattern:tool.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Wipe all MIDI items and reset composition state. Tracks can compose again after.
Destructive operations (wipe_all_midi, compose_arrangement with clear_existing=true) lack confirmation pattern or dry-run support. Agents can accidentally erase work without warning per pattern:confirmation-request.
Parameter constraints (enums, min/max, patterns) declared only in description text, not as JSON Schema constraints. analyze_loudness 'reference' has hardcoded valid values; take_set_pitch 'semitones' has range limits; neither is formally constrained in schema. Forces LLM to parse text and guess valid values per pattern:constrained-input.
Tool descriptions are brief (55-125 chars), below 194-char production baseline. Lack 'WHEN to use' context, dependencies, and consequences. Agents cannot distinguish compose_arrangement from compose_edit_tools or predict when to call each per pattern:tool-description.
No error handling or recovery guidance documented. What happens if analyze_loudness receives an invalid path? If compose_arrangement fails to parse shorthand? If wipe_all_midi has no tracks to wipe? Agents receive no actionable error recovery hints per pattern:recovery-guide.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema or registration. Agents cannot infer safety/irreversibility without reading descriptions. Per current spec (2026-07-28), tool annotations should be present for WRITE and DESTRUCTIVE tools.