Skip to main content
Glama

openDAW MCP

CI Docs License: Apache-2.0 PyPI OpenSSF Scorecard MCP Tools Skills DSP Scripts Tests Examples Python Lint MCP Registry Smithery Glama LangChain + AutoGen + CrewAI Sponsor

547 MCP tools for agent-native control of openDAW — a browser-based digital audio workstation.

This project wraps openDAW's internal box system and project API behind a Model Context Protocol server, allowing AI agents (Claude, GPT, Hermes, etc.) to create and manipulate music projects programmatically — tracks, instruments, effects, MIDI, automation, audio regions, rendering, and more.

Star this repo if it's useful — it helps others discover it!

Quick numbers

547 MCP tools

226 Python examples

134 DSP scripts

12 agent skills

3 framework wrappers

6139 unit + E2E tests

7 stem separation modes

0 ruff errors

30-second demo

from opendaw_mcp.server import OpendawServer

server = OpendawServer()
await server.bridge.start()

# Full drum beat in one call (kick|snare|hihat, 16 steps each)
await server.mcp_opendaw_create_drum_pattern(
    pattern="x...x...x...x...|o.......o.....o.|..x...x...x...x.", unit_index=0
)

# Synth + reverb
await server.mcp_opendaw_create_synth_track(name="Lead")
await server.mcp_opendaw_add_effect(unit_index=1, effect_type="Dattorro")

# Render to WAV
await server.mcp_opendaw_render_full(output_path="beat.wav")

Why opendaw-mcp?

The only fully headless, zero-license MCP server for music production. No DAW license, no desktop, no GUI — runs in Docker, CI, and cloud.

Comparison with Ableton-MCP competitors

Feature

opendaw-mcp

ahujasid/ableton-mcp

Producer Pal

OSC-based MCPs

License required

None (free)

Ableton Live 10+ ($99+)

Ableton Live

Varies

Headless / server

✅ Docker, CI, cloud

❌ Desktop only

❌ Desktop only

⚠️ Needs Live running

Tool count

543

~10

~15

~5-10

Tool annotations

✅ readOnly + destructive

Scriptable DSP

✅ Custom JS effects

Stem separation

✅ 7 models (GPU local)

Suno → DAW pipeline

✅ End-to-end

Genre templates

✅ 8 genres

Agent skills

✅ 12 skills

Render with LUFS target

✅ (-14, -16, custom)

dawproject export

✅ Ableton/Bitwig

Lite agent profile

✅ 39 tools

Phase-based tool loading

✅ inspect/compose/mix/render

Bridge benchmarks

✅ p50/p95 in CI

GitHub stars

2.8k

Our moat: fully headless, zero-cost, 547 tools, runs anywhere. Every competitor requires a paid DAW running on a desktop.

Related MCP server: ableton-live-mcp

How It Works

AI Agent ──MCP──▶ Python Server ──Playwright──▶ Headless Chromium ──▶ openDAW (Vite dev server)

The MCP server launches a headless Chromium instance loaded with openDAW, then communicates via page.evaluate() calls into the DAW's V8 context. Every tool performs real operations on the live project — no stubs, no mocks.

Features

  • Track & Region CRUD — create/delete/move audio, note, and automation tracks with regions

  • Instrument Control — Vaporisateur ( polysynth), Nano, Tape, Soundfont, Playfield (drum machine), MIDI output

  • Effects — Delay, Reverb, Compressor, Equalizer, Saturation, Waveshaper, Stereo, Vocoder, NeuralAmp, Maximizer

  • MIDI Effects — Arpeggio, Pitch, Velocity, Zeitgeist, Spielwerk (scriptable)

  • Scriptable Devices — Apparat (instrument), Werkstatt (audio effect), Spielwerk (MIDI effect) with JS code compilation, full @param mapping metadata, and range-validated parameter setting

  • Automation — event creation, interpolation modes, tempo/signature changes

  • Audio Operations — region fades, gain, time/pitch stretch, warp markers, play modes

  • Mixing — send/return routing, buses, volume, solo/mute, mixer state inspection

  • Rendering — offline stem export with LUFS targeting, full mix render

  • Clips — session view clip CRUD, clone, consolidate, playback settings

  • Groove — groove shuffle amount and duration control

  • Presets — export/import audio unit presets, effect chain presets

  • Transfer — move regions and audio units between projects

  • Project Info — tempo map conversion (PPQN↔seconds), duration, validation, sample listing

  • Notes — pitch range, overlapping detection, advanced properties (chance, cent, playCount, playCurve)

  • Modular System — voltage modules (Gain, Delay, Multiplier, AudioInput, AudioOutput), patch cable connections

  • Piano Mode — global transpose, keyboard type, note scale, time range

  • Project & Bus Metadata — creation date, signature, AU/track count, bus labels and colors

  • Debugging & Control — screenshots, condition polling, raw JS evaluation

Agent Skills

The skills/ directory contains structured skill files for AI agents (Hermes, Claude, etc.) that describe how to use the 547 MCP tools effectively. Each skill covers a specific domain and includes decision points so the agent can adapt to any genre or workflow.

Skill

Domain

Description

adaptive-mix-mastering

Mix → Master pipeline

Universal pipeline with decision points: genre detection, stem strategy, effect chain selection, LUFS targeting, mastering approach. Adapts to coldwave, techno, hip-hop, ambient, rock, pop. Includes references/decision-tree.md.

suno-to-opendaw

Suno → openDAW E2E

Killer workflow: Suno AI generation → SOTA stem separation (7 modes) → openDAW import → arrange → mix → master → export. 6-stage pipeline from prompt to finished track. Unique value prop — no other MCP server offers this.

dsp-script-authoring

Custom DSP writing

How to author custom Werkstatt/Apparat/Spielwerk DSP scripts. Processor API, @param/@sample declarations, DSP patterns (filters, saturation, reverb, LFO, envelope), validation workflow, 8 critical pitfalls. For writing new DSP, not using existing.

opendaw-automation

API reference

547 MCP tools full reference, bridge architecture, pitfalls, DSP script library (134 scripts), CodeRabbit review patterns. The base skill — others cross-reference it.

opendaw-track-architecture

Track structure

Tracks, regions, clips, notes, tempo, time signature, markers, groove, song form. 50+ tools for building the skeleton of a track.

opendaw-sound-design

Instruments + DSP

Built-in instruments (Vaporisateur, Playfield, Nano, Tape, Soundfont) + 33 scriptable DSP scripts (Werkstatt/Apparat/Spielwerk) with full API reference and choosing guide.

opendaw-genres

Genre templates

Concrete parameters per genre — BPM, track layout, drum patterns, bass lines, chords, effect chains, pan, LUFS targets. 8 genres: techno, coldwave, hip-hop, ambient, DnB, house, lofi, trap. Not theory — actual tool calls and values.

opendaw-effect-routing

Effects + routing

Effect chains, sends/returns, sidechain, buses, mixing, mastering chain, render/export. How to route audio and deliver final output.

opendaw-composition-patterns

Composition

When and how to use 26 orchestration tools. Decision tree by musical goal, genre-specific recipes, parameter guidelines, pitfalls. Hip-hop/house/jazz/DnB/ambient/expressive MIDI workflows.

opendaw-dsp-chains

DSP signal chains

10 production-ready DSP chain recipes: vocal, guitar, drum bus, synth bass, lofi, mastering, acid, ambient, vocoder, distortion. Exact Werkstatt scripts, order, parameters. Pitfalls: EQ→dynamics→saturation→time order, no double saturation, reverb/limiter last.

Using skills with Hermes

# Skills are auto-discovered from ~/.hermes/profiles/*/skills/
# Copy to your profile:
cp -r skills/adaptive-mix-mastering ~/.hermes/profiles/your-profile/skills/creative/

Using skills with other agents

The SKILL.md files are standard markdown with YAML frontmatter. Any agent that supports skill loading can use them. The decision points and tool references are agent-agnostic.

Suno Integration

opendaw-mcp connects with Suno for AI music generation. The flagship suno_generate_to_opendaw.py example demonstrates the full pipeline: Suno generation → download → openDAW import → mastering → render.

Getting Suno API access: Join the Suno Discord to get chirp API access. Without it, generation won't work — this is required for all Suno-based workflows.

Pipeline examples:

  • suno_generate_to_opendaw.py — Suno generation → openDAW mastering (flagship)

  • suno_to_opendaw.py — Import existing Suno track → enhance with DSP

  • suno_stems_to_opendaw.py — Stem split → per-stem mix → render

Quick Start

📚 Full documentation: https://ameobius.github.io/opendaw-mcp/

Prerequisites

  • Python 3.11+

  • Node.js 20+ (for openDAW dev server)

  • Chromium (Playwright will install it)

Install

From PyPI:

pip install opendaw-mcp
playwright install chromium

From source:

git clone https://github.com/AMEOBIUS-team/opendaw-mcp.git
cd opendaw-mcp
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
playwright install chromium

Set Up openDAW

Clone and build openDAW separately:

git clone https://github.com/andremichelle/openDAW.git
cd openDAW
npm install
npm run build   # or: npx turbo run build

Create a headless host page (see headless-daw/ for reference implementation).

Run

# Terminal 1: Start openDAW dev server
cd openDAW
npm run dev     # typically serves on http://localhost:5174

# Terminal 2: Start MCP server (stdio transport, default)
cd opendaw-mcp
source venv/bin/activate
python server.py

SSE Transport

For remote deployments and registry introspection (e.g. Glama):

MCP_TRANSPORT=sse FASTMCP_HOST=0.0.0.0 FASTMCP_PORT=8080 python server.py

Token Optimization Modes

opendaw-mcp ships 547 MCP tools. For token-sensitive environments, three modes reduce schema payload:

Mode

Env var

Tools

Savings

When to use

full (default)

OPENDAW_MCP_MODE=full

543

0%

Full control, no token constraints

lite

OPENDAW_MCP_MODE=lite

39

92%

Basic track production, minimal context

phase

OPENDAW_MCP_MODE=phase

10-55

90%

Phase-based: agent calls switch_phase() to load relevant tools

# Lite mode — 39 essential tools
OPENDAW_MCP_MODE=lite python server.py

# Phase mode — agent switches between compose/mix/render/inspect
OPENDAW_MCP_MODE=phase python server.py

Phase guides: docs/phases/compose.md, docs/phases/mix.md, docs/phases/render.md, docs/phases/inspect.md

Output Sandbox

Truncate bulky tool responses to prevent context flooding:

OPENDAW_MCP_OUTPUT_LIMIT=2000 python server.py  # max 2000 chars per response

Smart JSON truncation: dicts get field truncation with __truncated flag, lists get first N items with total/shown counts.

CLI

python server.py --help        # show usage and env vars
python server.py --version     # print version and tool count
python server.py --list-tools  # list all registered MCP tools

Docker

# Pull pre-built image from GitHub Container Registry
docker pull ghcr.io/ameobius/opendaw-mcp:1.14.1
docker run -p 8080:8080 ghcr.io/ameobius/opendaw-mcp:1.14.1
# MCP server available at http://localhost:8080/sse

# Or build from source
docker build -t opendaw-mcp .
docker run -p 8080:8080 opendaw-mcp

The Docker image bundles openDAW (built from source), Vite dev server, Chromium, and the MCP server. The entrypoint starts Vite, waits for it to be ready, then launches the MCP server in SSE mode.

Claude Desktop / MCP Client Config

Add to your MCP client config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "opendaw": {
      "command": "python",
      "args": ["path/to/opendaw-mcp/server.py"],
      "env": {
        "OPENDAW_HOST_DIR": "path/to/headless-daw",
        "OPENDAW_URL": "http://localhost:5174",
        "OPENDAW_EXPORT_DIR": "path/to/exports"
      }
    }
  }
}

See mcp.json in the repo for a reference config.

Environment Variables

Variable

Default

Description

OPENDAW_HOST_DIR

../headless-daw

Path to the headless openDAW host directory

OPENDAW_URL

http://localhost:5174

URL of the running openDAW instance

OPENDAW_EXPORT_DIR

../exports

Directory for rendered audio exports

NODE_BIN_DIR

(from PATH)

Path to Node.js binary directory (if not on PATH)

MCP_TRANSPORT

stdio

Transport protocol: stdio or sse

FASTMCP_HOST

127.0.0.1

SSE server bind host

FASTMCP_PORT

8000

SSE server bind port

Publishing Identity Mapping

This project uses a hybrid identity scheme — different namespaces for different registries. See docs/identity-mapping.md for the full mapping and rules.

Platform

Namespace

GitHub

AMEOBIUS-team/opendaw-mcp

MCP Registry

io.github.AMEBIUS/opendaw-mcp

GHCR

ghcr.io/ameobius/opendaw-mcp

PyPI

opendaw-mcp

Smithery

@macar228228/opendaw-mcp

Architecture

HeadlessDawBridge

The HeadlessDawBridge class manages the Playwright lifecycle:

  1. Launches headless Chromium with audio autoplay enabled

  2. Navigates to the openDAW URL

  3. Waits for window.DAW and factory globals to load

  4. Injects DAW_HELPERS — JS utility functions that eliminate boilerplate across tools

DAW_HELPERS

JavaScript helpers injected into the DAW context:

  • au(i) — get audio unit adapter by index

  • track(auIdx, trackIdx) — get track adapter

  • region(au, track, reg) — get region adapter

  • instrumentAU() — get the first instrument audio unit

  • modify(fn) — wrapper around editing.modify() for box mutations

  • allAUs() — list all audio unit adapters

Tool Structure

Each MCP tool follows the pattern:

@mcp.tool()
async def tool_name(param: str) -> str:
    """Description."""
    async def _run():
        result = await bridge.page.evaluate("""...JS...""")
        return json.dumps(result)
    return await bridge.run(_run)

The bridge is a singleton — state persists within a single Python process. All box mutations go through editing.modify() as required by openDAW's transactional model.

Input Sanitization

All string parameters that are interpolated into JavaScript template literals are sanitized before evaluation — quotes, backslashes, and braces are stripped to prevent JS injection. Numeric parameters use proper int/float type annotations for FastMCP type coercion.

DSP Scripts

The scripts/ directory contains 30 example DSP scripts (19 Werkstatt + 5 Apparat + 6 Spielwerk):

Script

Device

Description

werkstatt_darksat.js

Werkstatt

Tape saturation with drive, bias, tone, mix, output gain

werkstatt_coldfold.js

Werkstatt

Wavefolding + bitcrush + slew rate reduction

werkstatt_paulstretch.js

Werkstatt

Extreme time-stretch via FFT/ISTFT overlap-add

werkstatt_envfollower.js

Werkstatt

Envelope follower with sidechain ducking

werkstatt_chorus.js

Werkstatt

Stereo chorus with LFO-modulated delay lines

werkstatt_reverb.js

Werkstatt

Algorithmic reverb with comb + allpass filters

werkstatt_shimmer.js

Werkstatt

Pitch-shimmer reverb with granular pitch shift

werkstatt_spectral_freezer.js

Werkstatt

Spectral freeze — captures & sustains a spectral frame for drone/ambient textures

werkstatt_phaser.js

Werkstatt

Phaser with LFO-swept allpass filter chain

werkstatt_subcrusher.js

Werkstatt

Sub-bass enhancement with glide and distortion

werkstatt_lookahead.js

Werkstatt

Lookahead limiter with gain reduction metering

werkstatt_adsr_trim.js

Werkstatt

ADSR envelope trim for sustained samples (#241)

werkstatt_flanger.js

Werkstatt

Stereo flanger with LFO-modulated delay line and feedback

werkstatt_noisegate.js

Werkstatt

Noise gate with threshold, attack/hold/release, range control

werkstatt_tremolo.js

Werkstatt

Tremolo with sine→square shape interpolation and phase offset

werkstatt_granular_stretch.js

Werkstatt

Granular time-stretch with Hann window + pitch shift (#201)

werkstatt_pitch_shift.js

Werkstatt

Real-time pitch shifter via delay-line sweep with crossfade (#188)

werkstatt_dcremover.js

Werkstatt

DC offset remover + M/S stereo width tool (#91)

werkstatt_allpass.js

Werkstatt

Allpass filter with invert + cascade stages (#133)

werkstatt_ringmod_env.js

Werkstatt

Ring modulator with envelope-followed frequency modulation (#277)

apparat_darkbass.js

Apparat

Bass synth with sub oscillator and filter envelope

apparat_coldlead.js

Apparat

Lead synth with detune and vibrato

apparat_subcrusher.js

Apparat

Sub-bass synth with glide and distortion

apparat_ringmod.js

Apparat

Ring modulator synth with ADSR and sub-oscillator (#277)

apparat_fm.js

Apparat

2-operator FM synth with carrier/modulator ratio and ADSR (#138)

spielwerk_powerchord.js

Spielwerk

MIDI effect that generates power chord harmonies

spielwerk_arpeggiator.js

Spielwerk

MIDI arpeggiator with swing and octave range

spielwerk_chordmemory.js

Spielwerk

Chord memory — holds last chord shape (major/minor/7/dim/aug)

spielwerk_strum.js

Spielwerk

Strummer with up/down/random direction and spread

spielwerk_velocity.js

Spielwerk

Velocity scaler with curve, offset, and min/max clamp

spielwerk_mididelay.js

Spielwerk

MIDI delay with feedback, transpose per repeat, and decay

Showcase

Three demos proving end-to-end audio production:

Demo

Command

What it shows

Techno in 30s

python examples/showcase/01_techno_30s.py

Genre preset → master → -14 LUFS WAV

Ambient pad

python examples/showcase/02_ambient_pad.py

Manual synthesis, reverb, filter sweep

Suno → DAW

python examples/showcase/03_suno_to_daw.py track.wav

Stem separation, remix, re-render

See docs/showcase/ for details.

Examples

The examples/ directory contains 73 Python scripts demonstrating the full workflow:

Example

Description

create_beat.py

Drum beat with Playfield

create_chord_progression.py

Chord progression with Vaporisateur

mix_workflow.py

Mixing: levels, effects, sends

render_stems.py

Stem export with LUFS targeting

automation_sweep.py

Filter cutoff automation

modular_patch.py

Modular system with patch cables

full_production_pipeline.py

Complete track: synth + drums + DSP + automation + render

full_production_pipeline_v2.py

Enhanced pipeline with orchestration tools

scriptable_devices_demo.py

All 3 scriptable device types: Apparat synth + Werkstatt DSP + Spielwerk MIDI

device_specific_params.py

Effect parameters: Compressor, Reverb, Delay, etc.

instrument_automation.py

Automating instrument parameters over time

mastering_pipeline.py

Mastering chain: EQ, compression, limiting

metronome_settings.py

Metronome configuration and tempo changes

orchestration_demo.py

High-level orchestration tools in action

song_structure_demo.py

Song structure with markers and sections

render_convert.py

Render and convert audio formats

dawproject_export.py

Export to Bitwig .dawproject format

warp_marker_tempo_match.py

Warp markers for tempo-matched audio regions

suno_to_opendaw.py

Suno→openDAW pipeline: import AI track, add mastering chain, reverb send, arp layer, render+stems

suno_stems_to_opendaw.py

Full E2E: stem split (7 SOTA modes, local GPU) → import stems → per-stem mix (vol/pan/effects) → MIDI arp layer → render+export

suno_generate_to_opendaw.py

Flagship: Suno generation (chirp_generate) → download → openDAW load → mastering (DarkSat+Lookahead) → LUFS check → render

preset_management.py

Save/load Werkstatt effect presets (.opb) — compile DSP script, tweak params, export preset, import back

genre_techno.py

Genre template: techno skeleton (130 BPM, 4-on-floor drums, rolling bass, Vaporisateur+Playfield, Compressor+Waveshaper chain)

genre_coldwave.py

Genre template: coldwave skeleton (100 BPM, sparse drums, Am-Fmaj7-Cmaj-Gdom7 progression, 4 tracks, Dattorro reverb, Waveshaper hardclip)

genre_ambient.py

Genre template: ambient skeleton (70 BPM, no drums, Cmaj7-Amin7-Fmaj7-Gmaj7, pad+bell+texture, long reverbs decay 0.85-0.95)

genre_hiphop.py

Genre template: hip-hop skeleton (85 BPM, boom bap drums, 808 bass Ab minor, dark pentatonic melody, Compressor+Waveshaper)

genre_dnb.py

Genre template: DnB skeleton (174 BPM, Amen break, reese+sub bass F minor, aggressive Comp 8:1, Waveshaper)

genre_house.py

Genre template: house skeleton (124 BPM, 4-on-floor, off-beat chord stabs Fmin9-Cmin9-Gmin9-Dmin9, rolling bass, Delay+Reverb)

genre_lofi.py

Genre template: lofi skeleton (82 BPM, swung drums, jazzy Dmin7-Gdom7-Cmaj7-Fmaj7 ii-V-I, warm bass, short reverb)

genre_trap.py

Genre template: trap skeleton (145 BPM, fast hi-hat rolls, gliding 808 bass, dark minor melody)

create_melody.py

Melody from scale degrees + rhythmic pattern (14 scales, rests, sustains, octave shifts)

create_bassline.py

Bassline from root + rhythmic pattern (low octave, high velocity, scale degrees)

create_arpeggio.py

Arpeggios from chord names — 6 patterns (up/down/updown/downup/random/chord), 6 rates

humanize_notes.py

Humanize MIDI: velocity/timing/duration variation + swing (seeded PRNG, reproducible)

create_harmony.py

Generate harmony parts — diatonic (3rds/5ths/6ths) + chromatic intervals, up/down

create_counterpoint.py

Counter-melody in contrary motion — mirrors melody around center pitch

reverse_invert_notes.py

Melodic variation: retrograde (reverse) + mirror inversion around axis

create_drum_fill.py

Drum fills/transitions: 5 types (build, break, roll, crash, tom), adjustable density

create_ostinato.py

Repeating melodic pattern as foundation layer (minimalism, electronic, film)

create_crescendo.py

Crescendo/decrescendo on existing notes: linear, exponential, logarithmic curves

custom_dsp_script.py

DSP authoring: custom Werkstatt analog saturation script (tanh + DC blocker + tone filter), compile via ScriptCompiler, set params, verify

langchain_integration.py

LangChain toolkit: use opendaw-mcp tools as LangChain Tool objects with any LLM agent

autogen_integration.py

AutoGen toolkit: use opendaw-mcp tools with Microsoft AutoGen agents

crewai_integration.py

CrewAI toolkit: use opendaw-mcp tools with CrewAI crews

screenshot_demo.py

Create a full house track with drums/bass/chords/effects, take a screenshot of the DAW UI, render to WAV

Agent Framework Integration

LangChain

from opendaw_mcp.langchain_tools import OpendawToolkit

toolkit = OpendawToolkit()
tools = toolkit.get_tools()  # or filter: get_tools(categories=["transport", "orchestration"])

# Use with any LangChain agent
from langchain.agents import create_react_agent, AgentExecutor
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini")
agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

executor.invoke({"input": "Create a dark techno track at 130 BPM and render it"})

See examples/langchain_integration.py for a full demo.

AutoGen

from opendaw_mcp.autogen_tools import get_autogen_tools

tools = get_autogen_tools()  # or filter: get_autogen_tools(categories=["transport", "orchestration"])

from autogen import AssistantAgent, UserProxyAgent

assistant = AssistantAgent("producer", llm_config=llm_config, tools=tools,
    system_message="You are a music producer. Use opendaw tools to create, mix, and render music.")
user = UserProxyAgent("user", human_input_mode="NEVER")
user.initiate_chat(assistant, message="Create a dark techno track at 130 BPM and render it")

See examples/autogen_integration.py for a full demo.

CrewAI

from opendaw_mcp.crewai_tools import get_crewai_tools

tools = get_crewai_tools()

from crewai import Agent, Task, Crew, LLM

llm = LLM(model="gpt-4o-mini")
producer = Agent(role="Music Producer", goal="Create and mix tracks", backstory="Expert producer", tools=tools, llm=llm)
task = Task(description="Create a dark techno track at 130 BPM and render it", agent=producer, expected_output="WAV file")
crew = Crew(agents=[producer], tasks=[task])
result = crew.kickoff()

See examples/crewai_integration.py for a full demo.

Tool Catalog

See TOOL_CATALOG.md for the complete list of 547 tools with parameters and descriptions.

Orchestration Tools

High-level composers that combine multiple low-level operations into a single call — designed for agents to reduce token usage and round-trips:

Tool

Replaces

Example

create_notes_batch

10-50 × create_note

'[{"pitch":60,"start":0,"duration":0.5},...]'

create_drum_pattern

10-20 × create_note

'{"kick":"x...x...","hihat":"....o..."}'

create_chord_progression

15-50 × create_note

'[["C","min7"],["F","dom7"]]'

add_mastering_chain

3 × add_effect + 10 × set_param

style="warm", target_lufs=-14

create_genre_track

20-40 low-level calls

genre="lofi" → synth + drums + bass + chords

Mastering

The MCP server includes a full mastering chain for streaming-ready output:

  1. Renderrender_full (full mixdown) or export_stems (per-track stems)

  2. Measure LUFSmeasure_lufs (ITU-R BS.1770-4 K-weighting, gated mean squares)

  3. Auto-gainauto_gain (iterative: render → measure → adjust Maximizer threshold + output volume → re-render, converges ±1 LUFS)

# Render full mix
await server.mcp_opendaw_render_full("my_mix", 48000)

# Measure loudness
lufs = json.loads(await server.mcp_opendaw_measure_lufs("my_mix"))
# → {"lufs_integrated": -18.3, "true_peak_db": -3.71, ...}

# Auto-gain to Spotify target (-14 LUFS)
result = json.loads(await server.mcp_opendaw_auto_gain("-14", "mastered", 48000, "3"))
# → converges to -13.7 LUFS in 3 iterations

Platform targets: Spotify/YouTube -14 LUFS, Apple Music -16 LUFS, Tidal -14 LUFS.

Limitations

  • Headless only — some UI-dependent features (file dialogs, popup-based model loading) are not available

  • Single process — bridge state doesn't persist across Python process restarts

  • Upstream coupling — tools depend on openDAW's internal box system, which can change between versions

  • AU rename — requires adapter context not available in headless mode

Acknowledgments

License

Apache-2.0 — see LICENSE

Changelog

v1.86.0 (2026-07-05)

  • werkstatt_autowah.js DSP script — envelope-followed filter (autowah): filter frequency driven by input envelope, not LFO or static cutoff. 3 filter modes (bandpass/peaking/lowpass), sensitivity, attack/release, direction (up/down sweep), cutoff smoothing. 69 DSP scripts

  • 828 unit tests (+13), E2E 8/8

v1.85.0 (2026-07-05)

  • werkstatt_dimension_chorus.js DSP script — Roland Dimension D-style chorus: 2 detuned delay lines with independent LFO rates (triangle wave), no feedback, mono-sum input, brightness filter, stereo width control. 68 DSP scripts

  • 818 unit tests (+13), E2E 8/8

v1.84.0 (2026-07-05)

  • werkstatt_multitap_delay.js DSP script — multitap delay: 4 independent taps from single delay buffer, each with time/level/pan/feedback. Equal-power stereo pan per tap, feedback damping, spread modulation. 67 DSP scripts

  • 805 unit tests (+13), E2E 8/8

v1.83.0 (2026-07-05)

  • create_stutter orchestration tool — stutter edit: rapid rhythmic repetitions with evolving rate and dynamics. 5 patterns (accelerate, decelerate, ping_pong, constant, random), 5 accent patterns, 5 velocity ramps, gate, pitch jitter. Unlike create_chop (equal segments) — rate evolves over time. 309 MCP tools

  • 792 unit tests (+10), E2E 8/8

v1.82.0 (2026-07-05)

  • spielwerk_harmonizer.js DSP script — MIDI harmonizer: 3 voices at fixed intervals or diatonic, per-voice velocity, 14 scales. 66 DSP scripts

  • 782 unit tests (+11), E2E 8/8

v1.81.0 (2026-07-05)

  • werkstatt_dynamic_eq.js DSP script — dynamic EQ with 3 bands. Each band: peaking biquad filter + envelope follower that tracks signal level at that frequency. When level exceeds threshold, gain is dynamically reduced by up to range dB. Detection uses a separate unity-gain peaking filter to isolate band energy, processing filter applies the dynamic gain. 19 params: 3 bands × (freq, gain, Q, threshold, range) + attack, release, mix, output. Unlike parametric EQ (static gain) or multiband compressor (crossover split, phase issues), dynamic EQ applies dynamic gain only at the target frequency — surgical de-essing, resonance control, plosive removal without affecting the rest of the spectrum. Pro-tier mixing tool (FabFilter Pro-Q3, T-Racks, Soothe2)

  • 66 DSP scripts (50 Werkstatt + 8 Apparat + 8 Spielwerk)

  • 782 unit tests (+11), E2E 8/8

  • ruff clean, CI green

v1.80.0 (2026-07-05)

  • spielwerk_scale_quantizer.js DSP script — MIDI scale quantizer. Snaps incoming note pitches to the nearest pitch in the selected scale. 14 scales: major, minor, dorian, phrygian, lydian, mixolydian, locrian, minor/major pentatonic, harmonic minor, melodic minor, hungarian minor, double harmonic, chromatic (pass-through). 12 root notes (C-B). Direction: nearest (default) or always-up. Unlike arpeggiator (generates notes) or velocity (scales dynamics), this is a constraint — it forces out-of-scale notes into the scale. The most essential MIDI effect for live playing and generative music — no more wrong notes. 3 params: scale, root, direction

  • 64 DSP scripts (49 Werkstatt + 8 Apparat + 7 Spielwerk)

  • 762 unit tests (+10), E2E 7/7

  • ruff clean, CI green

v1.79.0 (2026-07-05)

  • apparat_supersaw.js DSP script — JP-8000 style supersaw synthesizer. 7 detuned sawtooth oscillators with fixed detune pattern (-12/-7/-4/0/+4/+7/+12 cents), per-voice equal-power stereo pan (center voice = center, outer voices spread wide), resonant one-pole lowpass filter with cutoff (50Hz-16kHz exponential) + resonance feedback. 9 params: detune, spread, cutoff, resonance, attack, decay, sustain, release, volume. Unlike wavetable synth (scanned tables, mono), supersaw uses 7 independent sawtooth phases with dedicated stereo placement — the iconic trance/hardstyle/EDM lead sound. ADSR envelope, randomized phase init per noteOn for rich texture

  • 63 DSP scripts (49 Werkstatt + 8 Apparat + 6 Spielwerk)

  • 752 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.78.0 (2026-07-05)

  • werkstatt_convolution_reverb.js DSP script — convolution reverb with generated stereo impulse response. Time-domain direct convolution with a procedurally generated IR: early reflections (7 discrete taps with stereo spread) + exponentially decaying noise tail through one-pole lowpass. Room size controls IR length (50-300ms), decay controls exponential envelope, damping controls lowpass cutoff (2k-16k Hz), predelay shifts reflections, early/late balance mixes discrete taps vs diffuse tail, width controls stereo spread of reflections. 8 params: room_size, decay, damping, predelay, early_late, width, mix, output. Unlike algorithmic reverb (feedback delay network), convolution uses an actual IR — the gold standard for realistic acoustic spaces. IR capped at 8192 samples for CPU. Classic for: realistic room/hall/cathedral ambience, drum room sound, vocal space, film post-production

  • 62 DSP scripts (49 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 742 unit tests (+10), E2E 8/8

  • 100 Python examples

  • ruff clean, CI green

v1.77.0 (2026-07-05)

  • create_motif_development orchestration tool — through-composed melodic development. Takes a 2-8 note motif and builds ONE continuous melodic line that evolves through 11 stage types: statement, sequence_up/down, fragment/fragment_end, invert, octave_up/down, expand, compress, cadence. Beethoven 5th approach — a 4-note seed grows into a full melodic arc. Unlike create_variations (separate regions, each a full transform), this writes a single flowing line. Unlike create_sequence (pure transposition), this mixes multiple development techniques in sequence. Accepts scale degrees (1-7) or MIDI pitches. 51 orchestration tools → 51

  • 308 MCP tools (51 orchestration)

  • 732 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.76.0 (2026-07-05)

  • werkstatt_rotary_speaker.js DSP script — Leslie rotary speaker emulation. Dual rotor system: horn (high rotor) with Doppler pitch modulation via variable delay + amplitude modulation, and rotor (low rotor) with amplitude modulation only. Crossover split (200-4000 Hz) routes highs to horn, lows to rotor. Speed control (0.8-6.67 Hz = 48-400 RPM), acceleration simulates the mechanical ramp-up/ramp-down of a real Leslie. Stereo widening via opposite-phase rotors. Unlike chorus (constant delay modulation) or tremolo (amplitude only), rotary speaker combines Doppler + amplitude + crossover + acceleration for the authentic Hammond organ / guitar sound. Classic for: Hammond organ, Pink Floyd guitar, Jon Lord Deep Purple, soul vocals, dub reggae. 7 params: speed, depth, crossover, horn_level, rotor_level, acceleration, mix

  • 61 DSP scripts (48 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 722 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.75.0 (2026-07-05)

  • create_variations orchestration tool — thematic variation generator. Reads notes from a source region and generates N variations, each as a new region. 9 transformation types: transpose, invert (with axis), reverse, augment, diminish, fragment, octave_up, octave_down. Up to 16 variations per call. This is the fundamental compositional technique of theme-and-variations — Bach Goldberg, Beethoven Diabelli, Brahms, jazz reharmonization. Unlike transpose_notes/invert_notes (destructive, modify in place), create_variations is generative — reads source, writes each variation to a new region. 50 orchestration tools → 50

  • 307 MCP tools (50 orchestration)

  • 712 unit tests (+10), E2E 9/9

  • ruff clean, CI green

v1.74.0 (2026-07-05)

  • opendaw-dsp-chains agent skill — 10 production-ready DSP signal chain recipes: vocal, guitar, drum bus, synth bass, lofi character, mastering, acid house, ambient pad, vocoder/vocal FX, distortion/metal. Each chain specifies exact Werkstatt scripts, order, and parameter values. Includes pitfalls section (EQ→dynamics→saturation→time order, no double saturation, reverb/limiter always last, moog self-oscillation warning, vocoder carrier requirements). DSP script index by family. 12 agent skills total

  • ruff clean, CI green

v1.73.0 (2026-07-05)

  • werkstatt_moog_ladder.js DSP script — Moog ladder filter (24dB/oct) with 4 cascaded one-pole stages, feedback resonance with self-oscillation, Huovilainen improved topology with tanh nonlinearity per stage. 3 modes: LP (classic Moog 24dB), HP (subtractive), BP (cascade). Drive (pre-filter saturation), warmth (feedback cross-mix from stage 1 to resonance path). Unlike multifilter (Chamberlin SVF — 12dB/oct, linear phase), Moog ladder has nonlinear character, steeper rolloff, and harmonic distortion at high resonance. Classic for: subtractive synthesis, acid bass, synthwave leads, analog emulation, house stabs. 6 params: cutoff, resonance, drive, warmth, mode, mix

  • 60 DSP scripts (47 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 702 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.72.0 (2026-07-05)

  • werkstatt_waveshaper.js DSP script — custom-curve waveshaper with 4 transfer functions: tanh (warm soft-clip), cubic (aggressive knee), atan (hard shoulders), Chebyshev (harmonic injection — 2nd/3rd harmonic blend via harmonics param). Drive (0-3), bias (asymmetric even harmonics), tone filter (one-pole LP/HP blend), output gain, dry/wet mix. Unlike tube_saturator (fixed curve) or coldfold (wavefolding), waveshaper gives 4 distinct shaping curves in one unit. Classic for: guitar amp simulation, harmonic excitement, creative distortion, analog emulation. 7 params: drive, curve, bias, harmonics, tone, output, mix

  • 59 DSP scripts (46 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 692 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.71.0 (2026-07-05)

  • create_two_hand_piano orchestration tool — two-hand piano arrangement generator. Left hand: 6 accompaniment patterns (block chords, arpeggio up/down/up-down, Alberti bass, bass+chord). Right hand: chord tones, arpeggiated chords, or custom melody. Separate bass/chord/melody octaves, adjustable arpeggio rate. Unlike create_chord_progression (block chords only) or create_melody (single line), this combines both hands into one coherent piano arrangement. Essential for: piano ballads, jazz comping, classical accompaniment, lofi piano, singer-songwriter patterns. 49 orchestration tools → 49

  • 306 MCP tools (49 orchestration)

  • 625 unit tests (+10), E2E 8/8

v1.70.0 (2026-07-05)

  • create_fugue orchestration tool — polyphonic fugue generator with subject, tonal/real answer, countersubject, and stretto. Subject stated in first voice, then imitated in others with tonal answer (5th up, diatonic adjustment) or real answer (exact transposition). Optional countersubject provides contrasting counterpoint after subject completes. Stretto mode overlaps voice entries for climactic density. Voice alternation: subject → answer → subject (octave down) → answer. Per-voice velocity decay. 2-5 voices, 2-32 note subject. Distinct from create_canon (strict imitation) and create_chorale (SATB voice leading) — fugue uses independent subject/answer/countersubject with tonal answer adjustment. Bach Well-Tempered Clavier, Art of Fugue. 48 orchestration tools → 48

  • 305 MCP tools (48 orchestration)

  • 615 unit tests (+10), E2E 8/8

v1.69.0 (2026-07-05)

  • werkstatt_spectral_gate.js DSP script — multiband spectral gate with per-band envelope followers. 4-16 log-spaced bandpass filter bank, each band has independent envelope detection. Bands below threshold are reduced by adjustable amount. Tilt control shifts spectral balance (boost highs, cut lows or vice versa). Attack/release smoothing per band. Output highpass. Classic for noise reduction, spectral cleaning, creative gating, dub-style frequency manipulation. 10 params: bands, threshold, reduction, attack, release, min_freq, max_freq, tilt, mix, output

  • 58 DSP scripts (45 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 605 unit tests (+10), E2E 8/8

v1.68.0 (2026-07-05)

  • werkstatt_looper.js DSP script — live looper with overdub. Records audio into circular buffer, plays back with variable speed (0.25x-4x), overdubs new layers with adjustable feedback. Three play modes: auto (record then overdub), play (playback only), overdub (continuous layering). Reverse mode for backwards loops. Crossfade at loop boundaries prevents clicks. Input monitor for zero-latency monitoring. Classic for live electronica, guitar looping, ambient performance, Ed Sheeran-style live layering. 10 params: loop_length, feedback, overdub, play_mode, speed, reverse_mode, monitor, fade_edges, mix, output

  • 57 DSP scripts (44 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 595 unit tests (+10), E2E 8/8

v1.67.0 (2026-07-05)

  • create_chorale orchestration tool — 4-voice SATB chorale generator with voice-leading rules. Parses chord progression, assigns soprano/alto/tenor/bass voices with smooth voice movement (nearest chord tone from previous position), parallel fifth/octave detection and correction, voice range clamping (S:60-81, A:55-74, T:48-67, B:36-62), per-voice velocity, optional voice_spread for wider voicings. Supports maj/min/m7/maj7/dom7/sus2/sus4/dim/aug. Classic Bach chorale style — foundational for vocal harmonies, string arrangements, synth pad layering. Distinct from create_harmony (block chords) and create_counterpoint (2 voices) — chorale assigns 4 independent voices with proper voice leading

  • 304 MCP tools (47 orchestration + 3 melodic variation + 4 transformation)

  • 585 unit tests (+10), E2E 8/8

v1.66.0 (2026-07-05)

  • werkstatt_scratch.js DSP script — DJ vinyl scratch with turntable physics. Triangle LFO drives back-and-forth motion with depth and rate control. Pullback parameter adds backward "yank" at cycle start. Physics model: velocity tracks target with friction coefficient for inertia. Wow (0.5 Hz pitch wobble) and flutter (adjustable 2-30 Hz) for vinyl character. Random crackle pops. Variable-speed readhead with linear interpolation from circular buffer. Classic for turntablism, tape rewind, DJ scratching, lo-fi character. 10 params: depth, rate, pullback, friction, wow, flutter, flutter_rate, crackle, mix, output

  • **57 DSP scripts (44 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 575 unit tests (+10), E2E 8/8

v1.65.0 (2026-07-05)

  • werkstatt_reverse.js DSP script — real-time reverse playback effect with chunked circular buffer. Reverses audio in configurable chunks (0.05-5 sec) with variable speed (0.25x-4x). Three trigger modes: continuous (immediately loop), single (freeze at end), gate (restart on input). Three stereo modes: normal, ping-pong (swap L/R), wide (M/S processing). Feedback for layered reverse textures. Crossfade smoothing for click-free transitions. Classic for backwards cymbals, vocal reverses, psychedelic transitions, tape rewind effects. 10 params: chunk_size, feedback, speed, smooth, dry_gain, wet_gain, mix, stereo_mode, trigger_mode, output

  • 55 DSP scripts (42 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 565 unit tests (+10), E2E 8/8

v1.64.0 (2026-07-05)

  • werkstatt_vocoder.js DSP script — channel vocoder with 8-24 log-spaced bandpass filter bank. Maps modulator (vocal/input) spectral envelope onto a carrier oscillator (saw/square/noise). Per-band envelope followers with adjustable response time and threshold gating. Emphasis control boosts high bands for intelligibility. Output highpass removes rumble. Classic for robotic voice effects, synth vocal textures, Daft Punk-style sounds. 10 params: bands, carrier_wave, carrier_freq, mod_response, mod_threshold, band_q, emphasis, highpass, mix, output

  • 54 DSP scripts (41 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 565 unit tests (+10), E2E 8/8

v1.63.0 (2026-07-05)

  • werkstatt_multiband_comp.js DSP script — 3-band multiband compressor with Linkwitz-Riley 4th order crossovers (24dB/oct). Independent threshold/ratio/attack/release/makeup gain per band (low/mid/high). Crossover frequencies 50-8000 Hz (exponential). Envelope followers per band with peak detection. Classic mastering tool — controls dynamics separately in low/mid/high frequency ranges. 18 params: 2 crossovers + 5 per band × 3 + mix

  • 54 DSP scripts (41 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 565 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.62.0 (2026-07-05)

  • werkstatt_harmonizer.js DSP script — dual-voice harmonizer with independent pitch shift (±12 semitones + ±50 cents), per-voice gain, detune LFO for chorus-like wobble, and delay-based pitch shifting. Creates choir/harmony effects from any input — two shifted voices with micro-detune. Distinct from pitch_shift (single voice) — harmonizer creates multiple harmonized copies. Classic for vocal harmonies, guitar harmonizers, synth thickening. 9 params: 2× shift_semi/cent/gain, detune, delay, mix

  • 54 DSP scripts (41 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 546 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.61.0 (2026-07-05)

  • create_passacaglia orchestration tool (303 MCP tools) — repeating bass ostinato with evolving harmonies above. Baroque form (Bach BWV 582) adapted to modern contexts. 3 variation styles: block (sustained chords), arpeggiated (broken), melodic (stepwise counter-melody). Bass pattern as MIDI pitches + custom rhythm, chord cycling, 3/4 and 4/4 time. Distinct from ostinato (single pattern), pedal_point (single note), bordun (drone chord)

  • 46 orchestration tools total

  • 536 unit tests (+10 passacaglia), E2E 8/8

  • ruff clean, CI green

v1.60.0 (2026-07-05)

  • werkstatt_formant_filter.js DSP script — 3-band parallel formant filter simulating vocal tract resonances. 5 vowel presets (/a/, /i/, /u/, /o/) with smooth interpolation, or manual F1/F2/F3 control. Bandwidth and resonance parameters shape the vocal character. Biquad bandpass filters in parallel. Classic for vocoder-like vocal coloring, talk-box effects, and synth voice synthesis. 9 params: 3 formant freqs, 3 bandwidths, vowel, resonance, mix

  • 51 DSP scripts (38 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 358 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.59.0 (2026-07-05)

  • werkstatt_comb_filter.js DSP script — standalone comb filter with delay-line feedback. Positive/negative polarity selects comb vs inverse comb characteristic. Damping LP in feedback path controls high-frequency decay. Freq 10-8000 Hz (delay time = 1/freq), feedback ±0.99. Classic building block of flangers/chorus, but standalone gives distinctive notched/peaked spectral combing. 5 params: freq, feedback, damping, mix, polarity

  • 50 DSP scripts (37 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 344 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.58.0 (2026-07-05)

  • werkstatt_auto_pan.js DSP script — auto-pan with LFO-driven stereo positioning. Waveform morph (sine→triangle→square), rate (0.1-20 Hz), depth, phase offset (0-360°), width, and offset. Equal-power pan law. Distinct from stereowidth (which expands existing stereo) — auto-pan moves the signal between channels. Classic for guitars, synths, percussion. 6 params: rate, depth, shape, phase, width, offset

  • 49 DSP scripts (36 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 334 unit tests (+10), E2E 8/8

  • ruff clean, CI green

v1.57.0 (2026-07-05)

  • werkstatt_graphic_eq.js DSP script — 10-band graphic EQ with ISO frequency bands (32, 64, 125, 250, 500, 1k, 2k, 4k, 8k, 16k Hz), each ±12 dB gain, plus master output ±6 dB. Biquad peaking filters (Q=1.41, ⅔ octave) in series. Distinct from parametric EQ (fixed bands vs movable). Classic rack-mount EQ for tone shaping, mixing, and live sound. 11 params: 10 bands + master

  • 48 DSP scripts (35 Werkstatt + 7 Apparat + 6 Spielwerk)

  • 324 unit tests (+10 for graphic EQ), E2E 8/8

  • ruff clean, CI green

v1.56.0 (2026-07-05)

  • werkstatt_tape_delay.js DSP script — tape delay with wow (0.5 Hz slow pitch drift) and flutter (15 Hz fast pitch wobble) modulating the delay time, plus saturation in the feedback path for graceful repeat degradation. Fractional delay read for smooth modulation. 6 params: time, feedback, wow, flutter, saturation, mix. Classic for dub, guitar slapback, ambient wash. Completes delay family: stereo ✅ tape ✅

  • werkstatt_graphic_eq.js DSP script — 10-band graphic EQ with ISO frequency bands (32, 64, 125, 250, 500, 1k, 2k, 4k, 8k, 16k Hz), each ±12 dB gain, plus master output ±6 dB. Biquad peaking filters (Q=1.41, ⅔ octave) in series. Distinct from parametric EQ (fixed bands vs movable). Classic rack-mount EQ for tone shaping, mixing, and live sound. 11 params: 10 bands + master

  • 48 DSP scripts (35 Werkstatt + 7 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 11 params, band_1k/band_32/band_16k/master set

  • Example script: werkstatt_tape_delay.py — dub, slapback, ambient wash presets

  • ruff clean, CI green

v1.55.0 (2026-07-05)

  • werkstatt_tube_saturator.js DSP script — tube/valve saturator with asymmetrical transfer curve (even harmonic dominance), warmth control (even/odd blend), bias, post-saturation tone filter, output gain. 6 params: drive, warmth, bias, tone, output, mix. Distinct from tape (darksat) and soft-clip (overdrive). Completes saturation family: tape ✅ overdrive ✅ wavefold ✅ bitcrusher ✅ tube ✅

  • 46 DSP scripts (33 Werkstatt + 7 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 6 params, drive/warmth/bias/tone set

  • Example script: werkstatt_tube_saturator.py — gentle warmth, aggressive crunch, vintage vocal

  • ruff clean, CI green

v1.54.0 (2026-07-05)

  • werkstatt_spring_reverb.js DSP script — spring reverb with dispersive delay lines, transient-driven "boing" chirp response, and 4 detuned springs. Parameters: decay, damp, tension (delay time), boing (transient sensitivity), mix. Classic for surf rock, dub, guitar amps. Completes reverb family: algorithmic ✅ shimmer ✅ spring ✅

  • 45 DSP scripts (32 Werkstatt + 7 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params, decay/tension/boing/damp set

  • Example script: werkstatt_spring_reverb.py — surf rock, dub, tight amp presets

  • ruff clean, CI green

v1.53.0 (2026-07-05)

  • create_isorhythm orchestration tool (302 MCP tools) — repeating rhythm (talea) × repeating pitch (color) as independent cycles. When lengths differ, patterns phase-shift until realigning at LCM. Medieval motets (Machaut), Messiaen, Boulez. Distinct from ostinato (which repeats rhythm+pitch together)

  • E2E verified: equal lengths (24 notes), phase shift 4×5 (LCM=20), single talea, complex rhythm, bad velocity/repeats/pitch/talea — 8/8 tests passed

  • +10 unit tests for isorhythm talea/color independence, phase cycling, position, duration → 282 total

  • Example script: create_isorhythm.py — classic, phase shift, minimalist

  • 45 orchestration tools total

  • ruff clean, CI green

v1.52.0 (2026-07-05)

  • create_hocket orchestration tool (301 MCP tools) — melodic line split between 2-4 voices. Hocket (Latin "hoquet" = hiccup) divides a single melody so each voice plays only part of it, creating interlocking texture. Three split modes: alternate (round-robin), pairs (2 per voice), phrase (4 per voice). Medieval Notre Dame polyphony, African mbira, Balinese gamelan, Steve Reich

  • E2E verified: alternate 2v (8 notes), 3 voices (12 notes), pairs, phrase, bad voices/split_mode/velocity/pitch — 8/8 tests passed

  • +10 unit tests for hocket voice assignment, note preservation, position spacing → 272 total

  • Example script: create_hocket.py — alternate, pairs, phrase patterns

  • 44 orchestration tools total

  • ruff clean, CI green

v1.51.0 (2026-07-05)

  • create_bordun orchestration tool (300 MCP tools) — continuously sustained drone chord as a textural layer. Unlike pedal_point (single anchored note), bordun is a sustained chord — open fifths, octaves, or drone chords. Found in Scottish bagpipes, Indian tanpura, hurdy-gurdy, ambient drone, folk. Configurable intervals (1-8), retrigger mode (every N bars), 3/4 time support

  • E2E verified: open fifth (2 notes), octave+fifth (3 notes), retrigger (4 notes), single drone, 3/4 time, bad root/octave/velocity — 8/8 tests passed

  • +10 unit tests for bordun note generation, pitch mapping, retrigger, duration → 262 total

  • Example script: create_bordun.py — open fifth, octave+fifth, minor triad, single drone

  • 43 orchestration tools total

  • ruff clean, CI green

v1.50.0 (2026-07-05)

  • werkstatt_bitcrusher.js DSP script — standalone bitcrusher with bit-depth quantization (1-16 bits) and sample-rate reduction. Drive, DC offset, dry/wet mix. Dedicated bitcrusher separate from coldfold's combined wavefold+crush

  • 44 DSP scripts (31 Werkstatt + 7 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params (bits/rate/drive/offset/mix), param values set

  • Example script: werkstatt_bitcrusher.py — lo-fi and extreme degradation presets

  • ruff clean, CI green

v1.49.0 (2026-07-05)

  • create_hemiola orchestration tool (299 MCP tools) — 3:2 rhythmic displacement creating cross-rhythm illusion. Fundamental to West African, Afro-Cuban, jazz, and minimalist music. Brahms, Bernstein, Glass. Two patterns: "3:2" (classic) and "2:3" (inverse). Superimposes primary and secondary groups over same time span

  • E2E verified: 3:2 pattern (5 notes), 2:3 pattern (5 notes), bars=2, bad pattern, bad bars, bad velocity, bad pitch, bad duration — 8/8 tests passed

  • +10 unit tests for hemiola note count, ratio, timing, velocity → 242 total

  • Example script: create_hemiola.py — 3:2 and 2:3 patterns

  • 42 orchestration tools total

  • ruff clean, CI green

v1.48.0 (2026-07-05)

  • apparat_wavetable.js DSP script — wavetable synthesizer with 8 interpolated wavetables (sine, triangle, saw, square, pulse, double-sine, saw+tri, noise-sine). Scan position with LFO modulation, unison detune (1-7 voices), ADSR envelope. Completes Apparat synthesis methods: subtractive ✅ FM ✅ ring mod ✅ Karplus-Strong ✅ wavetable ✅

  • 44 DSP scripts (31 Werkstatt + 7 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 10 params, pos/unison/pos_lfo_depth set

  • +10 unit tests (TestWavetableDSP: header, params, tables, scan, unison, ADSR) → 232 total

  • Example script: apparat_wavetable.py — scan + unison presets

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.47.0 (2026-07-05)

  • werkstatt_vibrato.js DSP script — pitch vibrato via modulated delay line. 4 params: rate (0.1-20 Hz, exp), depth (0.5-20 ms), shape (sine→triangle morph), stereo (phase offset 0-1). Completes the modulation family: chorus ✅ flanger ✅ phaser ✅ tremolo ✅ vibrato ✅

  • 42 DSP scripts (30 Werkstatt + 6 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 4 params, rate 5→8, depth 0.003→0.008

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.46.0 (2026-07-05)

  • create_appoggiatura orchestration tool (298 MCP tools) — expressive leaning grace note: approach → main. Fourth and final essential ornament (trill ✅, mordent ✅, turn ✅, appoggiatura ✅). Adjustable ratio, above/below direction. Bach, Mozart, Chopin. Ornaments set complete

  • E2E verified: above, below, equal split, validation — 8/8 tests passed

  • +10 unit tests for appoggiatura order, timing, velocity (374 total)

  • Example script: create_appoggiatura.py — above + below appoggiatura

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.45.0 (2026-07-05)

  • create_turn orchestration tool (298 MCP tools) — circular ornament (gruppetto): main → upper → main → lower → main. Third of four essential ornaments (trill ✅, mordent ✅, turn ✅). Mozart, Beethoven, Bach

  • E2E verified: upper, lower, half-step, validation — 8/8 tests passed

  • +10 unit tests for turn note order, timing, velocity (374 total)

  • Example script: create_turn.py — upper + lower turn

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.44.0 (2026-07-05)

  • create_mordent orchestration tool (298 MCP tools) — classical baroque ornament: main → neighbor → main. Upper/lower direction, adjustable interval. One of four essential ornaments (trill, mordent, turn, appoggiatura). Bach, Mozart

  • E2E verified: upper, lower, half-step, validation, clamped neighbor — 8/8 tests passed

  • +10 unit tests for mordent neighbor direction, timing, velocity (374 total)

  • Example script: create_mordent.py — upper + lower mordent

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.43.0 (2026-07-05)

  • create_comping orchestration tool (298 MCP tools) — rhythmic chordal accompaniment. Jazz piano comping, funk guitar chops, reggae skanks, country boom-chick, neo-soul. Rhythm grid (x/play, -/rest, ./ghost), syncopation, chord JSON parsing. One call replaces 20-80 manual note creations

  • E2E verified: jazz comping (64 notes), funk with ghosts, reggae skank (16 steps), syncopation, validation — 8/8 tests passed

  • +10 unit tests for comping generation, ghost velocity, rhythm parsing (374 total)

  • Example script: create_comping.py — jazz ii-V-I with syncopation

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.42.0 (2026-07-05)

  • augment_notes transformation tool (298 MCP tools) — augmentation/diminution: the fourth classical motivic transformation. Multiplies note durations by a factor (0.25-4.0). Two modes: "scale" (phrase slows down/speeds up) and "stretch" (durations only). Completes the four fundamental transformations: transpose, reverse, invert, augment. Think Beethoven 5th recapitulation

  • E2E verified: augmentation x2 (5 notes), diminution x0.5 (8 notes), stretch mode, no-op, validation — 8/8 tests passed

  • +10 unit tests for factor validation + duration math (374 total)

  • Example script: augment_notes.py — augmentation + diminution on C major scale

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.41.0 (2026-07-05)

  • create_canon orchestration tool (298 MCP tools) — strict melodic imitation with delayed voice entries. The foundation of contrapuntal music: Pachelbel's Canon, "Row Row Row Your Boat", Bach fugue subjects, film score layering. Unlike create_counterpoint (generates a new line), a canon copies the SAME melody into each voice — just shifted in time and pitch. 2-6 voices, per-voice transposition, velocity decay, up/down entry order. One call replaces 16-48 manual note creations. Essential for: rounds, fugues, film scores, call-and-response layering, minimalism

  • E2E verified: 3-voice canon (24 notes), 2-voice round (8), direction=down (12), 4-voice (24), bad voices, transposition mismatch, bad direction, start_beat offset — 8/8 tests passed

  • +10 unit tests for canon voice generation + transposition + direction + clamping (374 total)

  • Example script: create_canon.py — 4-voice Pachelbel-style canon with fifth/octave transpositions

  • 298 MCP tools (260 low-level + 41 orchestration + 3 melodic)

  • ruff clean, CI green

v1.40.0 (2026-07-05)

  • create_pedal_point orchestration tool (292 MCP tools) — sustained bass note under changing chords. The foundational technique in film scoring (Hans Zimmer drones), organ preludes (Bach), and rock ballads. Retrigger or sustained pedal mode. Full chord name parsing (maj/min/m7/maj7/dom7/sus2/sus4/dim/aug + implicit major). Adjustable time signatures (3/4, 4/4, 6/8). One call replaces 13-34 manual note creations. Essential for: film scoring, organ music, rock ballads, ambient drones, harmonic tension

  • E2E verified: retriggered (16 notes), sustained (13), 7th chords (15), 2 bars per chord, 3/4 waltz, sus4, error handling — 8/8 tests passed

  • +10 unit tests for pedal point generation + chord parsing (314 total)

  • Example script: create_pedal_point.py — 5 pedal points (retriggered, sustained, jazz 7ths, slow, waltz)

  • 292 MCP tools (254 low-level + 35 orchestration + 3 melodic)

  • ruff clean, CI green

v1.39.0 (2026-07-05)

  • create_sequence orchestration tool (291 MCP tools) — transposed melodic repetition. The most fundamental compositional technique in Western music: repeat a melodic fragment at different pitch levels. 3 directions (up/down/alternating). Adjustable transposition (semitones, 5=4th, 7=5th), repeats (1-8), velocity decay (fade-out/build-up). One call replaces 8-32 manual note creations. Essential for: baroque sequences, jazz ii-V-I chains, film score builds, EDM build-ups, classical development sections

  • E2E verified: ascending 4th (12 notes), descending 2nd (16 notes), alternating 5th (9 notes), velocity decay, single repeat, error handling — 8/8 tests passed

  • +9 unit tests for sequence pattern generation (304 total)

  • Example script: create_sequence.py — 5 sequences (baroque, jazz, film score, fade-out, rising quint)

  • 291 MCP tools (254 low-level + 34 orchestration + 3 melodic)

  • ruff clean, CI green

v1.38.0 (2026-07-05)

  • create_glissando orchestration tool (290 MCP tools) — smooth scale run between two pitches. 6 scale types (chromatic/major/minor/pentatonic_minor/pentatonic_major/whole_tone). 5 rates (32nd/16th/8th/32t/16t). 4 velocity curves (flat/ramp_up/ramp_down/arc). Ascending or descending. Unlike riser/bass_drop (pitch sweeps), glissando plays every intermediate scale tone. One call replaces 6-13 manual note creations. Essential for: transitions, fills, classical ornamentation, jazz runs, dramatic effects

  • E2E verified: chromatic asc (13 notes), major (8), descending (13), pentatonic minor (6), whole tone (7), velocity arc, error handling — 8/8 tests passed

  • +12 unit tests for glissando pattern generation (295 total)

  • Example script: create_glissando.py — 5 glissandi across scales

  • 290 MCP tools (254 low-level + 33 orchestration + 3 melodic)

  • ruff clean, CI green

v1.37.0 (2026-07-05)

  • create_trill orchestration tool (289 MCP tools) — rapid two-note alternation ornament. 5 rates (32nd/16th/8th/32t/16t triplet). Upper note accent (baroque style), start on upper or lower. Works for classical trills, jazz shakes, metal tremolo picking, electronic LFO patterns. One call replaces 4-64 manual note creations. Essential for: baroque ornaments, jazz phrasing, tremolo effects, ornamentation

  • E2E verified: default 16th (16 notes), 32nd (64 notes), 8th (4 notes), triplet 16th (24 notes), start_with_upper, no_accent, error handling — 8/8 tests passed

  • +11 unit tests for trill pattern generation (283 total)

  • Example script: create_trill.py — 5 trills across genres (baroque, fast, slow, jazz shake, minor 3rd)

  • 289 MCP tools (254 low-level + 32 orchestration + 3 melodic)

  • ruff clean, CI green

v1.36.0 (2026-07-05)

  • create_chop orchestration tool (288 MCP tools) — slice source pitches into segments and rearrange. 5 modes: reverse (Dilla flip), stutter (glitch repeat), shuffle (Madlib random), ping-pong (ABBA), gate (chopped break). Octave shift for bass chops, velocity variation for human feel, inner-pitch reverse for nested chops. One call replaces 8-48 manual note creations. Essential for: hip-hop sampling, glitch-hop, bass music, sample flip workflows

  • E2E verified: reverse (4 notes), stutter x3 (12 notes), shuffle (5 notes), ping-pong (8 notes), gate (3 notes), octave shift, error handling — 8/8 tests passed

  • +13 unit tests for chop pattern generation (285 total)

  • Example script: create_chop.py — 6 chops across 48 beats (reverse, stutter, shuffle, ping-pong, gate, bass chop)

  • 288 MCP tools (254 low-level + 31 orchestration + 3 melodic)

  • ruff clean, CI green

v1.35.0 (2026-07-05)

  • create_bass_drop orchestration tool (287 MCP tools) — descending pitch sweep into sustained sub bass for dubstep/EDM/trap. Two phases: sweep (16th-note resolution pitch glide) + hold (sustained landing note). 3 curves (linear/exp/log), adjustable sweep (0.25-8 beats) and hold (0-16 beats). Complement to create_riser — riser builds up, bass drop lands. One call replaces 10-65 manual note creations. Essential for: dubstep drops, EDM build-and-drop, trap bass falls, impact transitions

  • E2E verified: default drop (33 notes, 32 sweep + 1 hold), sweep-only (64 notes), short aggressive (9 notes), error handling

  • 287 MCP tools (254 low-level + 30 orchestration + 3 melodic)

  • ruff clean, CI green

v1.34.0 (2026-07-05)

  • create_break orchestration tool (287 MCP tools) — classic drum break patterns for jungle/DnB/hip-hop/breakbeat. 6 presets: Amen Break, Think Break, Ashanti, Funky Drummer, When the Levee, Synthetic. 1-8 bars with variation modes (none/fill/humanize/drop) and swing. One call replaces 15-120 manual note creations. Essential for: breakbeat-based genres, sampling workflows, drum programming

  • E2E verified: Amen (14 notes), Think 2-bar fill (26 notes), Funky Drummer humanized (22 notes), Amen 2-bar drop (25 notes), Synthetic with swing (14 notes), error handling

  • 287 MCP tools (254 low-level + 30 orchestration + 3 melodic)

  • ruff clean, CI green

v1.33.0 (2026-07-05)

  • create_stab orchestration tool (287 MCP tools) — rhythmic chord stabs for house/disco/funk. Grid pattern with 'x' (stab), '-' (rest), '.' (ghost). Cycles through chord progressions. Adjustable octave, velocity, stab duration, pattern length. Ghost stabs use 45% velocity and shorter duration. One call replaces 20-60 manual note creations. Essential for: house off-beat stabs, funk syncopated punches, garage/shuffle patterns

  • E2E verified: house Cm7 off-beat (16 notes, 4 stabs), funky F7/Cm7 with ghost notes (28 notes, 7 hits), all-rests error, invalid rhythm error

  • 287 MCP tools (254 low-level + 30 orchestration + 3 melodic)

  • ruff clean, CI green

v1.32.0 (2026-07-05)

  • create_riser orchestration tool (284 MCP tools) — ascending pitch sweep for build-up transitions. 3 curves (linear, exp, log). Adjustable pitch range (MIDI 0-127), step count (8-128), length (0.25-16 beats). Velocity ramps up proportionally. One call replaces 10-50 manual note creations. Essential for: build-ups before drops, section transitions, tension creation

  • E2E verified: 32 notes, pitch 36→84, exp curve ascending, linear curve 16 notes, error handling

  • 287 MCP tools (254 low-level + 30 orchestration + 3 melodic)

  • ruff clean, CI green

v1.31.0 (2026-07-05)

  • werkstatt_stereowidth.js — M/S stereo width processor. 5 params: width (0=mono, 0.5=neutral, 1.5=wide), lowTrim (mono bass below crossover), lowFreq (50-500Hz crossover), mix, output. M/S encode → width scaling on side → low-freq trim → M/S decode. Essential for mastering: wide highs, mono bass

  • 41 DSP scripts (29 Werkstatt + 6 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params, width 0.5→1.2, lowTrim 0→0.7

  • ruff clean, CI green

v1.30.0 (2026-07-05)

  • apparat_pluck.js — Karplus-Strong plucked string synth. 7 params: decay (string decay rate), damping (lowpass strength), brightness (noise burst spectral content), attack, release, detune, volume. Noise burst excites delay line, averaging filter creates natural string decay. Unique physical modeling sound unavailable in other Apparat scripts

  • 40 DSP scripts (28 Werkstatt + 6 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 7 params, brightness 0.7→0.9, code header readback OK

  • ruff clean, CI green

v1.29.0 (2026-07-05)

  • werkstatt_transient.js — transient shaper with dual envelope followers. 4 params: attack (±12 dB transient boost/cut), sustain (±12 dB sustain boost/cut), mix, output. Fast envelope (~5ms) detects transients, slow envelope (~80ms) detects sustain, independent gain on each component. No threshold needed — works on any material. Essential for drum mixing

  • 39 DSP scripts (28 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 4 params, attack 0.5→0.8, sustain 0.5→0.3

  • ruff clean, CI green

v1.28.0 (2026-07-05)

  • werkstatt_deesser.js — dynamic de-esser, band-split architecture. 7 params: freq (2-12kHz crossover), threshold (-40..0 dB), ratio (1:1..10:1), attack, release, mix, output. 2nd-order Linkwitz-Riley HPF isolates sibilance, envelope-followed gain reduction on high band only. Completes vocal chain: EQ → compressor → de-esser → exciter → limiter

  • 38 DSP scripts (27 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 7 params, threshold 0.5→0.65, freq 0.4→0.8

  • ruff clean, CI green

v1.27.0 (2026-07-05)

  • werkstatt_exciter.js — harmonic exciter with band-split architecture. 5 params: freq (crossover 800Hz-12kHz), harmonics (0-1), drive (0-1), mix (0-1), output (±24 dB). Cascaded one-pole HPF isolates highs, cubic nonlinearity adds odd harmonics, parallel wet/dry. Completes mastering chain: EQ → compressor → exciter → limiter

  • 37 DSP scripts (26 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params, freq 0.3→0.75, harmonics 0.5→0.85

  • ruff clean, CI green

v1.26.0 (2026-07-05)

  • werkstatt_limiter.js — brickwall limiter with lookahead buffer + TPDF dither. 5 params: ceiling (0-1), release (10-500 ms), lookahead (0.1-5 ms), dither (TPDF on/off), mix. Instant attack, smooth release, circular lookahead buffer. Completes dynamics chain: compressor → limiter. Essential for mastering

  • werkstatt_exciter.js — harmonic exciter with band-split architecture. 5 params: freq (crossover 800Hz-12kHz), harmonics (0-1), drive (0-1), mix (0-1), output (±24 dB). Cascaded one-pole HPF isolates highs, cubic nonlinearity adds odd harmonics, parallel wet/dry. Completes mastering chain: EQ → compressor → exciter → limiter

  • 37 DSP scripts (26 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params, freq 0.3→0.75, harmonics 0.5→0.85, code header readback OK

  • ruff clean, CI green

v1.25.1 (2026-07-05)

  • +31 unit tests for music_theory functions — parse_melody_pattern (11 tests: ascending, rests, timing, velocity, scales, octaves, sharps, empty pattern), scale_to_pitches (6 tests: major, minor, length extension, octave, dorian, phrygian), chord_to_pitches (8 tests: triads, sevenths, diminished, sus4, octave, sharps), GENRE_PRESETS (6 tests: known genres, bpm/drums fields, bpm ranges)

  • 316 unit tests total (was 241), all passing

  • ruff clean, CI green

v1.25.0 (2026-07-05)

  • werkstatt_paraeq.js — 3-band parametric EQ + HP/LP filters. 12 params: 3 × (freq, gain ±18 dB, Q 0.1-6) + hp_freq + lp_freq + mix. Biquad filters (RBJ Audio EQ Cookbook). Signal chain: HP → Band1 → Band2 → Band3 → LP. Closes critical EQ gap — parametric EQ is fundamental to mixing, was the most requested missing DSP category

  • 35 DSP scripts (24 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 12 params with correct defaults, band1_gain 0→6 dB, band2_q 1→3.5, code header readback OK

  • ruff clean, CI green

v1.24.0 (2026-07-05)

  • werkstatt_compressor.js — soft-knee peak compressor. 7 params: threshold (0→-60 dB), ratio (1:1→20:1), attack (0.1→100 ms log), release (50→500 ms log), makeup (0→+24 dB), mix (dry/wet), knee (0→12 dB soft knee). Peak detection, one-pole envelope smoother, stereo-linked. Closes the biggest DSP gap — compressor is fundamental to mixing

  • Integration test fixtest_integration.py now skips when Playwright chromium is unavailable instead of failing. Checks both DAW reachability and browser availability

  • 34 DSP scripts (23 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 7 params with correct defaults, threshold 0.5→0.75, ratio 0.4→0.85, code header readback OK

  • ruff clean, CI green

v1.23.3 (2026-07-05)

  • werkstatt_multifilter.js — multi-mode SVF filter (Chamberlin topology). 4 modes: lowpass, highpass, bandpass, notch. 5 params: mode, cutoff (20-20kHz), resonance, drive, mix. Closes critical gap — standalone multi-mode filter was missing while allpass/dcremover existed

  • 34 DSP scripts (23 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params with correct defaults, mode switching (LP→HP), resonance cranked (0.3→0.8)

  • ruff clean, CI green

v1.23.2 (2026-07-05)

  • werkstatt_overdrive.js — asymmetric soft-clip overdrive (tube-like). 5 params: drive, tone, level, bias, dry. Asymmetric clipping = even harmonics = warmth. Pre-HP filter removes mud, post-LP tone control, dry blend for parallel overdrive

  • 32 DSP scripts (21 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 5 params with correct defaults, set_param works (drive 0.4→0.8, dry 0→0.3)

  • ruff clean, CI green

v1.23.1 (2026-07-05)

  • werkstatt_stereo_delay.js — stereo delay with ping-pong, feedback, tone filter. 6 params: time_l, time_r, feedback, tone, mix, pingpong. Fill gap — delay was missing from DSP library while reverb/chorus/flanger/phaser all present

  • 31 DSP scripts (20 Werkstatt + 5 Apparat + 6 Spielwerk)

  • E2E verified: compiled via ScriptCompiler, 6 params created with correct defaults, set_param works (feedback 0.35→0.6, pingpong 0→1.0)

  • ruff clean, CI green

v1.23.0 (2026-07-05)

  • apply_articulation — staccato/legato/tenuto/accent for existing notes. Duration reshaping for phrasing character (staccato=short, legato=connected, tenuto=full slot, accent=velocity boost on downbeats). Deterministic, not random

  • 13 unit tests for articulation math (staccato ratio, legato overlap, tenuto slot fill, accent boost) — 228→241 total

  • E2E verified: staccato (240→120, 8 notes), legato (240→228, 95% fill), accent (beats boosted to 0.9, off-beats stay 0.5)

  • 58 examples (added apply_articulation.py)

  • 283 MCP tools, 26 orchestration tools, ruff clean, CI green

v1.22.0 (2026-07-05)

  • apply_velocity_curve — deterministic velocity envelope across notes (ramp_up/ramp_down/arc/trough/power). Unlike humanize (random), this applies a mathematical curve shape — build-ups, fade-ins, crescendo rolls, expressive phrasing. Power exponent for exponential curves

  • 15 unit tests for velocity curve interpolation (ramp, arc, trough, power) — 213→228 total

  • E2E verified: ramp_up (0.2→1.0, 16 notes), arc (peak at middle=0.95), power=2.0 (slow rise, mid=0.36)

  • 54 examples (added apply_velocity_curve.py)

  • 282 MCP tools, 25 orchestration tools, ruff clean, CI green

v1.21.0 (2026-07-05)

  • apply_sidechain — sidechain ducking via volume automation. Classic pumping/breathing effect for house/techno/EDM. Adjustable depth, attack, release, kick interval

  • create_ghost_notes — ghost notes (quiet grace notes) for funk/R&B/neo-soul/hip-hop drumming. Seeded reproducibility, avoids occupied positions

  • 12 unit tests for sidechain ducking curve and ghost note placement logic — 201→212 total

  • E2E verified: sidechain (272 events, 16 kicks, error handling), ghost_notes (4 added, error handling)

  • 53 examples (added apply_sidechain.py, create_ghost_notes.py)

  • 281 MCP tools, 24 orchestration tools, ruff clean, CI green

v1.20.0 (2026-07-05)

  • create_call_response — call-and-response patterns (antecedent/consequent phrases). Foundation of blues, jazz, hip-hop, electronic. Alternates call → response with adjustable repeats

  • create_walking_bass — walking bass lines over chord progressions. Beat 1=chord root, beat 2=chord tone, beat 3=passing tone, beat 4=approach note. Jazz/blues/swing

  • 11 unit tests for call_response (interleave, timing, velocity) and walking_bass (beat positions, approach notes, bass range) — 190→201 total

  • E2E verified: call_response (blues ×4, error handling), walking_bass (ii-V-I, 12-bar blues, 2 bars/chord, error handling)

  • 51 examples (added create_call_response.py, create_walking_bass.py)

  • 279 MCP tools, 22 orchestration tools, ruff clean, CI green

v1.19.1 (2026-07-05)

  • create_scale_run — ascending/descending scale sequences for fills, transitions, build-ups. 14 scales, 1-4 octaves

  • 8 unit tests for scale run generation (major/minor/blues/chromatic/pentatonic, multi-octave, direction)

  • E2E verified: C minor up 1 oct (8 notes), A blues down 2 oct (13 notes), error handling

  • 277 MCP tools, 20 orchestration tools, ruff clean, CI green

v1.19.0 (2026-07-05)

  • apply_swing — pure swing feel for existing notes, deterministic, no randomness. 16th/8th grid, 0-1 depth. 0.58 = classic hip-hop/lofi swing

  • create_polyrhythm — polyrhythms: two streams with different subdivision counts (3:4, 2:3, 5:7, 7:8). Jazz, electronic, progressive, math rock

  • 12 unit tests for swing offset logic and polyrhythm generation (170→182 total)

  • E2E test for apply_swing (0.5/0.0/8th grid) and create_polyrhythm (3:4, 2:3, error handling)

  • 30 DSP scripts (added flanger, noisegate, tremolo)

  • 281 MCP tools, 24 orchestration tools, ruff clean, CI green

v1.18.0 (2026-07-05)

  • create_drum_fill — drum fills/transitions: 5 types (build, break, roll, crash, tom), adjustable density and bar length

  • create_ostinato — repeating melodic/rhythmic pattern as foundation layer, scale-based, 1-16 repeats

  • create_crescendo — crescendo/decrescendo on existing notes, 3 curves (linear, exp, log)

  • E2E verified: drum_fill (build+roll), ostinato (C minor ×4), crescendo (exp 0.2→0.9)

  • 276 MCP tools, 19 orchestration tools, ruff clean, CI green

v1.17.0 (2026-07-05)

  • create_counterpoint — new orchestration tool: generate counter-melody in contrary motion. Mirrors melody around center pitch. Auto-creates target track.

  • humanize_notes — new orchestration tool: velocity/timing/duration variation + swing. Seeded mulberry32 PRNG for reproducibility.

  • create_harmony — new orchestration tool: generate harmony from existing notes. 8 intervals (diatonic thirds/fifths/sixths + chromatic). Up/down direction.

  • reverse_notes — melodic variation: retrograde (reverse note order in region)

  • invert_notes — melodic variation: mirror inversion around axis pitch (newPitch = 2*axis - oldPitch)

  • suno-prompt-engineering skill — concentrated Suno prompt engineering guide from 20+ KB files

  • 7 new examples: create_melody, create_bassline, create_arpeggio, humanize_notes, create_harmony, create_counterpoint, reverse_invert_notes

  • TOOL_CATALOG: all 27 DSP scripts documented (was 7)

  • KB index sync: 31→33 entries (all files covered)

  • bridge.py: PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH env var for system chromium

  • 271 MCP tools, 43 examples, 9 skills, ruff clean, CI green

v1.16.1 (2026-07-05)

  • create_melody — new orchestration tool: generate melodies from scale + rhythmic pattern using scale degrees (1-7). Supports 14 scales, rests, sustains, octave shifts. One call replaces 10-30 create_note calls.

  • create_bassline — new orchestration tool: generate basslines from root + rhythmic pattern. Low octave default (C2=36), high velocity (0.9), octave up/down (+/_). One call replaces 8-20 create_note calls.

  • create_arpeggio — new orchestration tool: generate arpeggios from chord name with 6 patterns (up/down/updown/downup/random/chord) and 6 rates. One call replaces 8-32 create_note calls.

  • opendaw_mcp/music_theory.py — shared music theory module: NOTE_TO_PITCH, CHORD_INTERVALS, SCALE_INTERVALS, GENRE_PRESETS, chord_to_pitches(), scale_to_pitches()

  • DRY refactor: create_chord_progression and create_genre_track now import from music_theory instead of duplicating dicts inline

  • 2 new genres: coldwave (110 BPM, dark bass, Dm-Fmaj-Gmin-Amin) and hiphop (90 BPM, boom bap, Cm7-Ebmaj7-Gmin7-Bbmaj7) — create_genre_track now supports 8 genres

  • Scales: 14 scale types (major, minor, harmonic minor, melodic minor, dorian, phrygian, lydian, mixolydian, locrian, pentatonic major/minor, blues, chromatic)

  • 38 new unit tests (test_music_theory.py) — 150 total

  • ruff clean, 264 MCP tools intact, no regressions

v1.16.0 (2026-07-05)

  • Modular architecture — infrastructure extracted from 13K-line server.py into opendaw_mcp/ package:

    • constants.py — lookup tables (TIDAL_RATE_MAP, DELAY_SYNC_MAP, WAVESHAPER_FUNCS, REVAMP_SECTIONS)

    • bridge.pyHeadlessDawBridge class (Playwright bridge, DAW_HELPERS injection)

    • utils.py — pure-Python helpers (_parse_wav, _compute_lufs, _ok, _err, _safe_filename, _safe_path, _clamp_script_param)

    • __init__.py — public API, all symbols re-exported for backward compat

  • OpendawServer facade — class providing bridge + all mcp_opendaw_* tools as methods. Framework wrappers (LangChain, AutoGen, CrewAI) now work via this single interface.

  • server.py: 13244 → 12955 lines (infrastructure moved to package modules)

  • 0 regressions — 316 unit tests pass, ruff clean, all framework wrappers functional, 283 MCP tools intact

v1.15.2 (2026-07-04)

  • CrewAI toolkitopendaw_mcp/crewai_tools.py wraps 27 tools for CrewAI. Custom OpendawCrewAITool class, category filtering, shared server instance.

  • GitHub Discussions seeded — 5 discussions: release announcement, 3 FAQ (bridge, GPU, MCP clients), genre showcase

  • 33 examples total (added crewai_integration.py)

v1.15.1 (2026-07-04)

  • AutoGen toolkitopendaw_mcp/autogen_tools.py wraps 27 tools for Microsoft AutoGen. Category filtering, shared server instance.

  • Framework integration docs page — LangChain + AutoGen + MCP direct + Hermes, with comparison table

  • 32 examples total (added autogen_integration.py)

v1.15.0 (2026-07-04)

  • LangChain toolkitopendaw_mcp/langchain_tools.py wraps 30+ tools as LangChain StructuredTool objects. Category filtering, auto bridge start. Use with any LangChain agent.

  • AutoGen toolkitopendaw_mcp/autogen_tools.py wraps 27 tools for Microsoft AutoGen. Category filtering, shared server instance.

  • Docs site — mkdocs-material at https://ameobius.github.io/opendaw-mcp/ — 21 pages, dark mode, search, auto-deploy via GitHub Actions

  • PR template — structured checklist for contributors

  • PyPI metadata — Documentation, Issues, Changelog URLs pointing to docs site

  • dev.to article — "Controlling a DAW with AI Agents via MCP" (in promotion/)

  • 32 examples total (added langchain_integration.py, autogen_integration.py)

v1.14.4 (2026-07-04)

  • Final 2 genre examples (E2E verified): genre_lofi.py (82 BPM, swung drums, jazzy ii-V-I, warm) and genre_trap.py (145 BPM, fast hi-hat rolls, gliding 808, dark minor). All 8 genres from the skill now covered with E2E examples. 30 examples total.

v1.14.3 (2026-07-04)

  • 3 more genre examples (E2E verified): genre_hiphop.py (85 BPM, boom bap, 808 Ab minor), genre_dnb.py (174 BPM, Amen break, reese+sub F minor), genre_house.py (124 BPM, 4-on-floor, off-beat chord stabs Fmin9-Cmin9-Gmin9-Dmin9). 28 examples total, 6 genres covered.

v1.14.2 (2026-07-04)

  • 2 new genre examples (E2E verified): genre_coldwave.py (100 BPM, Am-Fmaj7-Cmaj-Gdom7, 4 tracks, Dattorro+Waveshaper) and genre_ambient.py (70 BPM, Cmaj7-Amin7-Fmaj7-Gmaj7, pad+bell+texture, long reverbs). 25 examples total.

  • Fixed return key names in genre examples (notes_created / total_notes / lanes)

v1.14.1 (2026-07-04)

  • opendaw-genres skill — 8 genre templates with concrete parameters: techno, coldwave, hip-hop, ambient, DnB, house, lofi, trap. BPM, track layout, drum patterns, bass lines, chord progressions, effect chains, pan, LUFS targets. Not theory — actual tool calls and values. 10 skills total.

v1.14.0 (2026-07-04)

  • 2 new agent skills: suno-to-opendaw (6-stage Suno→stems→openDAW→mix→master→export pipeline) and dsp-script-authoring (custom Werkstatt/Apparat/Spielwerk DSP script writing guide with patterns, validation, pitfalls). 7 skills total.

  • set_marker_repeat MCP tool (v1.13.1) — marker repeat count control (0=infinite)

  • 283 MCP tools (254 low-level + 26 orchestration)

v1.13.0 (2026-07-04)

  • Preset Management: 2 new MCP tools for openDAW preset format (.opb). save_effect_preset encodes any audio effect chain into a shareable .opb bundle via PresetEncoder.encodeEffects. load_effect_preset decodes .opb and applies it to a project. Enables agent-driven preset creation and reuse.

  • 5 Werkstatt presets published to upstream (PR #284): Dark Saturation, Plate Reverb, Cold Fold Distortion, Stereo Phaser, Stereo Chorus.

  • 283 MCP tools (254 low-level + 26 orchestration)

v1.12.1 (2026-07-04)

  • Stem Splitter: 2 new MCP tools for SOTA open-source source separation. split_stems runs 7 modes locally on GPU (ensemble, scnet, bs6, polarformer, dereverb, drumsep, denoise). Optional auto-import into DAW. Uses BS-Roformer, HTDemucs FT, SCNet XL, MelBand Roformer models.

  • list_split_modes — list all separation modes with SDR scores

  • 283 MCP tools (254 low-level + 26 orchestration)

v1.12.0 (2026-07-04)

  • Agent Skills: 10 structured skill files in skills/ directory — adaptive mix→master, suno-to-opendaw (Suno→stems→mix→master E2E), dsp-script-authoring (custom DSP), opendaw-genres (8 genre templates), opendaw-automation (283 tools, 146 ref files), track architecture, sound design, effect routing, composition patterns. Decision points for genre-adaptive workflows. Agent-agnostic.

  • 41 DSP scripts total (29 Werkstatt + 6 Apparat + 6 Spielwerk)

v1.11.9 (2026-07-04)

  • CodeRabbit fixes: reverb stereo width (separate L/R comb banks with decorrelated delay times, M/S width on reverb tail), paulstretch cursor split (independent read/write cursors, proper frame emission gating)

  • 41 DSP scripts total (29 Werkstatt + 6 Apparat + 6 Spielwerk)

v1.11.8 (2026-07-04)

  • New Werkstatt script: ring modulator with envelope-followed frequency modulation (#277) — workaround for MIDI input limitation in Werkstatt audio effects

  • 41 DSP scripts total (29 Werkstatt + 6 Apparat + 6 Spielwerk)

v1.11.7 (2026-07-04)

  • Suno→openDAW pipeline example: import AI-generated track, add mastering chain (tape sat + lookahead comp), reverb send bus, MIDI arp layer, render + stems + LUFS

v1.11.6 (2026-07-04)

  • 4 new Spielwerk MIDI effect scripts: chord memory, strummer, velocity scaler, MIDI delay

  • 1 new Python example: Suno→openDAW pipeline (import AI track, mastering chain, reverb send, arp layer, render+stems)

  • 41 DSP scripts total (29 Werkstatt + 6 Apparat + 6 Spielwerk)

v1.11.5 (2026-07-04)

  • 7 new DSP scripts: DC remover + stereo width (#91), allpass filter (#133), 2-operator FM synth (#138), chord memory, strummer, velocity scaler, MIDI delay

  • Coldfold fix: removed unused range variable (CodeRabbit review)

  • 41 DSP scripts total (29 Werkstatt + 6 Apparat + 6 Spielwerk)

v1.11.4 (2026-07-04)

  • 1 new Apparat script: ring modulator synth with ADSR and sub-oscillator (#277)

  • 18 DSP scripts total (12 Werkstatt + 4 Apparat + 2 Spielwerk)

v1.11.3 (2026-07-04)

  • 1 new Werkstatt script: real-time pitch shifter via delay-line sweep (#188)

  • Ruff lint fixes: removed unused imports/variables in examples and midi_parser

  • 17 DSP scripts total (12 Werkstatt + 3 Apparat + 2 Spielwerk)

v1.11.2 (2026-07-04)

  • 10 DSP bug fixes synced from upstream PR #283 CodeRabbit review:

    • darksat: undefined outR variable fix, DC blocker signal path corrected

    • chorus: delay buffer 2× for depth modulation, safe modulo for negative indices

    • coldfold: slew parameter /100 scaling removed (was disabling the parameter)

    • lookahead: gain reduction now applied to delayed signal (true lookahead)

    • reverb: comb filter indices advancing, per-comb damping state, M/S stereo width decode

    • shimmer: per-channel pitch shifter state (eliminates stereo crosstalk)

    • phaser: stable 1st-order allpass topology (2nd-order was unstable)

    • subcrusher: bidirectional glide (was diverging on upward glides)

    • arpeggiator: swing notes no longer dropped at block boundaries

  • 14 DSP scripts total (9 Werkstatt + 3 Apparat + 2 Spielwerk) — all CodeRabbit issues addressed

  • 2 new Werkstatt scripts: ADSR trim (sustained sample trimming, #241) + granular time-stretch (Hann window overlap + pitch shift, #201)

  • 1 new Werkstatt script: real-time pitch shifter via delay-line sweep (#188)

  • 1 new Apparat script: ring modulator synth with ADSR and sub-oscillator (#277)

  • 18 DSP scripts total (12 Werkstatt + 4 Apparat + 2 Spielwerk)

v1.11.1 (2026-07-04)

  • Scriptable device mapping infolist_script_params now returns full @param mapping metadata (min, max, mapping type, unit) via ScriptDeclaration.parseParams()

  • Range validationset_script_param now validates values against @param declarations: bool snaps to 0/1, int rounds+clamps, linear/exp clamps to [min, max]. Returns clamped flag and range info

  • _clamp_script_param Python helper mirrors JS-side clamping logic

  • +15 unit tests (93 total) — TestScriptParamClamping: linear/exp/int/bool/unipolar clamping, rounding, snapping

  • +6 integration E2E tests — bridge startup, globals, track ops, scriptable compile, param clamping, latency benchmark (avg 4ms round-trip)

  • 5 new Werkstatt DSP scripts — reverb (Schroeder plate), chorus (stereo dual-LFO), phaser (allpass cascade), lookahead compressor (soft knee), shimmer delay (granular pitch shift). Total: 12 scripts

  • DAW_ScriptDeclaration added to headless-daw globals

v1.11.0 (2026-07-04)

  • apply_mix_preset — 8th orchestration tool: batch volume/pan/mute/solo across all tracks. Named presets (lofi, house, balanced, wide) or custom JSON

  • 258 MCP tools (252 low-level + 8 orchestration)

v1.10.2 (2026-07-04)

  • 24 new unit tests for orchestration tools (78 total) — curve interpolation, chord theory, drum pattern parsing, song structure parsing

  • TOOL_CATALOG fully synchronized — 0 discrepancies with server.py

v1.10.1 (2026-07-04)

  • 258 MCP tools (253 low-level + 7 orchestration)

  • create_song_structure — arrangement markers (intro/verse/chorus/bridge/outro) from JSON section list

  • automation_sweep — smooth automation ramps with linear/exp/log curves. Replaces 10-30 create_automation_event calls

  • PyPI v1.10.1 publishedpip install opendaw-mcp

  • Both orchestration tools tested end-to-end via Playwright bridge

  • 54 tests, ruff clean, CI green

v1.10.0 (2026-07-04)

  • 7 orchestration tools — high-level composers for agents:

    • create_notes_batch — batch MIDI note creation (JSON array, one round-trip)

    • create_drum_pattern — step-sequencer notation (x...x... → drum beat)

    • create_chord_progression — chord names → auto-voiced notes ([["C","min7"]])

    • add_mastering_chain — EQ + Compressor + Maximizer with style presets

    • create_genre_track — full genre starting point (house/techno/lofi/dnb/trap/ambient)

    • create_song_structure — arrangement markers from JSON

    • automation_sweep — smooth parameter ramps with linear/exp/log curves

  • 258 total tools (250 low-level + 7 orchestration + 1 internal)

  • set_metronome — dedicated metronome control (enabled, gain, beat_subdivision)

  • Module-level lookup tables — TIDAL_RATE_MAP, DELAY_SYNC_MAP, WAVESHAPER_FUNCS, REVAMP_SECTIONS extracted for testability

  • +23 new unit tests (54 total) — fraction maps, waveshaper funcs, revamp sections, safe_filename edge cases

  • Official ScriptCompiler migrationset_script_device_code now uses the real ScriptCompiler from @opendaw/studio-adapters instead of custom @param/@sample parser. Benefits: declaration caching (WeakMap), proper sample file cleanup, label parsing, correct worklet wrapping

  • Stems export fixuseInstrumentOutput changed from True→False. Stems now route through channel strip (effects, sends, volume/pan) as documented by naomiaro/opendaw-test

  • export_dry_stem — new tool for freeze/flatten/re-amp workflows: captures raw instrument output before effects

  • set_waveshaper_equation — 6 transfer functions (hardclip/cubicSoft/tanh/sigmoid/arctan/asymmetric)

  • set_crusher_crush — sample-rate reduction with documented crush inversion semantics

  • set_revamp_filter — 7 EQ sections (highpass/lowshelf/lowbell/midbell/highbell/highshelf/lowpass) with enabled/freq/gain/q/order

  • set_tidal_rate — musical fraction string → Tidal LFO rate index (17 entries)

  • set_delay_sync — musical fraction string → Delay synced time index (21 entries, includes "off")

  • Effect lookup case-insensitiveadd_effect("werkstatt") now works alongside Werkstatt

  • naomiaro/opendaw-test research — 543 commits, 17 SDK doc chapters used as authoritative reference for effect parameters and box field names

  • 54 tests, ruff clean, CI green

v1.9.6 (2026-07-03)

  • measure_lufs refactored — 223 lines → 20 lines. Extracted _parse_wav() and _compute_lufs() helpers

  • DRY: K-weighting coefficients — duplicated if/else branches (48kHz vs else) were identical, merged into single computation

  • 9 new unit tests — WAV parsing (float32/mono/stereo/PCM16/invalid/no-data) + LUFS computation (silence/full-scale/low-level/stereo)

  • Social preview banner — custom OpenGraph image for GitHub link previews

  • awesome-mcp PR updated — title and body synced to 255 tools

  • GitHub topics — 18 topics for discoverability

  • 31 total tests, ruff clean, CI green

v1.9.5 (2026-07-03)

  • CLI commands--version, --list-tools, --help with full env var reference

  • 31 unit tests — pytest covering _ok, _err, _wrap_eval, _unwrap_eval, _safe_filename, _safe_path, _parse_wav, _compute_lufs

  • 3 bug fixes found by tests:

    • _ok(){"success": False} in data overwrote the True flag (security fix)

    • _safe_filename() — case-sensitive extension stripping (.MP3 not stripped)

    • _safe_filename() — Windows backslash path traversal not handled on Linux

  • CI enhanced — now runs pytest (54 tests) alongside syntax/AST/smoke/ruff checks

  • PEP 561py.typed marker for type checker support

  • Mastering pipeline example — full chain: render → measure LUFS → auto-gain → stems → MP3

  • 25 examples total — all syntax-validated

  • 255 total tools (added export_dry_stem for freeze/flatten workflows)

v1.9.4 (2026-07-03)

  • Removed 2 duplicate tools (245 → 243)

    • delete_signature_event — superseded by delete_signature_change (richer: position match + index, returns updated event list)

    • list_aux_sends — superseded by list_sends (richer: target_bus_name, send_level_db, routing, send_pan via box-level access)

  • TOOL_CATALOG.md regenerated from AST — all 255 tools with descriptions, 32 categories

  • server.json Docker tag fixed — was stale 1.0.0, now matches release version

  • 255 total tools

v1.9.3 (2026-07-03)

  • DRY refactoring complete: 17 DAW_HELPERS, ~295 replacements, 0 raw enumeration patterns

    • New helpers: markerBoxes, sendBoxes, busBoxes, sampleBoxes, noteTrackBoxes, clipBoxes, rootClipBoxes, scriptParams, scriptSamples, chainBoxes

    • All pointerHub.incoming() enumeration patterns replaced across 245 tools

    • CONTRIBUTING.md updated with full 17-helper reference table

    • 6 DRY commits, 0 regressions, CI green

v1.9.2 (2026-07-03)

  • DRY refactoring: 113+ tools migrated to h.allAUBoxes() / h.auBox() helpers

    • Replaced 133 occurrences of raw [...rootBox.audioUnits.pointerHub.incoming()].map(({box}) => box).sort(...) boilerplate with h.allAUBoxes() across 113+ MCP tools

    • Box-level helpers eliminate ~3000 lines of duplicated AU enumeration code

    • E2E verified: allAUBoxes returns sorted array, auBox(i) returns box by index, count matches raw, box identity matches

  • Security hardening

    • Transport action enum validation (play, stop, toggle) — prevents JS injection

    • duplicate_effect chain_type enum validation (audio, midi)

    • _safe_filename() + _safe_path() helpers — os.path.basename() sanitization + path traversal protection on 6 render/export locations

    • _unwrap_eval bare except → json.JSONDecodeError

  • 245 total tools (no tool count change — refactoring only)

v1.9.1 (2026-07-03)

  • 2 new generic tools: Boolean & Integer effect parameter setters

    • set_effect_parameter_bool(unit_index, effect_index, parameter_name, value) — Generic boolean field setter. Covers Compressor (lookahead, automakeup, autoattack, autorelease), Gate (inverse), Maximizer (lookahead), StereoTool (invertL, invertR, swap), NeuralAmp (mono)

    • set_effect_parameter_int(unit_index, effect_index, parameter_name, value) — Generic integer field setter. Covers Vocoder (bandCount), StereoTool (panningMixing), Fold (overSampling), Crusher (bits), Delay (version). Device-specific tools are preferred when available.

  • 245 total tools

v1.9.0 (2026-07-03)

  • 6 new tools: Device-Specific Parameters & NeuralAmp Model Loading

    • set_neuralamp_model(unit_index, effect_index, model_json, label, pack_id) — Load NAM/Tone3000 model JSON directly into a NeuralAmp effect, bypassing the popup-based Select Flow. Creates NeuralAmpModelBox and links it via pointer

    • set_vocoder_modulator_source(unit_index, effect_index, source) — Set Vocoder modulator source: noise-white, noise-pink, noise-brown, self, or external

    • set_vocoder_band_count(unit_index, effect_index, band_count) — Set Vocoder filter band count (8-32)

    • set_stereo_tool_panning(unit_index, effect_index, panning_mixing) — Set StereoTool panning law (linear, equal-power)

    • set_fold_oversampling(unit_index, effect_index, oversampling) — Set Fold wavefolder oversampling (0=off, 1=2x, 2=4x)

    • set_crusher_bits(unit_index, effect_index, bits) — Set Crusher bit depth (1-16)

  • 255 total tools

v1.8.2 (2026-07-03)

  • 2 new tools: Audio Region Time Base & Waveform Offset

    • set_audio_region_time_base(unit_index, track_index, region_index, time_base) — Switch duration interpretation between 'musical' (PPQN, tempo-following) and 'seconds' (fixed wall-clock)

    • set_audio_region_waveform_offset(unit_index, track_index, region_index, offset) — Set waveform display offset for visual alignment

  • PR #280 closed — andremichelle confirmed it's our bundler setup issue, not upstream. Closing as requested.

  • 237 total tools

v1.8.1 (2026-07-03)

  • 3 new tools: Warp Marker CRUDcreate_warp_marker, delete_warp_marker, update_warp_marker

    • create_warp_marker(unit_index, track_index, region_index, position_beats, seconds) — Add warp marker to stretched audio regions

    • delete_warp_marker(unit_index, track_index, region_index, marker_index) — Delete non-anchor warp marker

    • update_warp_marker(unit_index, track_index, region_index, marker_index, position_beats, seconds) — Update warp marker position/seconds (-1 = unchanged)

    • Enables agent-driven tempo matching: programmatically pin audio regions to musical positions

  • 235 total tools

v1.8.0 (2026-07-03)

  • 3 new tools: MP3/FLAC Audio Conversionconvert_audio, render_full_format, export_stems_format

    • convert_audio(filename, format, bitrate, quality) — WAV→MP3/FLAC via system ffmpeg

    • render_full_format(filename, format, bitrate) — render + convert in one step

    • export_stems_format(filename_prefix, format, bitrate) — stems + convert each

    • Uses system ffmpeg (4.4.2), not browser WASM — more reliable in headless mode

    • E2E: WAV 1.01MB → MP3 0.11MB (ratio 0.106) → FLAC 0.19MB (ratio 0.194) ✅

  • Bugfix: operator precedence in 14 division+nullish coalescing expressions

    • X / Quarter ?? 0(X ?? 0) / Quarter — prevents NaN→null for position/duration fields

  • Improvement: get_track_info now includes exclude_piano_mode field

  • 232 total tools

v1.7.4 (2026-07-03)

  • 3 new tools: Engine Sleep/Wake + Loading Checkengine_sleep, engine_wake, query_loading_complete

    • engine_sleep() — suspend audio processing to save CPU during non-audio operations

    • engine_wake() — resume audio processing

    • query_loading_complete() — check if all audio samples are loaded and ready

    • E2E: sleep ✅, wake ✅, loading (loaded=false, is_ready=true) ✅

  • Improvement: get_effect_chain + get_midi_effect_chain — now return short type names (Delay instead of DelayDeviceBox), plus class, minimized fields

v1.7.3 (2026-07-03)

  • 2 new tools: Instrument Automationadd_instrument_automation, list_automatable_fields

    • Automate any instrument parameter: Vaporisateur cutoff/volume/ADSR, Tape flutter/wow, Playfield sample mute

    • Per-sample targeting via sample_index for Playfield

    • list_automatable_fields introspects Pointers.Automation support (18/23 on Vaporisateur)

    • Addresses upstream #269 (playfield mute automation) via MCP

    • E2E: Vaporisateur cutoff automated (3 events) ✅, 18 automatable fields ✅

v1.7.2 (2026-07-03)

  • 3 new tools: Effect Duplication + Instrument Automationduplicate_effect, add_instrument_automation, list_automatable_fields

    • duplicate_effect — duplicate single effect in-place with all params copied (audio or MIDI chain)

    • add_instrument_automation — automate any instrument parameter (Vaporisateur cutoff/volume, Tape flutter, Playfield sample mute, etc). Supports per-sample targeting via sample_index

    • list_automatable_fields — introspect which fields support Pointers.Automation (18/23 on Vaporisateur)

    • Addresses upstream issue #273 (Ctrl+D for audio effects) and #269 (playfield mute automation) via MCP

    • E2E tested: Delay duplicated with params ✅, Vaporisateur cutoff automated (3 events) ✅, 18 automatable fields detected ✅

  • Bugfix: transport(action) now respects action parameter — was always toggling, now correctly handles "play", "stop", "toggle"

  • Cleanup: removed unused region_type param from set_region_duration and set_region_mute

v1.7.1 (2026-07-03)

  • 4 new tools: Engine Controlengine_panic(), get_engine_status(), schedule_clip_play(clip_ids), schedule_clip_stop(track_ids)

    • Panic button for stuck audio, real-time engine monitoring (CPU load, position, BPM, playing state), session view clip triggering

    • E2E tested: get_engine_status ✅, engine_panic ✅

v1.7.0 (2026-07-03)

  • 2 new tools: DawProject Interopexport_dawproject(filename), import_dawproject(filename)

    • Export/import projects in .dawproject format (Bitwig, Ableton, rePitch compatible)

    • ZIP containing project.xml, metadata.xml, and audio samples

    • Enables cross-DAW workflow: create in openDAW → export to Bitwig, or import Bitwig project → render in openDAW

    • DawProject + DawProjectImport exposed as globals in headless-daw

    • E2E tested: export (2442 bytes, valid ZIP) → import (7 boxes, round-trip OK)

v1.6.2 (2026-07-03)

  • 2 new tools: Studio Settingsget_studio_settings(), set_studio_setting(category, key, value)

    • Read/write StudioPreferences: engine, visibility, editing, debug, storage, time-display, pointer

    • Control auto-create-output-maximizer, overlapping-regions-behaviour, enable-beta-features, auto-delete-orphaned-samples, note-audition-while-editing, and more

    • StudioPreferences exposed as DAW_StudioPreferences global in headless-daw

v1.6.1 (2026-07-03)

  • 4 new tools from DAW globals researchset_unit_minimized, list_aux_sends, capture_realtime, get_sample_info

    • Mixer minimize, aux send listing, realtime audio capture, sample metadata

v1.6.0 (2026-07-03)

  • DAW_HELPERS refactoring — all 180 tools with const p = window.DAW migrated to const h = window.DAW_HELPERS pattern

    • Eliminated boilerplate: AU list enumeration, sort, editing.modify wrapping

    • Fixed 19+ pre-existing bugs: setPosition (api→engine), 8x missing .sort() on AU lists, 9x Quarter=960 hardcode → h.ppqn.Quarter, 2x Python/JS scope leaks

    • DAW_HELPERS provides: h.au(i), h.track(), h.region(), h.modify(), h.allAUs(), h.ppqn, h.uuid, h.rootBox, h.api, h.editing, h.boxGraph, h.tempoMap, h.rootBoxAdapter, h.project

  • E2E verified: 23/23 tests passing

v1.5.2 (2026-07-02)

  • Sanitization: all string parameters sanitized against JS injection

  • Documentation: README badges, Docker, SSE, examples, mastering

  • CI: GitHub Actions with AST tool count verification

v1.5.0 (2026-07-01)

  • Modular system: 6 MCP tools for patchable modular synthesizer

  • PianoMode: 6 MCP tools for piano roll view control

  • Freeze/unfreeze: pre-render AU to save CPU

  • Preset save/load: export/import AU as base64 preset

  • Transfer regions/AUs: deep-copy with dependency tracking

Available Tools

515 tools
mcp_opendaw_accent_beatsA

Apply beat-aware velocity accents to notes based on their position.

Unlike apply_velocity_pattern (which cycles by note index), this determines accent strength from each note's beat position — downbeats get strong, off-beats get weak. This is how real drummers and musicians play.

Accent patterns:

  • "4/4" — beat 1 strong, 2 medium, 3 medium, 4 weak (classic rock/pop)

  • "backbeat" — beats 1+3 medium, 2+4 strong (rock, funk, soul)

  • "3/4" — beat 1 strong, 2 weak, 3 medium (waltz)

  • "6/8" — beats 1+4 strong, others weak (compound duple)

  • "off_beat" — downbeats weak, off-beats strong (syncopated, reggae skank)

  • "four_on_floor" — every quarter strong (house, techno)

Notes that fall on exact beat boundaries get accent levels. Notes between beats (e.g. 16th notes) get interpolated: closer to a strong beat → higher.

Use cases:

  • Make drum patterns feel groovy instead of flat

  • Add natural dynamics to programmed basslines

  • Emphasise downbeats in chord stabs

  • Create backbeat feel on snare/hihat

unit_index: AU index. track_index: Note track index. accent_pattern: Beat accent scheme (4/4, backbeat, 3/4, 6/8, off_beat, four_on_floor). strong_velocity: Velocity for strong beats (0-1). medium_velocity: Velocity for medium beats (0-1). weak_velocity: Velocity for weak beats (0-1). region_index: Region (-1 = first region).

Returns count of notes accented and per-level breakdown.

Example:

Backbeat feel — accent beats 2 and 4

accent_beats(0, 0, "backbeat", strong_velocity=1.0, weak_velocity=0.5)

Four-on-the-floor — every beat loud

accent_beats(0, 0, "four_on_floor", strong_velocity=0.95)

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo
weak_velocityNo
accent_patternNo4/4
medium_velocityNo
strong_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description clearly explains how accent strength is determined (downbeats strong, off-beats weak) and the interpolation for notes between beats. It also mentions the return value (count of notes accented and per-level breakdown), providing transparency beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections for main functionality, differentiation, accent patterns, use cases, parameter list, and an example. Every sentence adds value, and the structure makes it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters and no output schema, the description covers both parameter semantics and return value ('Returns count of notes accented and per-level breakdown'). It is complete enough for an agent to understand what the tool does and what it outputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by listing each parameter with a brief explanation (e.g., 'strong_velocity: Velocity for strong beats (0-1)'). While not exhaustive, it adds sufficient meaning beyond the schema's bare types and titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('apply') and resource ('beat-aware velocity accents to notes'), clearly stating the tool's purpose. It distinguishes itself from the sibling 'apply_velocity_pattern' by explaining the difference in accent determination (beat position vs note index).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with 'apply_velocity_pattern' and provides concrete use cases (e.g., making drum patterns groovy, adding natural dynamics to basslines). It does not explicitly state when not to use it, but the differentiation and use cases offer adequate guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_anticipationA

Add anticipation notes before strong-beat notes.

Anticipation is the fourth classic non-chord tone technique: a note that arrives early — on the weak part of the beat before a strong beat — anticipating the pitch of the upcoming note. This creates forward rhythmic motion and is ubiquitous in jazz, pop, and Latin music.

Unlike passing tones (which connect two different pitches stepwise), suspensions (which hold a note into the next chord), and neighbor tones (which ornament a single note), anticipation reaches forward to the next melodic/harmonic goal before the beat arrives.

Structure: [original note shortened] → [anticipation on weak beat] → [strong beat note]

The tool finds notes on strong beats (integer beat positions) and inserts an anticipation note just before them. The anticipation has the same pitch as the target note (or a related scale tone if direction is set), placed on the weak portion of the beat.

Jazz syncopation, pop vocal anticipations, salsa montuno, and funk guitar stabs all rely on this device.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) scale: Scale for anticipation pitch selection ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues", "chromatic") root: Root note for scale (C, C#, D, ... B) anticipation_offset: How early the anticipation arrives, in beats before the strong beat (0.0625-0.5, default 0.25 = sixteenth note before). Smaller = more subtle, larger = more pronounced. anticipation_fraction: Duration of anticipation as fraction of the offset gap (0.1-1.0, default 0.33). Controls how long the anticipation note lasts relative to the gap before the strong beat. anticipation_velocity: Velocity of anticipation note (0-1, default 0.55 — softer than the main note, as it is on a weak beat). direction: Anticipation pitch direction — "auto": same pitch as target note (classic anticipation) "upper": one scale step above target "lower": one scale step below target "approach": scale step approaching target from the direction of the previous note min_duration_beats: Minimum note duration in beats to qualify (0.5-4.0, default 1.5). Ensures the target note is long enough to anticipate meaningfully. cross_track: If >= 0, place anticipations on this track index instead of source track (preserves original notes).

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
directionNoauto
unit_indexYes
cross_trackNo
track_indexYes
region_indexNo
min_duration_beatsNo
anticipation_offsetNo
anticipation_fractionNo
anticipation_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses the tool's behavior: it finds notes on strong beats, shortens them, and inserts an anticipation note on the weak beat before. It explains the effect on the original note structure and details parameter impacts, providing complete transparency without contradicting any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but somewhat lengthy due to musical theory context and parameter details. However, it is well-structured with a clear front-loaded purpose, a logical flow from concept to parameter list, and no irrelevant information. It earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, output schema exists), the description covers all necessary aspects: musical context, structural effect, parameter semantics, and differentiation from siblings. It is fully complete for an AI agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by providing detailed explanations for all 11 parameters in an 'Args' section, including defaults, ranges, and musical meanings (e.g., anticipation_offset as 'sixteenth note before'). This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add anticipation notes before strong-beat notes' and provides a thorough explanation of the anticipation technique, distinguishing it from passing tones, suspensions, and neighbor tones. It also lists genres where it is used (jazz, pop, Latin), making the purpose unmistakable and differentiating it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts anticipation with other non-chord tone techniques (passing tones, suspensions, neighbor tones), providing clear guidance on when to use this tool versus alternatives. It also explains the musical context and structure, helping the agent understand the appropriate use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_automationA

Add parameter automation to an effect on an audio unit.

Creates an automation track + value clip + value events. Automation points control the parameter over time.

unit_index: Audio unit index. effect_index: Effect position in the chain. parameter_name: Parameter to automate (e.g. "cutoff", "volume", "mix"). points: JSON array of [position_beats, value_0_to_1] pairs. Example: "[[0, 0.5], [4, 1.0], [8, 0.5]]"

The parameter must be automatable (Field<Pointers.Automation>).

ParametersJSON Schema
NameRequiredDescriptionDefault
pointsYes
unit_indexYes
effect_indexYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the tool creates an automation track, value clip, and value events, and specifies that the parameter must be automatable. However, with no annotations, it misses details on error handling, side effects like overwriting existing automation, and the return value structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the purpose. It efficiently covers the key information in a few sentences without unnecessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (4 required params, no nested objects, output schema exists), the description covers the core functionality and parameter semantics. However, it lacks information on error conditions, prerequisites, and what the output schema returns, making it only partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, and the description compensates by explaining each parameter: unit_index, effect_index, parameter_name with examples, and points with format and example. The descriptions are clear and add value beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds parameter automation to an effect on an audio unit, with specific verbs and resources. It distinguishes from sibling tools like add_instrument_automation by specifying 'effect on an audio unit'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites like checking automatable fields with list_automatable_fields, nor does it indicate when to use add_instrument_automation instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_bass_chainA

Add a ready-made bass processing chain to an audio unit — EQ → Compressor (+ optional Waveshaper drive).

One call replaces 2-3 individual add_effect + set_effect_parameter calls. Designed for bass tracks but works on any low-frequency content.

unit_index: Target audio unit (the bass track). style: Preset character:

  • "deep" — sub boost, slow comp, thick low end (hip-hop, trap, 808s)

  • "round" — low-mid warmth, gentle comp (R&B, jazz, soul)

  • "driven" — low cut, mid boost, comp + drive (rock, punk bass)

  • "clean" — transparent, minimal coloration (electronic, house)

  • "tight" — fast comp, controlled, punchy (disco, funk, pop)

drive_amount: Waveshaper saturation (0-1, default 0 = off). Use 0.2-0.5 for grit.

Creates: Revamp EQ → Compressor (→ Waveshaper) on the target AU. Returns effect indices and parameter values set.

Example:

Deep sub bass chain

add_bass_chain(0)

Driven rock bass with grit

add_bass_chain(0, style="driven", drive_amount=0.4)

Clean electronic bass

add_bass_chain(0, style="clean")

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNodeep
unit_indexNo
drive_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the created effects (Revamp EQ, Compressor, optional Waveshaper) and says it returns effect indices and parameter values. However, it does not mention if it overwrites existing effects, whether changes are reversible, or any required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, benefit, parameter details, output comment, and examples. Every sentence is informative, and the overall length is appropriate without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters (none required), no annotations, and an output schema (not provided but described). The description covers the effect chain, parameter details, use cases, and examples, making it complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully documents all three parameters: `unit_index` (target audio unit), `style` (with detailed preset descriptions for deep, round, driven, clean, tight), and `drive_amount` (range 0-1, default 0, usage advice). Examples show typical values. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a ready-made bass processing chain to an audio unit' and specifies the exact effect chain (EQ → Compressor → optional Waveshaper). It distinguishes this tool from siblings like `add_effect` by noting it replaces multiple individual calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool replaces 2-3 individual `add_effect` and `set_effect_parameter` calls and is designed for bass tracks but works on any low-frequency content. It provides examples but does not explicitly state when to avoid using it (e.g., for custom chains).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_chord_tensionA

Add a tension/extension note to an existing chord — jazz harmony.

Adds an extension note (9th, 11th, 13th, or alterations) to a chord already on the timeline. This is how triads become jazz chords — stack a 9th on a C major triad and it becomes Cmaj9, add a b13 to a G7 and it becomes G7b13. The extension is calculated from the chord root, so you don't need to know the exact pitch.

extension: The tension note to add:

  • "9" — major 9th (2 semitones above root, +14 from root). Adds color and warmth. C → D. The most common jazz extension.

  • "b9" — minor 9th (1 semitone above root, +13). Dark, tense. Dominant chords in minor keys, flamenco, film scores. C → Db.

  • "#9" — augmented 9th (3 semitones, +15). The Hendrix chord sound. Bluesy, gritty. C → D#.

  • "11" — perfect 11th (5 semitones above root, +17). Suspended, open. C → F. Can clash with 3rd — use carefully.

  • "#11" — augmented 11th (6 semitones, +18). Lydian sound. Dreamy, floating. C → F#. Common in modal jazz.

  • "13" — major 13th (9 semitones above root, +21). Full, rich. The ultimate jazz extension. C → A. Adds completeness.

  • "b13" — minor 13th (8 semitones, +20). Dark, dramatic. Minor key dominants. C → Ab. Spanish/orchestral feel.

chord_position: Beat position of the chord (finds root = lowest note). octave: Which octave to place the extension in (3-7, default 5). Higher = more color, lower = more grounded. velocity: Velocity of the added note (0-1, default 0.6 = subtle).

Returns root pitch, extension pitch, extension name, chord size.

Example:

Add 9th to first chord — Cmaj → Cmaj9

add_chord_tension(0, 2, 0, 0.0, extension="9")

Add b13 for dark dominant — G7 → G7b13

add_chord_tension(0, 2, 0, 4.0, extension="b13")

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
velocityNo
extensionNo9
unit_indexYes
track_indexYes
region_indexYes
chord_positionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that extensions are calculated from the chord root and returns pitch info, but lacks details on side effects, reversibility, or error handling. It adds context like potential clashes (11th with 3rd), which is helpful but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: one-line summary, conceptual explanation, detailed extension list with musical character, other parameters, return values, and examples. Every section adds value, though the extension list could be slightly condensed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's musical complexity and 7 parameters, the description covers purpose, parameter roles, and return values. It includes practical examples and educational content. However, it does not address edge cases like invalid chord_position or missing chord, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains the most important parameters (extension, chord_position, octave, velocity) in detail with musical context. The index parameters are self-explanatory. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it adds tension/extension notes to chords in a jazz harmony context. It uses specific verbs and resources, and the purpose is distinct from sibling tools like add_chord_progression or invert_chord_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive guidance on when to use each extension type (e.g., 'most common jazz extension', 'dark, tense'), and gives examples for Cmaj9 and G7b13. However, it does not explicitly contrast with alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_drum_chainA

Add a ready-made drum processing chain to an audio unit — Gate → EQ → Compressor (+ optional Reverb).

One call replaces 3-4 individual add_effect + set_effect_parameter calls. Designed for drum tracks but works on any rhythmic content.

unit_index: Target audio unit (the drum track). style: Preset character:

  • "punchy" — tight gate, bright EQ, fast comp (pop, rock drums)

  • "deep" — loose gate, sub boost, slow comp (hip-hop, trap, 808s)

  • "crisp" — bright EQ, fast attack comp (techno, house, electronic)

  • "roomy" — medium gate, warm EQ, lush reverb (rock, live drums)

  • "tight" — transparent, just cleanup (jazz, acoustic, lofi)

reverb_amount: Reverb wet/dry (0-1, default 0 = off). Use 0.1-0.3 for room sound.

Creates: Gate → Revamp EQ → Compressor (→ Reverb) on the target AU. Returns effect indices and parameter values set.

Example:

Punchy drum chain on track 0

add_drum_chain(0)

Deep 808 chain

add_drum_chain(0, style="deep")

Roomy rock drums with reverb

add_drum_chain(0, style="roomy", reverb_amount=0.25)

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNopunchy
unit_indexNo
reverb_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the effects created (Gate → EQ → Compressor → optional Reverb) and mentions returning effect indices and values. However, it does not clarify whether existing effects are preserved or overwritten, nor does it mention any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line summary, a benefit statement, a parameter list with clear headings and descriptions, and a multi-line example section. Every sentence adds value, and the formatting aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters, no required ones, absence of schema descriptions, and presence of an output schema, the description fully covers purpose, usage context, parameter meanings, expected output (effect indices and values), and includes practical examples. It is complete and self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description provides detailed semantics for all three parameters: unit_index (target as 'the drum track'), style (five named options with descriptions), and reverb_amount (range and typical usage). This adds significant value beyond the minimal schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Add a ready-made drum processing chain') and the resource ('audio unit'), with a specific sequence of effects. It distinguishes from sibling tools like add_bass_chain and add_vocal_chain by explicitly targeting drums and rhythmic content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool is designed for drum tracks but works on any rhythmic content, and notes it replaces multiple individual effect calls. It provides clear context for use, though it does not explicitly state when not to use it (e.g., for non-rhythmic content).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_effectA

Add an audio effect to an audio unit's effect chain.

effect_type: One of the audio effect names from mcp_opendaw_list_effects: Compressor, Crusher, DattorroReverb, Delay, Fold, Gate, Maximizer, NeuralAmp (Tone3000), Reverb, Revamp, StereoTool, Tidal, Vocoder, Waveshaper, Werkstatt

Returns effect_index — use it with mcp_opendaw_set_effect_parameter.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_typeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full behavioral disclosure. It only states that the tool adds an effect and returns an index, omitting details about prerequisites (e.g., unit must exist), mutability, error handling, or side effects. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a bullet list of effect types. It is relatively concise but the list is lengthy (16 items). The structure is clear, with the main action first followed by parameter details and return value usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 required parameters and an output (effect_index), the description covers the return value's purpose but does not specify the type or format of the index. It also lacks error conditions or prerequisites. With an output schema present (context says true), the description is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% documentation coverage (no descriptions for parameters). The description clarifies the effect_type parameter by listing valid values, but does not explain unit_index—its type, range, or how to obtain it. With all the burden on the description, this gap significantly reduces usefulness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add an audio effect to an audio unit's effect chain', using a specific verb and resource. It distinguishes from sibling 'add' tools by specifying the domain (audio effect) and includes a list of valid effect types from a related tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains that effect_type must be from mcp_opendaw_list_effects and provides a list. It also links the return value to a downstream tool (mcp_opendaw_set_effect_parameter), giving context for subsequent steps. However, it does not explicitly state when not to use this tool or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_instrument_automationA

Automate a parameter on the instrument connected to an audio unit.

Works with any automatable instrument field: Vaporisateur (cutoff, resonance, volume, etc), Playfield sample mute, Tape flutter/wow, Nano volume/release, and more.

For Playfield sample-level params (mute, volume, pan, etc), set sample_index to the sample slot index (0-based). For top-level instrument params, leave sample_index as -1.

unit_index: Audio unit index containing the instrument. parameter_name: Field name to automate (e.g. "cutoff", "mute", "flutter"). points: JSON array of [position_beats, value] pairs. Example: "[[0, 0.5], [4, 1.0]]" sample_index: For Playfield, which sample slot to target (-1 = top-level instrument field).

Returns automation track info and number of events created.

ParametersJSON Schema
NameRequiredDescriptionDefault
pointsYes
unit_indexYes
sample_indexNo
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states the tool adds automation points and returns info, but does not disclose whether it overwrites existing automation, if the parameter must exist, or any side effects. Lacks details on error behavior or prerequisites like instrument presence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear first sentence stating purpose, followed by examples and parameter explanations. Slightly lengthy but front-loaded and every sentence adds value. Could be tightened slightly without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameter details, return value (automation track info and events count), and notes compatibility with various instruments. Lacks mention of error conditions or required project state (e.g., audio unit must exist and be loaded). Overall fairly complete for a 4-parameter tool with output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% description coverage. The description provides detailed meaning for all four parameters: unit_index (audio unit index), parameter_name (field name), points (JSON array with example), and sample_index (explained -1 vs specific index). Adds significant value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool automates a parameter on an instrument connected to an audio unit. Provides specific examples of instruments and parameters (Vaporisateur cutoff, Playfield mute, etc.), and distinguishes from siblings like 'add_automation' (general) and 'set_instrument_param' (single value).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Offers clear context for use: any automatable instrument field with examples. Instructs on when to set sample_index vs -1. Does not explicitly exclude alternative tools or state when not to use this tool, but the context is sufficient for informed selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_instrument_chainA

Add a ready-made instrument processing chain — EQ → Compressor → Reverb (+ optional Delay).

Universal chain for guitars, keys, synth leads, strings, pads — any melodic/harmonic instrument. One call replaces 3-4 individual add_effect + set_effect_parameter calls.

unit_index: Target audio unit (the instrument track). style: Preset character:

  • "clean" — transparent EQ, light comp, subtle reverb (keys, piano, clean guitar)

  • "warm" — low-mid warmth, tube-like comp (jazz guitar, Rhodes, warm synths)

  • "bright" — air boost, present mids, short reverb (lead guitar, synth lead, pop keys)

  • "ambient" — wide EQ, minimal comp, lush reverb (pads, strings, atmospheres)

  • "driven" — mid crunch, drive comp, room reverb (rock guitar, aggressive synths)

reverb_amount: Reverb wet/dry (0-1, default 0.15 = subtle). delay_amount: Optional delay wet/dry (0-1, default 0 = off).

Creates: Revamp EQ → Compressor → Reverb (→ Delay) on the target AU. Returns effect indices and parameter values set.

Example:

Clean keys chain

add_instrument_chain(0)

Ambient pad with lush reverb

add_instrument_chain(0, style="ambient", reverb_amount=0.4)

Driven rock guitar

add_instrument_chain(0, style="driven", reverb_amount=0.2)

Synth lead with delay

add_instrument_chain(0, style="bright", delay_amount=0.2)

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoclean
unit_indexNo
delay_amountNo
reverb_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the created chain (Revamp EQ → Compressor → Reverb → Delay) and mentions return values. However, does not disclose whether existing effects are replaced or added, nor prerequisites (e.g., unit must exist). No annotations provided to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: summary, parameter descriptions, examples. Every sentence adds value without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains the chain, parameters, outputs, and provides examples. Could address edge cases (e.g., existing effects), but overall complete for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Explains each parameter (unit_index, style with detailed descriptions, reverb_amount, delay_amount) beyond the schema, which has no descriptions. Good coverage for 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a ready-made instrument processing chain (EQ, Compressor, Reverb, optional Delay) for melodic/harmonic instruments. It distinguishes from siblings like add_effect and set_effect_parameter by noting one call replaces 3-4 individual calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context (universal chain for melodic/harmonic instruments) and style guidance, but lacks explicit when-not-to-use or alternative tools beyond implied replacement of individual effect calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_markerA

Add a timeline marker at a position.

Markers label song structure points (Verse, Chorus, Bridge, etc.). Visible on the timeline ruler.

position_beats: Position in beats. label: Marker text (e.g. "Verse 1", "Chorus", "Drop").

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool adds a marker but does not disclose side effects, limits on number of markers, or whether the operation is reversible. The basic additive nature is conveyed, but more detail could be helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary action, and no extraneous words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the presence of an output schema (unseen but declared), the description covers purpose, parameters, and visibility. It lacks project context, but that is common across sibling tools and not critical for this operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), but the description fully explains both parameters: 'position_beats' as position in beats and 'label' with examples. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a timeline marker at a position' with a specific verb and resource. It explains the purpose of markers (label song structure points) and visibility. Among siblings like set_marker_label and delete_marker, this tool is uniquely the creation action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adding markers but does not explicitly state when to use this tool versus alternatives (e.g., updating or deleting markers). It lacks guidelines on prerequisites such as having a project open.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_mastering_chainA

Add a ready-made mastering chain to the output bus — EQ + compressor + maximizer in one call.

target_lufs: Target loudness (-14 = Spotify, -16 = Apple, -10 = loud). style: Preset character:

  • "balanced" — transparent EQ, gentle comp, clean limiter

  • "warm" — low shelf boost, slower comp attack, soft saturation

  • "loud" — aggressive comp, fast release, hard limit

  • "transparent" — minimal EQ, light comp, true peak limiting

Creates: Revamp EQ → Compressor → Maximizer on the output/master AU. Returns the effect indices and parameter values set.

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNobalanced
target_lufsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the tool creates three specific effects (Revamp EQ, Compressor, Maximizer) on the output/master AU and returns effect indices/parameter values. However, it doesn't clarify if it overwrites existing chains or is additive, nor any side effects or dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It begins with a clear action statement, then presents parameters in a readable bulleted list. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately covers purpose, parameters, and result (effect indices and values). It lacks mention of prerequisites or whether the tool is additive, but overall is sufficient for a straightforward tool with two optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description fully compensates. It explains target_lufs with concrete examples (-14, -16, -10) and lists four style options with detailed character descriptions. This adds significant meaning beyond the schema's bare type/default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Add a ready-made mastering chain to the output bus — EQ + compressor + maximizer in one call.' It uses a specific verb ('Add') and resource ('mastering chain to the output bus'), and distinguishes from sibling tools like add_bass_chain or add_drum_chain by specifying it targets the output bus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by naming (mastering chain for output bus) but lacks explicit guidance on when to use this tool versus alternatives like adding individual effects or other chains. No context on prerequisites (e.g., project state) or when not to use it (e.g., if a mastering chain already exists).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_midi_effectA

Add a MIDI effect to an audio unit's MIDI effect chain.

MIDI effects process note data before the instrument. They are chained on au.midiEffects (separate from audio effects on au.audioEffects).

effect_type: One of: Arpeggio, Pitch, Velocity, Zeitgeist, Spielwerk

unit_index: Audio unit index (must be an instrument AU, not output). Returns effect_index in the MIDI chain.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_typeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the effect is added to the MIDI effect chain, that it processes note data before the instrument, and that the unit type must be an instrument AU. It also mentions the return of effect_index. This is good transparency, though it doesn't mention potential side effects or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: one sentence for purpose, then two sentences for context and details. No redundant words, and the information is front-loaded. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values need not be explained. The description covers the tool's purpose, the separate chain, parameter constraints, and effect_type options. It does not specify the order of effects in the chain or behavior when multiple effects exist, but these are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (no parameter descriptions in schema). The description compensates fully by explaining that effect_type must be one of the listed values (Arpeggio, Pitch, Velocity, etc.) and that unit_index must be an instrument AU, not output. This adds critical meaning beyond the raw schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Add' and resource 'MIDI effect to an audio unit's MIDI effect chain'. It distinguishes from audio effects by explicitly separating MIDI effects (midiEffects) from audio effects (audioEffects), which differentiates it from siblings like 'add_effect'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: MIDI effects process note data before the instrument, they are chained separately, and the unit must be an instrument AU (not output). It lists valid effect_types. However, it does not explicitly state when not to use this tool or offer direct alternatives, missing a small opportunity for explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_modular_moduleB

Add a module to a Modular device.

au_index: Audio unit index. effect_index: Effect index within the AU. module_type: One of "gain", "delay", "multiplier", "audio-input", "audio-output". label: Optional label for the module. x, y: Position in the modular editor grid.

Returns the new module's index and info.

ParametersJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
labelNo
au_indexYes
module_typeYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the return value but does not disclose error conditions, side effects, permissions, or constraints (e.g., duplicate labels, invalid types, coordinate conflicts).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the action. It lists parameters in a clear, readable format. Slight improvement could be a bulleted list, but overall efficient and focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core purpose and parameters, mentions return value. Lacks context on what a Modular device is, how to obtain au_index/effect_index, or behavior under edge cases. Adequate for basic use but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining each parameter (au_index, effect_index, module_type, label, x, y) and providing the enum values for module_type. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it adds a module to a Modular device, with specific parameters. It is unambiguous but does not explicitly differentiate from sibling add tools, though the modular context is unique among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like connect_modular_modules or remove_modular_module. The description only describes the action, not the context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_neighbor_tonesA

Add upper/lower neighbor tones to embellish existing notes.

A neighbor tone is a non-chord tone that steps away from the main note by one scale step (up or down) and then returns. Unlike passing tones which connect two different notes, neighbor tones ornament a single sustained note.

Structure: [main first part] → [neighbor (dissonance)] → [main return]

The original note is split into three parts:

  1. First part: original pitch from start to neighbor_offset

  2. Neighbor: one scale step away, duration = neighbor_fraction of original

  3. Return: original pitch for the remainder

This is the third of the four classic non-chord tone techniques: passing tones, suspensions, neighbor tones, and anticipation.

Bach ornaments, jazz ballad fills, country chicken pickin', and classical cadenzas all use neighbor tones extensively.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) scale: Scale for diatonic neighbor step ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues", "chromatic") root: Root note for scale (C, C#, D, ... B) direction: Neighbor direction — "upper": step up from main note (most common) "lower": step down from main note "alternating": alternate upper/lower per note neighbor_fraction: Duration of neighbor as fraction of original note (0.1-0.5, default 0.25 = quarter of original). Smaller values create subtle ornaments, larger create more prominent embellishments. neighbor_offset: Position of neighbor within the note (0.1-0.9, default 0.5 = middle). 0.15 = near start, 0.5 = middle, 0.85 = near end. neighbor_velocity: Velocity of neighbor note (0-1, default 0.6 — softer than the main note, as is traditional for ornaments). min_duration_beats: Minimum note duration in beats to embellish (0.5-4.0, default 1.0). Short notes are skipped — ornaments need room to breathe. cross_track: If >= 0, place neighbors on this track index instead of source track (preserves original notes).

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
directionNoupper
unit_indexYes
cross_trackNo
track_indexYes
region_indexNo
neighbor_offsetNo
neighbor_fractionNo
neighbor_velocityNo
min_duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the algorithmic structure (splitting the original note into three parts: first part, neighbor, return), with precise details on how the neighbor is placed. It discloses that short notes are skipped (min_duration_beats parameter) and that the default neighbor velocity is softer than the main note. It also explains the cross_track parameter for preserving original notes. This is comprehensive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence summary, a musical explanation, a structural outline, a comparison to siblings, genre examples, and then a clearly formatted parameter list. Every sentence adds value—no fluff, no repetition. It front-loads the core purpose and immediately differentiates from related tools. The parameter descriptions are concise yet informative, using consistent formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is exhaustive for a tool with 11 parameters and no schema descriptions. It covers the musical theory, the splitting algorithm, all parameter constraints, defaults, and even cultural context (Bach, jazz, country, classical). The output schema exists, so return values need not be explained. The description leaves no significant gaps for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning no parameter descriptions in the JSON schema. The description compensates fully by explaining every parameter in detail, including valid ranges, defaults, and musical implications. For example, neighbor_fraction is described as '0.1-0.5, default 0.25' with guidance on subtle vs prominent effects. neighbor_offset: '0.1-0.9, default 0.5' with examples (0.15 near start, 0.5 middle, 0.85 near end). direction: explains 'upper', 'lower', 'alternating' with context. This adds immense value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear verb+resource: 'Add upper/lower neighbor tones to embellish existing notes.' It immediately distinguishes neighbor tones from passing tones by explaining that neighbor tones ornament a single sustained note while passing tones connect two different notes. This explicitly differentiates it from its sibling tools like mcp_opendaw_add_passing_tones, establishing a unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts neighbor tones with passing tones ('Unlike passing tones which connect two different notes...'), and positions it as the third of four classic non-chord tone techniques (passing tones, suspensions, neighbor tones, anticipation). This provides clear guidance on when to use this tool versus alternatives. It also lists genres where neighbor tones are used, helping the agent choose appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_passing_tonesA

Add passing tones between existing notes for smoother melodic lines.

Inserting diatonic passing tones in gaps where consecutive notes have an interval larger than a 2nd. The passing tone is placed on the weak part of the beat, connecting the two notes stepwise through the scale.

This is a fundamental counterpoint technique — makes large melodic leaps sound smoother by filling them with scale steps. Bach inventions, jazz walking lines, and pop vocal melismas all use passing tones.

Passing tones are only added when:

  • The interval between consecutive notes is > 2 semitones

  • There is enough time gap between notes (at least 1/8 note)

  • The interval does not exceed max_interval semitones

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) scale: Scale for diatonic passing tones ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues", "chromatic") root: Root note for scale (C, C#, D, ... B) max_interval: Maximum interval (semitones) to fill with passing tones (3-12, default 7 = perfect 5th). Intervals larger than this are left as leaps. velocity: Velocity of passing tones (0-1, default 0.6 — slightly quieter than melodic notes, as is traditional) duration_fraction: Duration of passing tones as fraction of the gap between notes (0.25-1.0, default 0.5) direction: Passing tone direction — "auto": choose direction that fits scale better "ascending": always step up from lower to higher note "descending": always step down from higher to lower note "nearest": use nearest scale tone to midpoint cross_track: If >= 0, place passing tones on this track index instead of source track (preserves original melody)

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
velocityNo
directionNoauto
unit_indexYes
cross_trackNo
track_indexYes
max_intervalNo
region_indexNo
duration_fractionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It thoroughly explains the behavior: inserts diatonic passing tones on weak beats, stepwise, respecting scale and duration. It mentions cross_track to preserve original melody, but could clarify if this is additive or modifies existing notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections, but is somewhat lengthy. However, every sentence contributes value, and the parameter list is clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, no annotations, output schema present), the description covers the operation, conditions, and parameters completely. No gaps remain for the agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain parameters. It does: each parameter (unit_index, track_index, region_index, scale, root, max_interval, velocity, duration_fraction, direction, cross_track) is described with defaults, ranges, and meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds passing tones to smooth melodic lines, specifies it's a counterpoint technique, and distinguishes it from similar tools by focusing on stepwise filling of large intervals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit conditions for when passing tones are added (interval > 2 semitones, time gap >= 1/8 note, interval <= max_interval), but does not explicitly mention alternative tools like neighbor tones or anticipations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_signature_changeA

Add a time signature change at a specific position in the track.

Unlike set_time_signature (which sets the global default), this creates a SignatureEventBox on the timeline's signature track, allowing time signature changes mid-track (e.g. 4/4 → 3/4 → 4/4).

position_beats: Position in beats where the change occurs. numerator: Number of beats per bar (top number). denominator: Note value per beat (bottom number: 4=quarter, 8=eighth).

Returns the created signature event details.

ParametersJSON Schema
NameRequiredDescriptionDefault
numeratorYes
denominatorYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that the tool creates a SignatureEventBox on the timeline's signature track and returns details. However, it does not mention potential conflicts with existing signature changes at the same position or idempotency, which would strengthen transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using only three sentences: purpose, distinction from sibling, and parameter descriptions. No redundant information; every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and three parameters, the description adequately covers the tool's function and parameter semantics. It mentions the return value (signature event details) and the effect on the signature track. Could provide a bit more about behavior with existing events, but it's largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description fully explains each parameter: position_beats (position in beats), numerator (beats per bar), denominator (note value per beat with examples). Since schema coverage is 0%, this compensates completely, adding meaning beyond type and title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a time signature change at a specific position, using a specific verb ('Add') and resource ('SignatureEventBox'). It distinguishes itself from the sibling tool 'set_time_signature' by explaining the difference (global vs. mid-track).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with 'set_time_signature' and explains when to use this tool (for mid-track changes). It provides an example (4/4 → 3/4 → 4/4) to illustrate usage, making the context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_suspensionA

Add suspension-resolutions to existing notes.

A suspension is a non-chord tone technique where a note from the previous chord is held over (suspended) into the next chord on a strong beat, creating dissonance, then resolves by step (usually downward) to a chord tone.

Structure: Preparation (held note) → Suspension (dissonance on strong beat) → Resolution (step down/up to chord tone).

This tool finds notes on strong beats (downbeats) and creates a suspension before them: a preparatory note a step above (or below) the target, held into the strong beat, then resolving to the target note.

This is one of the most expressive devices in Western music — Bach chorales, jazz ballads, film scores all rely on suspensions for emotional tension-release.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) scale: Scale for resolution step ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "chromatic") root: Root note for scale resolution: Resolution direction — "down": resolve downward by step (classic 4-3, 9-8, 7-6 suspension) "up": resolve upward by step (rare, retardation) "both": alternate down/up per note suspension_offset: Semitone offset of suspension from target (1-7, default 2 = step above for down resolution). The suspension is placed this many semitones above (for "down" resolution) or below (for "up" resolution) the target note, then snaps to nearest scale tone. preparation_beats: Duration of the preparation note in beats (0.25-2.0, default 0.5 = eighth note before strong beat). suspension_velocity: Velocity of suspension note (0-1, default 0.75 — slightly accented, it is on a strong beat). resolution_velocity: Velocity of resolution note (0-1, default 0.65 — resolution is typically softer). cross_track: If >= 0, place suspensions on this track index instead of source track (preserves original melody).

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
resolutionNodown
unit_indexYes
cross_trackNo
track_indexYes
region_indexNo
preparation_beatsNo
suspension_offsetNo
resolution_velocityNo
suspension_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the algorithmic behavior: it creates a preparatory note, holds it into a strong beat, and resolves to the target note. It explains the structure (preparation -> suspension -> resolution) and how parameters affect the outcome. Since no annotations are provided, the description carries the full burden of disclosure, and it does so well, though it could mention whether the original notes are modified or new notes are added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is notably verbose, including a multi-paragraph music theory lesson about suspensions (preparation, suspension, resolution). While informative, this could be shortened for an AI agent that primarily needs functional details. The first sentence is a clear purpose statement, but the length reduces conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the musical effect and the presence of an output schema, the description is fairly complete. It explains the algorithm, parameters, and musical context. It does not mention error conditions or return values, but the output schema likely covers that. It is sufficient for an AI agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides clear semantics for each of the 11 parameters in the docstring (e.g., 'unit_index: Audio unit index', 'suspension_offset: Semitone offset of suspension from target'). It explains defaults and typical values. However, some parameter descriptions could be more precise (e.g., root defaults to 'C' but the description only says 'Root note for scale'). Overall, it compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Add suspension-resolutions to existing notes' and provides a detailed explanation of what a suspension is in music theory. It distinguishes itself from sibling tools by being specific about the suspension technique, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool: 'This tool finds notes on strong beats (downbeats) and creates a suspension before them.' It implies the context of adding expressive non-chord tones. However, it does not explicitly state when not to use it or mention alternative tools for similar effects (e.g., anticipation, neighbor tones), which would improve clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_tempo_changeA

Add a tempo (BPM) change at a specific position in the track.

Creates a ValueEventBox on the timeline's tempo track, allowing BPM automation mid-track (e.g. 120 BPM → 90 BPM → 140 BPM).

The tempo track uses normalized values (0..1) mapped to minBpm..maxBpm (default 60..240). This tool handles the conversion automatically.

position_beats: Position in beats where the tempo change occurs. bpm: Target BPM (60-240). interpolation: 'linear' for smooth transition, 'hold' for instant jump.

Returns the created tempo event and full tempo map.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
interpolationYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description discloses the underlying mechanism (normalized values, automatic mapping from BPM), interpolation behavior, and that it returns the created tempo event and full tempo map. It does not mention side effects or destructive actions, but the tool's purpose is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is multiple sentences but each provides essential information: purpose, mechanism, parameter descriptions, return value. It is well-structured and front-loaded, though slightly verbose but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 required params, no enums, no annotations, no schema descriptions), the description covers all necessary aspects: what it does, how it works internally, parameter meanings, and output. It is complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining all three parameters: position_beats (position in beats), bpm (target BPM 60-240), interpolation (linear/hold). It adds constraints, examples, and context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds a tempo (BPM) change at a specific position in the track. It explains the creation of ValueEventBox on the tempo track for mid-track automation, distinguishing it from other tempo-related tools like set_bpm or create_tempo_ramp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: adding BPM changes mid-track with examples (e.g., 120→90→140). It explains automatic conversion and interpolation types but does not explicitly contrast with alternatives like set_bpm or create_tempo_ramp, though the sibling list implies these exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_add_vocal_chainA

Add a ready-made vocal processing chain to an audio unit — EQ + compressor + reverb (+ optional delay).

One call replaces 3-4 individual add_effect + set_effect_parameter calls. Designed for vocal tracks but works on any melodic content.

unit_index: Target audio unit (the vocal track). style: Preset character:

  • "balanced" — transparent EQ, gentle comp, medium reverb (pop)

  • "warm" — low-mid warmth, slower comp, lush reverb (R&B, soul)

  • "bright" — air boost, fast comp, short reverb (pop, radio)

  • "intimate" — minimal EQ, light comp, small room (ballad, acoustic)

  • "aggressive" — presence boost, hard comp, plate reverb (rock, rap)

reverb_amount: Reverb wet/dry (0-1, default 0.25 = subtle). delay_amount: Optional slap delay wet/dry (0-1, default 0 = off).

Creates: Revamp EQ → Compressor → Reverb (→ Delay) on the target AU. Returns effect indices and parameter values set.

Example:

Balanced vocal chain on track 0

add_vocal_chain(0)

Warm R&B vocal with lush reverb

add_vocal_chain(0, style="warm", reverb_amount=0.35)

Pop vocal with slap delay

add_vocal_chain(0, style="bright", delay_amount=0.15)

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNobalanced
unit_indexNo
delay_amountNo
reverb_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the effect chain order (Revamp EQ → Compressor → Reverb → Delay), that it returns effect indices and parameter values, and the effect of each parameter. This provides sufficient behavioral context for safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: summary, then parameter details, then examples. All parts are valuable, though it could be slightly more streamlined. The example section is particularly helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters fully described, an output schema present, and clear explanation of the effect chain created, the description covers essential context. It doesn't need to detail return values due to output schema. Minor gaps: no mention of prerequisites or error conditions, but sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate fully. It explains each parameter: unit_index (target audio unit), style (five presets with descriptions), reverb_amount (wet/dry, default 0.25), delay_amount (optional, default 0). Examples illustrate usage. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states clearly: 'Add a ready-made vocal processing chain to an audio unit — EQ + compressor + reverb (+ optional delay).' It specifies the verb (add), resource (vocal chain), and distinguishes from siblings like add_effect and add_bass_chain by noting it replaces multiple calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes: 'One call replaces 3-4 individual add_effect + set_effect_parameter calls. Designed for vocal tracks but works on any melodic content.' This gives explicit guidance on when to use it and suggests the alternative of individual calls, though it lacks explicit 'when not to use' statements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_dynamicsA
Read-only

Dynamics analysis — crest factor, loudness range, transient density, segment RMS.

Measures the dynamic character of a track:

  • crest_factor_db: Peak/RMS ratio in dB (high = dynamic, low = compressed/squashed)

  • loudness_range_db: LRA — 95th-10th percentile of short-term RMS (high = varied dynamics)

  • dynamic_range_db: max-min window RMS (total loudness variation)

  • transient_density: energy spikes per second (high = percussive/transient-rich)

  • segment_variation_db: RMS variation across 10 segments of the track

  • segments: per-segment RMS (dB) with time positions

Compression decision guidance:

  • crest_factor < 6 dB → heavily compressed, low headroom

  • crest_factor > 15 dB → very dynamic, may need compression

  • loudness_range < 4 dB → flat/squashed, lacks dynamic interest

  • loudness_range > 12 dB → very dynamic, may need leveling

  • transient_density > 10 → percussive/transient-heavy content

  • segment_variation > 6 dB → significant level changes between sections

Args: filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns dynamics descriptors, 10-segment RMS contour, and compression suggestions.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint: true, and the description is fully consistent, describing the tool as 'Measures the dynamic character' (read operation). The description goes beyond annotations by explaining each metric's meaning (e.g., crest_factor_db, transient_density) and providing contextual semantics (e.g., 'high crest_factor = very dynamic'). This rich behavioral detail aids the agent in understanding what the tool does and how to interpret outputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a summary line, a list of metrics with explanations, compression guidance, argument description, and a return statement. It is front-loaded with the core purpose. While informative, it could be slightly more concise by reducing redundant phrasing (e.g., 'Measures the dynamic character of a track' could be merged with the first line). Every sentence earns its place, but the length is appropriate for the detail provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (context signal), the description adequately covers the main return values (dynamics descriptors, 10-segment RMS contour, compression suggestions) and their meanings. However, it lacks information about file format constraints (e.g., sample rate, bit depth) or performance considerations. Overall, it is sufficiently complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single filename parameter has 0% schema description coverage. The description compensates fully by explaining how to specify the file: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds essential context not present in the schema, making the parameter's usage unambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Dynamics analysis' and lists specific metrics (crest factor, loudness range, etc.). It distinguishes itself from sibling analysis tools (e.g., analyze_harmonic_rhythm, analyze_spectrum) by focusing on dynamic character. The verb 'analyze' paired with 'dynamics' makes the action and resource explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on interpreting results for compression decisions, which helps the agent decide if dynamics analysis is needed. However, it does not explicitly state when to use this tool over other analysis tools or when not to use it. There are no exclusions or alternatives mentioned, leaving the agent to infer intent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_harmonic_rhythmA
Read-only

Analyze harmonic rhythm — how fast chords change and where.

Identifies chords from MIDI notes (same logic as identify_chords), then analyses the rhythm of chord changes:

  • Chord change positions: exact beat where each new chord starts

  • Chord durations: how long each chord lasts (in beats and bars)

  • Harmonic rhythm rate: fast (<2 bars), medium (2-4 bars), slow (>4 bars)

  • Harmonic density: chords per bar

  • Chord sequence: ordered list of chords with durations

  • Stable sections: where harmony stays the same for 4+ bars

  • Active sections: where chords change every bar or faster

  • Total harmonic events: number of distinct chord changes

This complements identify_chords (which lists chords) by focusing on the temporal pattern of harmony — essential for understanding arrangement, predicting where tension builds, and planning variations.

Use with:

  • analyze_song_structure (structure + harmonic rhythm = full form picture)

  • reharmonize_progression (know what to reharmonize and where)

  • create_arrangement_variation (match or contrast harmonic rhythm)

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = first, -2 = all regions on track). group_tolerance: Beats of tolerance for grouping notes (default 0.25). min_notes: Minimum notes for chord identification (default 3).

Returns harmonic rhythm analysis with chord timeline and section classification.

ParametersJSON Schema
NameRequiredDescriptionDefault
min_notesNo
unit_indexYes
track_indexYes
region_indexNo
group_toleranceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the analysis process (identifying chords from MIDI notes using the same logic as identify_chords) and lists all output fields (chord change positions, durations, rate, density, etc.). Annotations already provide readOnlyHint=true, and the description is consistent with that. The description adds behavioral context beyond annotations by explaining the types of analysis performed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise opening, bullet points for output, usage guidance, parameter list, and return value note. It is informative without being overly verbose, though it could be slightly more concise by condensing some bullet points. Nonetheless, each sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, multiple output fields, relationship to other tools) and the presence of an output schema, the description covers all necessary aspects: purpose, inputs, outputs, usage relationships, and parameter details. It provides a complete picture for an AI agent to correctly select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% description coverage, so the description fully compensates. It explains each parameter in a separate bullet: unit_index, track_index, region_index (with special values -1 and -2), group_tolerance (with default 0.25), and min_notes (with default 3). This adds critical meaning beyond the schema's parameter names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze harmonic rhythm — how fast chords change and where.' It lists specific outputs (chord change positions, durations, rate, density, etc.) and explicitly distinguishes itself from the sibling tool identify_chords, which focuses on chord identification rather than temporal patterns. This provides a clear and distinct purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance by listing companion tools: 'Use with: analyze_song_structure, reharmonize_progression, create_arrangement_variation.' It also explains how it complements identify_chords. While it does not explicitly state when not to use, the positive guidance is strong and helps the agent decide when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_melodyA
Read-only

Analyze melodic content — contour, intervals, direction, climax.

Returns a detailed melodic analysis of notes in a region:

  • Contour profile: direction (up/down/static) for each consecutive interval

  • Interval histogram: count of each interval size (semitones)

  • Step vs leap ratio: percentage of steps (≤2 semitones) vs leaps (>2)

  • Direction changes: how often melody changes direction

  • Climax: highest pitch and its position

  • Nadir: lowest pitch and its position

  • Phrase analysis: groups by rests (gaps > 1 beat) into phrases

  • Contour shape classification: ascending/descending/arch/v_shape/wave/static

  • Melodic range: semitone span between lowest and highest

  • Average interval size

Useful for:

  • Understanding a melody before variation/reharmonization

  • Comparing melodies (which is more jagged, which more stepwise?)

  • Identifying climax placement (is the high point early, middle, late?)

  • Feeding analysis to create_motif_variations

  • Evaluating AI-generated melodies for contour interest

unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first region).

Returns analysis object.

Example: analysis = analyze_melody(0, 3)

contour_shape, climax_position, step_leap_ratio, interval_histogram

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and description agrees (no mutation implied). Description adds rich behavioral detail: what analysis components are returned (contour profile, interval histogram, etc.) and example usage. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: summary line, bullet-point list of analysis outputs, 'Useful for' list, parameter explanations, and example. Front-loaded with key info. Slightly lengthy but earns its space with comprehensive details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a melodic analysis tool, the description covers all necessary aspects: inputs, outputs (via bullet list), use cases, and parameter details. Output schema exists, so return values are adequately specified elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description provides clear explanations for all parameters (unit_index: AU index, track_index: Note track index, region_index: Region (-1 = first region)). This compensates well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Analyze melodic content' with a specific verb and resource, and lists detailed outputs (contour, intervals, climax, etc.). It distinguishes from sibling analysis tools by focusing exclusively on melody, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a 'Useful for' section with clear contexts (e.g., understanding a melody before variation, comparing melodies, feeding to create_motif_variations). While it doesn't explicitly list when not to use or alternatives, the guidance is sufficient for most scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_mixA
Read-only

Complete mix diagnosis in one call — combines track + spectrum + stereo + dynamics.

Runs all four analysis modules and synthesizes a single prioritized report:

  1. analyze_track: BPM, key, LUFS, duration

  2. analyze_spectrum: 7-band frequency balance, spectral centroid, rolloff

  3. analyze_stereo: width, L/R balance, phase correlation, mono compat

  4. analyze_dynamics: crest factor, LRA, transient density, segment contour

Produces prioritized mix_suggestions (sorted by severity) and a master_check with platform-specific LUFS targets:

  • Spotify: -14 LUFS

  • Apple Music: -16 LUFS

  • YouTube: -14 LUFS

  • CD: no target (full dynamics)

The agent can call this single tool instead of 4 separate calls, getting a complete picture for mix decisions: EQ, compression, stereo, mastering.

Args: filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns combined analysis + prioritized suggestions + master check.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details that it runs four analysis modules and returns a report with prioritized suggestions and a master check. Annotations already declare readOnlyHint=true, confirming no side effects. The description adds value by specifying what the analysis covers and the output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear bullet points listing the four modules and the platform-specific LUFS targets. It is informative without being verbose, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (though not fully shown), the description covers the tool's purpose, input requirements, high-level output (combined analysis, suggestions, master check), and platform targets. It provides sufficient context for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'filename' has 0% schema description coverage, but the description fully clarifies: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that this tool performs a 'complete mix diagnosis' by combining four analysis modules into one call. It explicitly lists the modules and distinguishes itself from the individual analyze_* tools, making its purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises that the agent 'can call this single tool instead of 4 separate calls', which implies it should be used for comprehensive mix analysis. However, it does not explicitly state when not to use it (e.g., if only one analysis is needed), so it lacks complete usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_phaseA
Read-only

Per-band phase analysis — coherence, polarity, inter-channel delay.

Checks for phase problems that destroy mono compatibility:

  • Per-band phase correlation (sub, bass, mid, high)

  • Polarity check (inverted channels?)

  • Inter-channel sample delay (misaligned mics, plugin latency)

  • Mono compatibility score (what happens when L+R collapse to mono)

Low-frequency phase issues are critical: bass should be mono. High-frequency phase issues widen stereo but risk mono cancellation.

filename: WAV file in exports dir, or absolute path.

Returns per-band phase coherence + mono compatibility assessment.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description details the specific checks, explains the significance of low vs high frequency phase issues, and describes the input parameter, providing rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening summary and bullet points, front-loading key information. It is slightly verbose but not excessively so.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and existence of an output schema, the description covers input details, analysis specifics, and return type. It is mostly complete but could mention file format restrictions beyond WAV.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds essential meaning by specifying that the filename must be a WAV file in the exports directory or an absolute path, which the schema alone does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs per-band phase analysis, enumerating specific checks (coherence, polarity, delay, mono compatibility) and distinguishes it from sibling analysis tools by focusing on phase and mono issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for diagnosing phase problems and mono compatibility but does not explicitly state when to use this tool over alternatives like analyze_stereo or analyze_spectrum, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_song_structureA
Read-only

Analyze song structure by segmenting MIDI content into structural parts.

Scans all note tracks bar-by-bar, computes per-bar features (note density, pitch range, average velocity, active track count), groups consecutive bars into segments, and classifies each segment as intro/verse/chorus/bridge/ outro/breakdown based on density and energy patterns.

Essential for: understanding existing arrangements, finding where sections change, verifying song form, and planning variations or extensions.

unit_index: AU index (-1 = all AUs). bars_per_segment: Minimum bars per structural segment (default 4). Groups of bars with similar density are merged into segments of at least this length.

Returns per-segment classification with bar range, density, energy, and feature summary.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexNo
bars_per_segmentNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains the behavior: scans all note tracks, computes per-bar features, groups consecutive bars, and classifies segments. It also mentions the return format (per-segment classification with bar range, density, energy, feature summary). The annotation readOnlyHint: true is consistent with the analysis nature. The description adds behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: first sentence states the core action, then details the method, then lists essential use cases, finally explains parameters. Every sentence adds value; no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and the presence of an output schema, the description covers all necessary context: input parameters, process, and return values. It is complete enough for an agent to understand what the tool does and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description fully explains both parameters: unit_index ('AU index (-1 = all AUs)') and bars_per_segment ('Minimum bars per structural segment... groups of bars with similar density are merged...'). This adds significant meaning beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze song structure by segmenting MIDI content into structural parts.' It details the method (bar-by-bar, per-bar features, grouping, classification) and lists specific section types (intro/verse/chorus/bridge/outro/breakdown). This distinguishes it from sibling analysis tools like analyze_dynamics or analyze_harmonic_rhythm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases: 'Essential for: understanding existing arrangements, finding where sections change, verifying song form, and planning variations or extensions.' This guides the agent on when to use the tool. However, it does not explicitly state when not to use it or contrast with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_spectrumA
Read-only

Spectral analysis of audio across 7 ISO frequency bands.

Divides the spectrum into standard bands:

  • sub_bass (20-60 Hz), bass (60-250 Hz), low_mids (250-500 Hz), mids (500-2000 Hz), high_mids (2000-4000 Hz), presence (4000-6000 Hz), brilliance (6000-20000 Hz)

Per band: RMS (linear + dB), peak (dB), energy percentage. Global descriptors:

  • spectral_centroid_hz: brightness (weighted mean frequency)

  • spectral_spread_hz: frequency variance around centroid

  • spectral_rolloff_95_hz: frequency below which 95% of energy lies

  • low_high_ratio: energy <250 Hz / energy >250 Hz (tonal balance)

  • spectral_crest: peak/mean power ratio (tonal vs noisy)

Use after analyze_track for mix decisions:

  • High low_high_ratio → bass-heavy mix, may need EQ cut in low mids

  • Low spectral_centroid → dark/muffled, consider high shelf boost

  • High spectral_centroid → bright/harsh, consider high shelf cut

  • Dominant band energy_pct → where the mix lives

Args: filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns band-by-band analysis + global spectral descriptors + mix suggestions.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, and the description consistently describes a read-only analysis. It elaborates on what bands and global descriptors are computed, and mentions the return structure, providing good behavioral detail. No contradictions, but could mention that it requires a valid WAV file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Moderately long but well-organized with bullet points and examples. Front-loaded with purpose and followed by useful details. Could be slightly more concise, but no unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, readOnlyHint annotation, and output schema (present), the description covers all essential aspects: what it does, what it returns (bands + global descriptors + suggestions), and how to use it. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description fully explains the single parameter 'filename' with both relative and absolute path options, adding significant meaning beyond the schema's bare 'string' type. Since schema coverage is 0%, the description carries the full burden and does so excellently.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Spectral analysis of audio across 7 ISO frequency bands' and lists the specific bands and metrics, making the tool's purpose unmistakable. It distinguishes itself from siblings like analyze_track by focusing on detailed frequency band analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after analyze_track for mix decisions' and provides concrete examples of when to use based on specific metric values (e.g., high low_high_ratio, low spectral_centroid), offering actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_stereoA
Read-only

Stereo analysis of audio — width, L/R balance, mono compatibility, mid/side energy.

Analyzes the stereo field of a track:

  • stereo_width: Side/Mid RMS ratio (0 = mono, 0.5+ = wide, 1.0 = hard panned)

  • lr_balance: L/R energy difference (-1 = fully left, 0 = centered, +1 = fully right)

  • phase_correlation: -1 to +1 (+1 = mono safe, 0 = uncorrelated, -1 = out of phase)

  • mono_compatible: True if phase correlation > 0 (collapses to mono without cancellation)

  • phase_issues_pct: % of samples where L and R have opposite polarity

  • Per-region width: low (<250Hz), mid (250-4000Hz), high (4000+Hz) Helps identify if stereo width is well-distributed or concentrated in one region

Mix decision guidance:

  • stereo_width < 0.1 → narrow/mono mix, consider widening

  • stereo_width > 0.8 → very wide, check mono compatibility

  • phase_correlation < 0 → phase issues, will cancel in mono

  • lr_balance > 0.2 → right-heavy, consider rebalancing

  • lr_balance < -0.2 → left-heavy, consider rebalancing

  • Low-freq width > 0.3 → bass is wide (usually undesirable, keep bass mono)

Args: filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns stereo descriptors, per-region width, and mix suggestions.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds value by detailing behavioral aspects (returns metrics, per-region width, mix suggestions) and does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, metric details, mix guidance, and args list. While somewhat long, every section adds unique value; a slight trim could improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description appropriately covers parameter usage and metric interpretation, though it could mention prerequisites like file existence. Overall, it is comprehensive for a read-only analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully explains the filename parameter, including valid paths and constraints ('Name of the WAV file in the exports directory (without path), or absolute path to any WAV file'), adding essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Stereo analysis of audio — width, L/R balance, mono compatibility, mid/side energy' and lists specific metrics, clearly distinguishing this tool from sibling analysis tools like analyze_phase and analyze_dynamics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed 'Mix decision guidance' explaining when to use based on metric thresholds (e.g., stereo_width < 0.1 → narrow mix), but does not explicitly compare with sibling tools or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_analyze_trackA
Read-only

Full audio analysis in one call — BPM + key + LUFS + duration + dynamic range.

Composite tool that runs detect_bpm + detect_key + measure_lufs in a single call. Eliminates 3 separate calls for track analysis. Essential for Suno remix pipeline: download_audio → analyze_track → set_bpm + matching progression → import → mix → render.

filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns: bpm, bpm_confidence, key, mode, key_confidence, lufs_integrated, true_peak_db, duration_seconds, sample_rate, channels, dynamic_range, alternatives (key alternatives), chroma.

Examples: result = analyze_track("suno_track.wav")

→ {bpm: 128.0, bpm_confidence: 0.85, key: "A", mode: "minor",

lufs_integrated: -14.2, duration_seconds: 30.0, ...}

Then use results for remix:

set_bpm(result.bpm) create_progression_from_key(result.key, result.mode, "synthwave")

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, and the description adds value by explaining it is a composite tool that runs multiple analysis functions, lists all return fields, and shows example output. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary sentence, explanation of composition, pipeline context, parameter description, list of returns, and an example. It is slightly long but every section adds value and is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description sufficiently explains return fields and shows an example. The pipeline context and parameter semantics make it complete for a single-parameter analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'filename' is explained in the description: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds meaningful context beyond the schema's type definition, especially since schema coverage is 0%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'full audio analysis in one call' including BPM, key, LUFS, duration, and dynamic range. It explicitly characterizes itself as a composite tool replacing three separate calls (detect_bpm, detect_key, measure_lufs), distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a specific pipeline example for the Suno remix workflow and notes that it eliminates three separate calls. While it does not explicitly list when not to use it or alternative tools, the context is clear and helpful for the intended use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_articulationA

Apply articulation to existing notes — staccato, legato, tenuto, accent.

Reshapes note durations relative to their grid position to change phrasing character. Unlike velocity_curve (dynamics) or humanize (random), this applies deterministic duration ratios — the fundamental dimension of musical articulation.

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all regions on the track). articulation: Articulation type:

  • "staccato" — shorten notes to fraction of their grid slot (default 50%)

  • "legato" — extend notes to nearly the next note's start (default 95%)

  • "tenuto" — hold notes to full grid slot (100%, no gap, no overlap)

  • "accent" — boost velocity on notes that fall on beat boundaries (downbeats) amount: Articulation depth 0-1 (default 0.5):

  • staccato: fraction of slot (0.3 = very short, 0.7 = moderate)

  • legato: overlap fraction (0.9 = near-full, 0.5 = half-fill)

  • tenuto: (unused, always full)

  • accent: velocity boost amount (0.3 = subtle, 1.0 = strong accent)

Returns per-region note counts and total notes reshaped.

Examples: apply_articulation(articulation="staccato", amount=0.3) # crisp, detached apply_articulation(articulation="legato", amount=0.95) # smooth, connected apply_articulation(articulation="accent", amount=0.8) # strong downbeat accents

ParametersJSON Schema
NameRequiredDescriptionDefault
amountNo
unit_indexNo
track_indexNo
articulationNostaccato
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the deterministic nature, how each articulation reshapes durations, and what the tool returns. Missing potential side effects but still thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, parameter details, and examples. It is appropriately sized for the tool's complexity, with no redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and output schema present, the description covers all major aspects: parameter meanings, articulation behaviors, and return value. Minor omissions like error handling, but sufficiently complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates well. It explains each parameter with defaults, ranges (e.g., amount 0-1), and effects per articulation type. Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies articulations (staccato, legato, tenuto, accent) to existing notes, with a specific verb and resource. It distinguishes from siblings like velocity_curve and humanize by explaining it applies deterministic duration ratios.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool, including comparisons with alternatives (velocity_curve, humanize). It gives examples of articulation usage but does not explicitly state when not to use it, though the context is sufficient for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_contourA

Apply a melodic contour shape to existing notes.

Redistributes note pitches to follow a specified contour profile while keeping timing and duration unchanged. Unlike transpose_notes (uniform shift), this reshapes the melody direction — ascending, descending, arch, inverted arch, wave, or custom.

The tool calculates a target pitch for each note based on its position in the sequence (0..1 normalized) mapped through the contour function, then snaps to the nearest scale degree if requested. The original pitch range center is preserved.

Contours:

  • "ascending": low to high across the phrase

  • "descending": high to low

  • "arch": rise then fall (peak at midpoint)

  • "inverted_arch": fall then rise (valley at midpoint)

  • "wave": sinusoidal up-down-up

  • "escalating": stepwise ascending with plateaus

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) contour: Contour shape name range_semitones: Pitch range span in semitones (1-48, default 12=octave) snap_to_scale: Scale for snapping results (""=chromatic, "major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues") root: Root note for scale snapping preserve_first: Keep first note pitch unchanged preserve_last: Keep last note pitch unchanged

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
contourNoarch
unit_indexYes
track_indexYes
region_indexNo
preserve_lastNo
snap_to_scaleNo
preserve_firstNo
range_semitonesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist; the description discloses that pitches are redistributed, timing and duration unchanged, snap-to-scale option, and preservation of original pitch range center. It does not mention return values or potential side effects beyond modification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: starts with one-sentence summary, then explanatory paragraph, lists contour shapes, then parameter descriptions. Efficient with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core functionality and parameters well. Does not describe return values or error conditions, but the presence of an output schema reduces the need. Overall adequate for a transformation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds extensive meaning: explains all parameters (unit_index, track_index, region_index, contour, range_semitones with range, snap_to_scale with options, root, preserve_first/last). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies a melodic contour shape to existing notes, contrasting with transpose_notes. It provides specific verb and resource, and distinguishes from sibling tools by explaining the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with transpose_notes, providing an alternative. It implies when to use this tool (reshaping melody) vs uniform shift, but lacks explicit 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_full_mixA

Apply a complete mix in one call — genre-aware processing chains on every track + mastering.

Replaces 5-6 separate calls (add_drum_chain + add_bass_chain + add_instrument_chain × N + add_mastering_chain). Each track gets the right chain with genre-appropriate style automatically.

genre: Determines chain styles per track. Supported: dnb, liquid_dnb, house, trap, techno, dubstep, afrobeat, rock, jazz, pop, funk, reggae, synthwave, trance, disco unit_index: Target audio unit. num_tracks: Number of note tracks in the unit (default 4). Track 0 = drums, Track 1 = bass, Track 2+ = melodic/instrument. master_lufs: Mastering LUFS target (-14 Spotify, -10 loud, -16 Apple).

Chain assignment per track: Track 0 → add_drum_chain (genre-aware style) Track 1 → add_bass_chain (genre-aware style) Track 2+ → add_instrument_chain (genre-aware style) Output → add_mastering_chain

Returns summary of all chains applied.

Example:

Full mix for a 4-track house project

apply_full_mix("house", unit_index=0, num_tracks=4)

Loud techno master

apply_full_mix("techno", num_tracks=3, master_lufs=-10)

ParametersJSON Schema
NameRequiredDescriptionDefault
genreNopop
num_tracksNo
unit_indexNo
master_lufsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the chain assignment per track and genre-aware style selection, and notes it returns a summary. However, it does not disclose whether existing chains are overwritten or merged, which is a key behavioral detail for a composite operation. With no annotations, more transparency is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with clear sections, bullet points for genres and track assignments, and an example call. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, composite operation), the description covers the overall purpose, parameters, track mapping, and provides an example. It is mostly complete but lacks information about whether existing chains are cleared or merged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains all 4 parameters: genre with a list of 15 supported styles, unit_index as target audio unit, num_tracks with track-to-chain mapping, and master_lufs with concrete examples like -14 for Spotify. This provides significant additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it applies a complete mix in one call with genre-aware processing chains on every track plus mastering. It explicitly contrasts with separate chain addition tools like add_drum_chain and add_bass_chain, providing strong purpose differentiation from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that this tool replaces 5-6 separate calls and details when to use it for full mixing. It does not explicitly state when not to use it (e.g., for per-chain adjustments), but the context strongly implies the composite use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_genre_humanizationA

Apply genre-aware humanization to arrangement tracks — makes programmed MIDI feel alive.

After creating an arrangement, notes are perfectly quantized — robotic. This tool applies genre-appropriate humanization: jazz gets loose timing and wide velocity variation, electronic genres stay tight with minimal variation, funk gets behind-the-beat pocket feel.

Each genre has a different humanization recipe:

  • Jazz: high timing variation (0.20), high velocity variation (0.20), swing 0.66 (classic jazz swing feel). Drums get the most humanization.

  • Funk: behind-the-beat timing (positive bias), medium velocity variation, swing 0.0 (straight 16ths but with pocket feel).

  • Rock: medium timing (0.10), medium velocity (0.12), no swing. Drums get slight push, bass stays tight.

  • Reggae: laid-back timing (positive bias, behind beat), medium velocity, no swing. Bass stays tight (it's the lead), drums get loose.

  • Pop: very subtle (0.05 timing, 0.08 velocity), no swing. Pop should sound polished, not loose.

  • DnB/House/Techno/Trance/Synthwave/Dubstep/Trap: minimal humanization. Electronic genres should sound tight and consistent. Timing 0.03, velocity 0.05, no swing.

  • Afrobeat: medium timing (0.12), medium velocity (0.15), no swing. Polyrhythms need some human feel but stay grounded.

  • Disco: subtle timing (0.06), medium velocity (0.10), no swing. Disco should sound tight but not robotic — live drummer feel.

genre: One of: dnb, house, trap, techno, dubstep, afrobeat, rock, jazz, pop, funk, reggae, synthwave, trance, disco unit_index: AU index with the arrangement tracks. drum_track / bass_track / harmony_track / melody_track: Track indices. has_4th_track: True if arrangement has 4 tracks (False for 3-track genres).

Returns humanization parameters applied per track.

Example:

After: create_jazz_arrangement(...)

apply_genre_humanization("jazz", unit_index=0)

After: create_dnb_arrangement(...)

apply_genre_humanization("dnb", unit_index=0, has_4th_track=False)

ParametersJSON Schema
NameRequiredDescriptionDefault
genreYes
bass_trackNo
drum_trackNo
unit_indexNo
melody_trackNo
harmony_trackNo
has_4th_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully informs behavior. It details per-genre humanization (timing variation, velocity, swing) and notes that it affects tracks (drum, bass, harmony, melody). It mentions returns, but not reversibility. Still, transparency is strong given the informative genre recipes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured: purpose, context, detailed genre recipes, parameter list, and example. Each section serves a purpose, especially the genre recipes which are essential for correct use. Could be slightly more concise (e.g., table for genres), but overall earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the description mentions returns, the description is fairly complete. It explains all 7 parameters, provides examples, and gives extensive genre context. Missing some nuance on track indices, but adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It lists parameters (genre, unit_index, drum_track, etc.) and explains genre values and their effects. However, it does not fully explain each track index's role beyond name and example, and 'unit_index' is only briefly described. Adding more detail would improve parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Apply genre-aware humanization to arrangement tracks — makes programmed MIDI feel alive.' It uses specific verb (apply) and resource (genre humanization on arrangement tracks). It distinguishes from siblings like 'humanize_notes' by focusing on genre-aware, whole-arrangement humanization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use: after creating an arrangement when notes are 'perfectly quantized — robotic.' It provides genre-specific humanization recipes, implying context. However, it does not explicitly state when not to use or list alternatives among siblings, but the genre-awareness provides clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_genre_mixA

Apply genre-specific mixing effects to tracks after creating an arrangement.

Closes the loop: create arrangement → apply genre mix → ready to render. One call replaces 10-20 manual add_effect + set_effect_parameter calls.

Each genre has a different effect chain recipe:

  • Drums: compressor (genre-specific ratio/threshold) + EQ

  • Bass: EQ (HPF + low boost) + saturation (genre-specific)

  • Chords/Melody: reverb (genre-specific decay) + delay (if applicable)

  • Extra track: genre-specific treatment

  • Sidechain: drums→bass (if applicable to genre)

genre: One of: dnb, house, trap, techno, dubstep, afrobeat, rock, jazz, pop, funk, reggae unit_index: AU index with the arrangement tracks. num_tracks: Number of tracks to mix (3 or 4, must match arrangement). sidechain: Whether to add sidechain drums→bass (True for electronic genres, False for organic).

Returns effects added per track and parameter values.

Example:

After: create_dnb_arrangement(...)

apply_genre_mix("dnb", unit_index=0, num_tracks=3, sidechain=True)

After: create_jazz_arrangement(...)

apply_genre_mix("jazz", unit_index=0, num_tracks=4, sidechain=False)

ParametersJSON Schema
NameRequiredDescriptionDefault
genreYes
sidechainNo
num_tracksNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that it adds effects per track with genre-specific recipes, sidechain behavior, and returns effects added per track. It could mention reversibility or idempotency, but it is still transparent enough for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a short header, followed by workflow context, bullet points detailing genre recipes, parameter explanations, and an example. Every sentence adds value and it is front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, output schema exists), the description is complete: it explains the workflow, genre-specific behavior, parameter constraints, and what is returned. The presence of an output schema reduces the need for return value detail, and the description covers the rest thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It does: it lists valid genre values, explains unit_index, num_tracks (must match arrangement), and sidechain (with guidance on when to set True/False). This adds critical meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies genre-specific mixing effects to tracks after creating an arrangement. It uses specific verbs and resources (apply, genre mix) and distinguishes itself from sibling tools like apply_full_mix or apply_mix_preset by being part of a pipeline (create arrangement → apply genre mix → ready to render).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Closes the loop: create arrangement → apply genre mix → ready to render' and mentions it replaces 10-20 manual calls, giving clear context for when to use it. However, it does not explicitly state when not to use it or compare with alternatives like apply_full_mix, so it is not a perfect 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_mix_presetA

Apply a mix preset to all audio units in one call — volume, pan, mute, solo.

Replaces 10-30 set_track_volume/set_track_panning/set_track_mute calls. Presets can be genre-specific or custom JSON.

preset: JSON object mapping unit indices to settings: {"0": {"volume_db": -3, "panning": 0.0, "mute": false}, "1": {"volume_db": -6, "panning": -0.3, "solo": false}, ...}

Alternatively, use a named preset: "lofi", "house", "balanced", "wide"

Returns applied settings per unit.

Example: preset='{"0":{"volume_db":-3,"panning":0},"1":{"volume_db":-6,"panning":-0.3}}' preset='lofi' (built-in: kicks +0, bass -3, synths -6, wide pans)

ParametersJSON Schema
NameRequiredDescriptionDefault
presetYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool applies settings to all audio units, returns applied settings, and can use named presets. However, it does not mention prerequisites (e.g., units must exist), error handling (e.g., invalid preset keys), or side effects (e.g., overwriting existing settings). Given no annotations, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a lead sentence, bullet-like sections, and examples. It is reasonably concise but includes some redundancy (the example repeats the preset format already described). Overall, it earns its space and is front-loaded with the key purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (applies mix to all units), no annotations, and low schema coverage, the description is quite complete. It covers the action, parameter format, built-in presets, and return value. Minor gaps: it doesn't explain behavior for non-existent units or invalid preset keys. But overall, it provides sufficient context for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain the 'preset' parameter. It does so in detail: the parameter can be a JSON string with unit indices and settings (volume_db, panning, mute, solo) or a named preset string like 'lofi'. It provides concrete examples and even describes the built-in presets. This exceeds what the schema alone conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Apply a mix preset to all audio units in one call — volume, pan, mute, solo.' This clearly states the verb (apply), resource (mix preset to all audio units), and scope (volume, pan, mute, solo). It explicitly distinguishes from sibling tools like set_track_volume by noting it replaces 10-30 individual calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool: when you want to apply a mix preset to all units and replace many individual set_* calls. It mentions alternatives (named presets vs custom JSON) and gives examples. It does not explicitly state when not to use, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_rhythm_patternA

Apply a rhythmic pattern to existing notes — reposition onsets to match a target grid.

Takes a rhythm pattern (either a rhythm_string like "x.x.x..x" or an onset_grid like "1,0,1,0,1,0,0,1") and repositions existing notes onto the onset positions. This is the inverse of extract_rhythm — it lets you stamp a groove onto any note content.

How it works:

  1. Reads existing notes and their pitches/velocities/durations

  2. Computes the target onset positions from the pattern (cycling if pattern is shorter than the region)

  3. Distributes notes across onset positions:

    • If fewer onsets than notes: extra notes are placed at the nearest onset

    • If more onsets than notes: notes are assigned round-robin to onsets

  4. Optionally adjusts velocity (accent onsets) and duration (staccato/legato)

velocity_mode:

  • "preserve": keep original velocities

  • "accent": strong beats (0,4,8,12 in 16th) get +20% velocity, weak get -10%

  • "flat": all notes get 0.8 velocity

  • "pattern": use onset_velocities from extract_rhythm if provided in onset_grid

duration_mode:

  • "preserve": keep original durations

  • "staccato": each note lasts 50% of the grid step

  • "legato": each note lasts until the next onset

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = first region). rhythm_string: Compact pattern "x.x.x..x" (x=onset, .=rest). Used if onset_grid is empty. onset_grid: Comma-separated "1,0,1,0,1,0,0,1" or "1;0.5;0;0.8" (value=velocity). Takes priority over rhythm_string. grid: Grid resolution (16th/8th/32nd/quarter). velocity_mode: How to handle velocities (preserve/accent/flat/pattern). duration_mode: How to handle durations (preserve/staccato/legato).

Returns modification summary with repositioned note count.

Example:

Extract groove from drums, apply to bass

rhythm = extract_rhythm(0, 0, grid="16th")

... parse rhythm_string from result ...

apply_rhythm_pattern(0, 1, rhythm_string="x...x...x...x...", grid="16th")

ParametersJSON Schema
NameRequiredDescriptionDefault
gridNo16th
onset_gridNo
unit_indexYes
track_indexYes
region_indexNo
duration_modeNopreserve
rhythm_stringNo
velocity_modeNopreserve

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses the tool's behavior: it reads existing notes, computes target onsets, distributes notes round-robin or to nearest onset, and optionally adjusts velocity/duration. Edge cases like pattern cycling and note distribution are explained, making the tool's behavior completely transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear introductory sentence, a 'How it works' section, parameter definitions, and an example. Every sentence contributes meaning, and there is no redundancy. It is comprehensive yet concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 8 parameters, no schema descriptions, no annotations, and an output schema, the description covers all necessary context: algorithm steps, parameter details, edge cases, and return value. It is fully sufficient for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It does so thoroughly by explaining each of the 8 parameters, including their format, default values, and behavioral implications (e.g., velocity_mode options, rhythm_string vs onset_grid priority). This adds immense value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: apply a rhythmic pattern to existing notes by repositioning onsets. It uses specific verb+resource ('apply a rhythmic pattern') and distinguishes itself as the inverse of 'extract_rhythm.' The sibling context is implicitly handled by explaining the relationship to extraction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool, including an example workflow with extract_rhythm. However, it does not explicitly state when not to use it or list alternative tools beyond mentioning its inverse relationship. The guidance is strong but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_sidechainA

Apply sidechain ducking via volume automation — the classic pumping/breathing effect.

Simulates sidechain compression by creating volume automation that ducks on every kick beat and recovers. This is the signature sound of house, techno, EDM, and modern pop. Works by creating automation events on the target track's volume parameter.

unit_index: AU index whose volume will be automated. track_index: Track index (-1 = all tracks on the AU). bars: Number of bars to fill with sidechain (1-16). start_beat: Starting beat position. depth: Ducking depth 0-1 (0.6 = volume drops to 40% on each kick, 0.8 = drops to 20%). attack: Attack time in beats (how fast volume drops, 0.01 = instant, 0.05 = smooth). release: Release time in beats (how fast volume recovers, 0.3 = classic, 0.5 = slow pump). kick_interval: Kick spacing in beats (1.0 = every beat, 2.0 = every 2 beats, 0.5 = 16th kicks).

Returns total automation events created and ducking pattern info.

Example: apply_sidechain(unit_index=0, bars=8, depth=0.7, release=0.25, kick_interval=1.0)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
depthNo
attackNo
releaseNo
start_beatNo
unit_indexYes
track_indexNo
kick_intervalNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description provides good transparency: it creates volume automation events on the target track's volume parameter, and details return info (total events, ducking pattern). It lacks mention of whether existing automation is overwritten.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose line, context, parameter list, return info, and example. It is slightly lengthy but each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 params, 1 required, output schema present), the description covers most aspects: how it works, parameter roles, return values, and example. Minor gap: no mention of prerequisites (e.g., need an existing kick track).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 8 parameters are explained with definitions, example values, and ranges, compensating for the 0% schema description coverage. For instance, depth: '0.6 = volume drops to 40% on each kick, 0.8 = drops to 20%'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies sidechain ducking via volume automation, specifying the classic pumping/breathing effect. It distinguishes from sibling tools like mcp_opendaw_connect_sidechain by focusing on simulation via automation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for house, techno, EDM, pop) and how it works, but does not explicitly state when not to use it or alternative tools like actual sidechain compression via connect_sidechain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_swingA

Apply swing feel to existing notes without changing velocity or duration.

Swing shifts every other grid position later, creating a triplet/shuffle feel. Unlike humanize_notes (which couples swing with random velocity/timing changes), this tool applies pure swing — deterministic, no randomness, reversible.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). swing_amount: Swing depth 0-1 (0 = straight, 0.5 = light swing, 1.0 = full triplet). 0.55-0.66 = classic hip-hop/lofi swing. grid: Grid to swing against — "16th" (default, shifts odd 16ths) or "8th" (shifts odd 8ths).

Returns per-track note counts shifted.

Example: apply_swing(unit_index=0, track_index=0, swing_amount=0.58, grid="16th")

ParametersJSON Schema
NameRequiredDescriptionDefault
gridNo16th
unit_indexNo
track_indexNo
swing_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description clearly states the tool is deterministic, reversible, and does not change velocity or duration. It does not mention potential side effects or limitations, but the stated properties give good behavioral context for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief summary sentence, then an explanation of the effect, sibling differentiation, parameter details, and an example. It is slightly verbose in the parameter section but front-loaded with the main purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All four parameters are explained, the behavior is described, and a usage example is given. The return value is briefly mentioned ('Returns per-track note counts shifted'), which is sufficient given the presence of an output schema. The tool is non-destructive and reversible, so no additional safety context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description fully compensates by explaining each parameter in detail: unit_index, track_index, swing_amount (with specific ranges), and grid (valid values). It also provides an example usage. This adds significant meaning beyond the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it applies swing feel to existing notes without changing velocity or duration, and distinguishes itself from the sibling tool 'humanize_notes' which couples swing with random changes. The verb 'apply' and resource 'swing feel to notes' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly compares to 'humanize_notes' and states this tool applies pure, deterministic, reversible swing. It provides guidance on swing_amount values (e.g., 0.55-0.66 for hip-hop/lofi). However, it does not explicitly state when not to use this tool or when to prefer alternatives beyond that single comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_velocity_curveA

Apply a velocity envelope across notes — ramp, arc, trough, or custom power curve.

Maps each note's position within its region to a velocity value via a mathematical curve. Unlike humanize_notes (random variation), this applies a deterministic envelope shape — useful for build-ups, fade-ins, crescendo rolls, and expressive phrasing.

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all regions on the track). curve_type: Curve shape:

  • "ramp_up" — linear increase from start_velocity to end_velocity

  • "ramp_down" — linear decrease from start_velocity to end_velocity

  • "arc" — rises to end_velocity then falls back to start_velocity (peak in middle)

  • "trough" — falls to start_velocity then rises to end_velocity (dip in middle)

  • "power" — exponential curve controlled by 'power' param (>1 = fast rise, <1 = slow rise) start_velocity: Velocity at curve start 0-1 (default 0.3). end_velocity: Velocity at curve end 0-1 (default 1.0). power: Exponent for "power" curve type (default 1.0 = linear). 2.0 = sharp attack, 0.5 = slow swell.

Returns per-region note counts and total notes shaped.

Examples: apply_velocity_curve(curve_type="ramp_up", start_velocity=0.2, end_velocity=1.0) # build-up apply_velocity_curve(curve_type="arc", start_velocity=0.4, end_velocity=0.95) # expressive phrase apply_velocity_curve(curve_type="power", power=2.0, start_velocity=0.1, end_velocity=1.0) # sharp attack

ParametersJSON Schema
NameRequiredDescriptionDefault
powerNo
curve_typeNoramp_up
unit_indexNo
track_indexNo
end_velocityNo
region_indexNo
start_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses behavior: maps note position to velocity via mathematical curves, explains each curve type's shape, and indicates return value (per-region counts). This goes beyond minimal requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: one-line summary, behavioral paragraph, parameter breakdown, return info, and examples. Every sentence adds value; no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage guidance, parameter semantics, behavior, return values, and examples. The output schema exists, and the description still explains what is returned. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining all 7 parameters: unit_index, track_index, region_index, curve_type (with 5 shapes), start_velocity, end_velocity, and power. It also provides default values and examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies a velocity envelope across notes, specifying deterministic curve shapes. It distinguishes from 'humanize_notes' by contrasting deterministic vs random, providing a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (deterministic envelope for expressive phrasing) vs alternative ('humanize_notes' for random variation). Also provides examples for common use cases like build-ups and crescendo rolls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_velocity_lfoA

Apply periodic velocity modulation — velocity LFO along note positions.

Oscillates note velocity cyclically based on each note's position, creating pumping, breathing, or wave-like dynamic motion. Unlike apply_velocity_curve (monotonic ramps), this creates REPEATING velocity patterns synced to beat positions.

Args: unit_index: Audio unit index track_index: Note track index rate: LFO cycles per beat (0.25=every 4 beats, 1.0=per beat, 2.0=twice per beat, 0.5=every 2 beats) depth: Modulation depth 0-1 (0=no change, 0.3=subtle breathing, 1.0=full swing from 0 to max) shape: LFO waveform — "sine" (smooth), "triangle" (linear), "saw" (ramp up), "square" (on/off), "random" (per-beat random) phase: Starting phase 0-1 (0=begin at peak, 0.25=begin at zero rising, 0.5=begin at trough, 0.75=begin at zero falling) center: Center velocity around which modulation oscillates (0-1). The LFO modulates ±depth*center around this value. region_index: Specific region (-1 = all regions)

Returns: JSON with notes_processed, modulation stats (min/max/avg velocity before and after), regions_processed, rate, depth, shape.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateNo
depthNo
phaseNo
shapeNosine
centerNo
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description thoroughly explains the behavior: oscillates velocity cyclically based on note position, creates repeating patterns, and details the modulation parameters and their effects. Also documents return values. Some implicit behavior (like how rate syncs to beat) could be more explicit, but overall very informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured: a brief summary, an explanation of the modulation effect, a key distinction from a sibling tool, a detailed Args list, and a Returns section. Every section adds value, though the Args list could be slightly more concise by integrating with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, output schema exists), the description is exceptionally complete. It covers all parameters, distinguishes from a relevant sibling, and describes return values. No gaps are evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the tool description includes a comprehensive Args section that explains each of the 8 parameters with examples, defaults, and meaning (e.g., rate cycles per beat, depth as modulation depth, shape waveforms, etc.). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it applies periodic velocity modulation using LFO, and explicitly contrasts with apply_velocity_curve which does monotonic ramps. The purpose is specific and easily distinguished from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use this tool (for repeating velocity patterns) and when to use apply_velocity_curve (for monotonic ramps). Includes details on the modulation effect (pumping, breathing, wave-like motion).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_apply_velocity_patternA

Apply a cyclic velocity pattern to existing notes in a region.

The producer's accent pattern tool. Instead of a linear ramp (crescendo), this applies a repeating velocity pattern across notes — the foundation of groove. Examples: strong-weak-medium-weak (backbeat emphasis), staggered accents for syncopation, or dynamic intensity layers.

unit_index: AU index. track_index: Track index. pattern: JSON array of velocity multipliers 0.0-1.0. Cycled across notes in order of position. Example: [1.0, 0.5, 0.7, 0.5] = strong-weak-medium-weak. region_index: Region index (-1 = first region). mode: "cycle" (repeat pattern from start, default) or "stretch" (distribute pattern evenly across all notes — good for 2-note patterns on 16 notes). base_velocity: Base velocity 0-1 that multipliers are applied to (default 0.8). Final velocity = base_velocity * pattern[i % len].

Returns notes modified, pattern applied, and velocity preview.

Examples: apply_velocity_pattern(unit_index=0, track_index=0, pattern="[1.0, 0.5, 0.7, 0.5]") -> 4-note accent cycle: strong-weak-medium-weak on every group of 4 notes apply_velocity_pattern(unit_index=0, track_index=0, pattern="[1.0, 0.3]", base_velocity=0.9) -> Alternating strong/weak at 0.9 and 0.27 apply_velocity_pattern(unit_index=1, track_index=0, pattern="[0.8, 0.4, 0.6, 0.4, 0.9, 0.4, 0.7, 0.4]", mode="stretch") -> 8-note pattern stretched across all notes in region

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNocycle
patternYes
unit_indexYes
track_indexYes
region_indexNo
base_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries full responsibility. It discloses destructive modification of notes, provides the velocity calculation formula, and explains modes. It could mention irreversibility or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear first sentence, conceptual paragraph, parameter explanations, and examples. It could be slightly more concise with bullet points for parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, behavior, and examples. Lacks discussion of error handling or edge cases like empty patterns, but sufficient for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 6 parameters are explained in the description, including patterns, modes, defaults, and the effect of base_velocity. This compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'apply' and resource 'cyclic velocity pattern to existing notes in a region', distinguishing it from linear ramps or other velocity tools. It uses specific examples to reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool's role as an accent pattern tool and contrasts with linear ramps, but does not explicitly state when to avoid this tool in favor of alternatives like random or LFO-based velocity changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_augment_notesA

Augment or diminish note durations — the fourth classical transformation.

Multiplies note durations by a factor. Combined with transpose, reverse, and invert, this completes the set of four fundamental motivic transformations used by Bach, Beethoven, and every composition teacher since.

  • factor > 1.0: augmentation (longer notes, slower feel). 2.0 = double duration.

  • factor < 1.0: diminution (shorter notes, faster feel). 0.5 = half duration.

  • factor = 1.0: no change (useful for testing).

Think Beethoven 5th: the opening G-G-G-Eb motif returns augmented (twice as slow) in the recapitulation. Or Bach fugues where the subject appears in diminution (twice as fast) in the finale.

factor: Duration multiplier (0.25-4.0). 2.0 = augmentation, 0.5 = diminution. unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all regions on the track). mode: How to handle note positions — "scale" (default): multiply both duration AND position relative to region start. The entire phrase slows down or speeds up — notes stay in sequence. "stretch": multiply only duration, leave positions unchanged. Notes become longer/shorter but don't move — may overlap or leave gaps.

Returns count of notes augmented and notes skipped (duration too short/long).

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoscale
factorYes
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the effect on durations, mode behavior (scale vs stretch), and return values (counts of augmented and skipped notes). It does not explicitly state that the tool mutates project state, but the mutation is implied. Could be improved with a caution about destructive changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but verbose, including historical examples and references that may not be essential for an LLM agent. While the first sentence front-loads the purpose, the subsequent paragraphs add context that could be trimmed. Adequate, but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and an empty schema, the description covers all necessary information: tool intent, parameter explanations, mode behavior, and return format. It accounts for the tool's complexity and provides enough context for an agent to use it correctly. The output schema exists but is not needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate fully. It explains factor range (0.25-4.0), default for region_index (-1 = all regions), and mode options with detailed examples of 'scale' (multiply duration and position) vs 'stretch' (duration only). All five parameters are meaningfully described, adding value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool augments or diminishes note durations, positions it as the fourth classical transformation, and differentiates it from siblings like transpose, reverse, invert. Musical examples (Beethoven 5th, Bach fugues) reinforce the purpose and distinguish it from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for duration changes with factor >1 or <1) and provides mode options. However, it does not explicitly mention when NOT to use it or compare with sibling tools like scale_durations, which also modifies durations. Lacks explicit alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_auto_gainA

Auto-adjust output volume to hit a target LUFS.

Iterative loop: render → measure LUFS → adjust Maximizer threshold → re-render. Converges within ±1 LUFS of target.

target_lufs: Target loudness (Spotify -14, YouTube -14, Apple -16). filename: Output filename (without .wav). sample_rate: Export sample rate (default 48000). max_iterations: Max refinement loops (default 3).

Returns final LUFS, threshold applied, iterations, and WAV path.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoauto_gain_mix
sample_rateNo
target_lufsYes
max_iterationsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the iterative process (render, measure, adjust, re-render) and convergence tolerance (±1 LUFS), but lacks details on side effects like whether a Maximizer plugin is required or added, or if the project master is altered. Since no annotations are provided, the description carries the full burden but is somewhat incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (about 120 words), well-structured with an intro, process explanation, and parameter list. Every sentence adds value, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does, how it works, parameter details, and return values. It lacks information on prerequisites or side effects, but given the presence of an output schema, the return value listing is sufficient. Minor gaps prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description individually explains each parameter with examples and defaults (e.g., target_lufs with common values, filename format, sample_rate default 48000, max_iterations default 3). Since schema_description_coverage is 0%, the description fully compensates and adds meaning beyond the schema's field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Auto-adjust output volume to hit a target LUFS.' It specifies the iterative loop and target loudness standards, effectively distinguishing it from sibling tools like measure_lufs or render_and_analyze.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for final loudness normalization but does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons to sibling tools are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_automation_sweepA

Create a smooth automation sweep (ramp) between two values over a beat range.

Generates multiple automation events with interpolated values, creating smooth parameter transitions (filter sweeps, volume fades, pitch drops, etc.) in one call. Automatically creates the automation track if it doesn't exist yet.

unit_index: AU index. parameter_name: Instrument parameter to automate (e.g. "cutoff", "volume", "resonance"). start_beat: Start position in beats. end_beat: End position in beats. start_value: Starting normalized value (0.0-1.0). end_value: Ending normalized value (0.0-1.0). steps: Number of interpolation points (default 16, more = smoother). curve: "linear" (even spacing), "exp" (exponential, good for filter sweeps), "log" (logarithmic).

Returns the number of events created and a preview of the first few points.

Example: Filter sweep from closed (0.1) to open (0.9) over 16 beats: automation_sweep(unit_index=0, parameter_name="cutoff", start_beat=0, end_beat=16, start_value=0.1, end_value=0.9, steps=32, curve="exp")

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNolinear
stepsNo
end_beatYes
end_valueYes
start_beatYes
unit_indexYes
start_valueYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behaviors: generates multiple interpolation points, auto-creates automation track, and returns event count and preview. It does not mention potential overwriting of existing automation, but it is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a header, parameter descriptions, return info, and an example. While it is somewhat lengthy, all sentences are relevant and the structure aids readability. Minor redundancy could be trimmed, but it remains effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, output schema exists), the description is complete. It covers all parameters, explains return values ('number of events created and a preview'), and provides an example. The existence of an output schema reduces the need for detailed return value description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains all 8 parameters with details: unit_index, parameter_name, start_beat, end_beat, start_value, end_value, steps (default 16), and curve ('linear', 'exp', 'log'). The example further clarifies usage. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a smooth automation sweep (ramp) between two values over a beat range.' It specifies the verb (create), resource (automation sweep), and differentiates from siblings like add_automation by emphasizing interpolation and multiple events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an example but lacks explicit guidance on when to use this tool versus alternatives like add_automation or create_filter_sweep. Usage is implied through context, but no when-to-use or when-not-to-use instructions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_balance_track_velocitiesA

Balance velocities across multiple tracks — MIDI mix leveling.

Sets relative velocity levels across multiple note tracks so they sit correctly in the mix. Unlike scale_velocity (one track at a time), this operates on multiple tracks simultaneously and establishes the relative balance between them.

Presets:

  • "mix_balanced" — all tracks equal (~0.75). Neutral starting point.

  • "drums_forward" — drums loudest (0.95), bass (0.80), harmony (0.65), lead (0.70). Hip-hop, rock, electronic.

  • "vocal_forward" — vocal/lead loudest (0.95), pads (0.60), bass (0.75), drums (0.80). Pop, ballad, singer-songwriter.

  • "pads_quiet" — pads very quiet (0.50), arp (0.65), bass (0.80), drums (0.90), lead (0.85). Ambient, cinematic.

  • "bass_heavy" — bass loudest (0.95), drums (0.85), lead (0.70), harmony (0.55). Reggae, dub, trap.

  • "custom" — use target_velocities parameter (comma-separated 0-1 values, one per track in track_indices order).

The tool reads current average velocities, computes scale factors to reach targets, and applies them. Original relative dynamics within each track are preserved (multiply mode).

track_indices: Comma-separated track indices (e.g. "0,1,2,3"). preset: One of the presets above, or "custom". target_velocities: For custom mode — comma-separated target avg velocities (e.g. "0.9,0.7,0.6,0.8"). Must match track_indices count. region_index: Region (-1 = first, -2 = all regions).

Returns per-track velocity stats before/after.

Example:

Balance 4 tracks: drums, bass, pads, lead

balance_track_velocities(0, "0,1,2,3", preset="drums_forward")

Custom: drums=0.9, bass=0.7, pads=0.5, lead=0.8

balance_track_velocities(0, "0,1,2,3", preset="custom", target_velocities="0.9,0.7,0.5,0.8")

ParametersJSON Schema
NameRequiredDescriptionDefault
presetNomix_balanced
unit_indexYes
region_indexNo
track_indicesYes
target_velocitiesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully explain behavior. It states that the tool 'reads current average velocities, computes scale factors to reach targets, and applies them' and that 'Original relative dynamics within each track are preserved (multiply mode).' It also notes that it returns per-track velocity stats before/after, giving a complete picture of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections: summary, presets list, behavioral notes, parameter explanations, and a usage example. Every sentence adds value without redundancy. It is concise yet comprehensive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, 0% schema coverage, no annotations, and an output schema (which isn't shown but exists), the description covers all necessary aspects: purpose, when to use, behavior, parameters, return value, and examples. It also differentiates from a sibling tool. The description is complete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains each parameter: track_indices as comma-separated indices, preset as one of five named presets or 'custom', target_velocities for custom mode, and region_index with defaults. It also provides a detailed example showing how to use parameters together.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Balances velocities across multiple tracks — MIDI mix leveling.' It uses a specific verb ('balance velocities') and resource ('multiple tracks'), and distinguishes itself from the sibling tool 'scale_velocity' which operates on one track at a time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (for relative balance across multiple tracks) and when not (use scale_velocity for a single track). It provides multiple presets and a custom mode, along with examples of how to use the tool with different parameter combinations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_batch_diagnosticA

Run full diagnostic on multiple stems in one call — problems + phase + profile comparison.

Phantom's batch_diagnostic equivalent. For each stem runs:

  1. detect_problems (clipping, DC offset, mud, harshness, sibilance, resonance)

  2. analyze_phase (polarity, correlation, mono compat) — stereo files only

  3. compare_to_profile (if genre specified)

Produces a prioritized triage report:

  • dealbreaker: clipping, phase inversion, DC offset

  • significant: mud, harshness, resonance

  • moderate: sibilance risk, width issues

  • minor: slight deviations from profile

filenames: JSON array or comma-separated list of WAV filenames. genre: Optional genre profile for comparison (pop, rock, lo-fi, etc.).

Returns per-stem results + global summary + prioritized fix list.

Example: batch_diagnostic('["vocals.wav","bass.wav","drums.wav","mix.wav"]', genre="rock")

→ {triage: [{stem: "vocals", severity: "significant", problems: [...]}]}

ParametersJSON Schema
NameRequiredDescriptionDefault
genreNo
filenamesYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description transparently covers key behaviors: runs three checks per stem, phase analysis for stereo files only, returns a triage report with severity levels. It does not mention side effects or permissions, but for a read-only diagnostic, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear summary first, then steps, output format, parameter details, and an example. It is slightly verbose but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch diagnostic tool, the description covers the main functionality, parameters, output triage levels, and stereo-only constraint. It could mention file availability or size limits, but overall it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description adds critical meaning: filenames accepts JSON array or comma-separated WAV list, genre is optional with examples (pop, rock, lo-fi). An example usage clarifies expected input format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool runs a full diagnostic on multiple stems including problem detection, phase analysis, and profile comparison. It clearly distinguishes from sibling tools like detect_problems and analyze_phase by batching these operations together.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool is a batch equivalent of Phantom's diagnostic, but does not explicitly state when to use this over individual analysis tools. However, the detailed output structure and prioritized triage report implicitly guide usage for comprehensive batch diagnostics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_capture_realtimeA

Capture realtime audio output from the DAW engine.

Records the live audio output for a specified duration. The engine must be running (call start_engine first). Useful for capturing live playback with effects, automation, and real-time processing.

duration_seconds: How long to record (float, e.g. 10.0). filename: Output WAV filename (without extension).

Returns file path and size, or error if engine not running.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
duration_secondsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions that the tool returns file path and size or an error if the engine is not running. However, it does not disclose whether overwriting occurs, any permissions needed, maximum duration, or the source of the recording (e.g., master output). This is adequate but could be more thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise with three short paragraphs. It front-loads the purpose and then provides parameter details and return info. There is no fluff, but the second paragraph could be slightly streamlined as it partially repeats the first line. Overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema but return value mentioned), the description covers the main aspects: what it does, prerequisite, parameters, and return. It does not mention potential overwrite behavior or recording source, but it is sufficient for the agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage, but the description explains both parameters: 'duration_seconds: How long to record (float, e.g. 10.0)' and 'filename: Output WAV filename (without extension).' This adds meaning beyond the schema by specifying the type, example, and that the extension should not be included. It could additionally mention allowed characters or default path, but it is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Capture realtime audio output from the DAW engine' with a specific verb and resource. It further explains that it records live audio for a given duration and is useful for capturing playback with effects and automation. This distinguishes it from sibling tools like export functions or creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite: 'The engine must be running (call start_engine first).' It also provides context for when to use the tool ('useful for capturing live playback...'). However, it does not explicitly mention when not to use it or provide alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_change_base_signatureA

Change the base time signature of the project.

This changes the initial signature (default 4/4). All existing signature change events are recalculated to preserve their approximate absolute positions.

nominator: Number of beats per bar (e.g. 4 for 4/4, 3 for 3/4, 6 for 6/8). denominator: Beat unit (1=whole, 2=half, 4=quarter, 8=eighth, 16=sixteenth).

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
nominatorYes
denominatorYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that existing signature change events are recalculated to preserve approximate absolute positions, and details parameter meanings, but does not mention potential failure modes or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, starting with a clear summary, then providing necessary details and parameter explanations without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with two parameters and an output schema, the description covers the main behaviors and parameter usage adequately, though a note on return format could be added.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds explicit meaning to both parameters (nominator and denominator) with examples and valid values, compensating for the 0% schema description coverage effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'change' and resource 'base time signature of the project', and distinguishes from siblings like 'add_signature_change' by specifying it alters the initial signature and recalculates existing events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the effect on existing events and that this changes the base signature, but does not explicitly state when to use this tool versus alternatives such as 'add_signature_change' or 'set_time_signature', leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_classify_drum_patternA

Classify a drum pattern from MIDI notes in a region.

Analyzes drum note positions, pitches (GM drum map: 36=kick, 38=snare, 42=closed hat, 46=open hat, 50=high tom, 45=low tom, 49=crash, 51=ride), and velocities to classify the pattern as one of: four-on-the-floor, breakbeat, boom-bap, trap, shuffle, half-time, military/march, amen, unknown.

Essential for: understanding existing drum patterns, matching genre expectations, verifying generated patterns, and suggesting variations.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks). region_index: Region index (-1 = all regions on track).

Returns pattern classification with confidence, features, and per-bar breakdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It details inputs (note positions, pitches via GM map, velocities), outputs (classification, confidence, features, per-bar breakdown), and lists pattern types. It does not explicitly state that the tool is read-only (no side effects), but the context implies it is analytical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: one-sentence summary, details on analysis method, pattern list, use cases, then parameter explanations. It is concise at ~120 words with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's analytical nature and the presence of an output schema, the description covers input selection, analysis parameters, output format (classification with confidence, features, per-bar breakdown), and usage scenarios. It does not detail the output schema fields but that is handled by the structured output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates fully by explaining each parameter: unit_index (AU index, -1 for all), track_index, region_index with defaults. This adds significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool classifies drum patterns from MIDI notes, lists specific pattern types (e.g., four-on-the-floor, breakbeat), and provides the GM drum map. This uniquely distinguishes it from sibling tools like 'analyze_dynamics' or 'transcribe_drums'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases: understanding patterns, matching genre expectations, verifying patterns, and suggesting variations. However, it does not mention when not to use it or suggest alternative tools for related tasks like drum transcription.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_clear_region_notesA
Destructive

Clear all notes from a region while keeping the region on the timeline.

Removes every note event from the specified region(s) but preserves the region itself — its position, duration, and track placement stay intact. This is the "erase and rewrite" operation: the producer wants to clear a region to start fresh, without deleting and recreating the region container.

Different from delete_note_region (which removes the entire region from the timeline) and delete_note (which removes one note at a time).

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all note regions on the track).

Returns notes cleared and remaining region info.

Examples: clear_region_notes(unit_index=0, track_index=0, region_index=0) -> Erase all notes in region 0, region stays on timeline clear_region_notes(unit_index=0, track_index=0, region_index=-1) -> Erase all notes in ALL regions on track 0

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true. Description adds context about what is preserved and the operation's effect, though the behavior is well covered by the purpose statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with core action, followed by explanation, sibling differentiation, parameter details, and examples. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameters, examples, expected output, and distinguishes related tools. Adequate given complexity and presence of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, description compensates by explaining each parameter's meaning (unit_index, track_index, region_index) and provides usage examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool clears all notes from a region while preserving the region. It explicitly distinguishes from siblings delete_note_region and delete_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use scenario ('erase and rewrite') and contrasts with alternative tools, giving clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_clone_clipA

Clone a clip (note or value) on the same track. Optionally consolidate (make event collection unique).

unit_index: AU index. track_index: Track index within the AU. clip_index: Clip index to clone. consolidate: If true, the clone gets its own independent event collection (not shared).

Returns success, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
clip_indexYes
unit_indexYes
consolidateNo
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It explains the 'consolidate' parameter but does not describe side effects (e.g., whether the original clip is modified, where the clone is placed, or permissions required). Important behavioral details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two paragraphs plus parameter list. It front-loads the main action. Parameter descriptions are inline but clear. No unnecessary sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and no annotations, the description covers the basics and explains parameters. However, it lacks details on behavioral impact and precise semantics of 'same track'. Return values are mentioned as success/error, which is sufficient with an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must define parameters. It explains each parameter: unit_index, track_index, clip_index, and consolidate. The meaning of 'consolidate' is clearly explained. However, 'AU index' is not expanded, which could be ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Clone a clip (note or value) on the same track,' using a specific verb and resource. It distinguishes from sibling tools like clone_track, clone_effect_chain, and consolidate_clip by specifying it operates on clips and remains on the same track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for cloning clips on the same track, which differentiates it from tools that copy to other tracks or clone tracks/effects. However, it does not explicitly state when not to use it or mention alternatives, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_clone_effect_chainA

Copy all effects from one audio unit to another, including parameter values.

Useful for applying the same vocal chain (EQ → compressor → reverb) to doubled vocal tracks.

src_unit: Source audio unit index. dst_unit: Destination audio unit index (effects appended to existing chain).

Returns list of cloned effects with their new indices.

ParametersJSON Schema
NameRequiredDescriptionDefault
dst_unitYes
src_unitYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully handles behavioral context. It discloses key traits: copies parameters, appends effects to destination's existing chain, returns list of cloned effects with new indices. This is comprehensive for a clone operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, no fluff. Core action in first sentence, use case in second, parameter explanations in third and fourth, return format in fifth. Well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (clone operation), no output schema needed for completeness, but the description mentions the return format. Context signals (2 params, no nested objects, output schema exists) are adequately addressed. No missing elements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions for parameters (0% coverage), but the description explains each parameter inline: 'src_unit: Source audio unit index.' and 'dst_unit: Destination audio unit index (effects appended to existing chain).' This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Copy all effects from one audio unit to another, including parameter values.' The verb 'copy' and resource 'effect chain' are specific. It distinguishes from siblings like 'duplicate_effect' (single effect) and 'move_effect' by specifying it copies all effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a concrete use case: 'applying the same vocal chain (EQ → compressor → reverb) to doubled vocal tracks.' This helps the agent understand context but does not explicitly mention when not to use or what alternatives exist (e.g., for partial cloning use duplicate_effect individually).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_clone_trackA

Clone a track — full duplication of notes, regions, and structure.

Creates a new track within the same audio unit (or a new audio unit) with all notes from the source track copied over. Optionally transposed, velocity-scaled, and time-shifted.

Unlike copy_notes_to_track (which copies notes between existing tracks), clone_track creates the destination track from scratch with the correct track type (note/audio), then populates it with a region and all notes from the source.

Essential for:

  • Doubling: same notes on two instruments for thicker sound

  • Octave layering: transpose +12 for octave above

  • Parallel harmony: transpose +7 for fifths, +3 for thirds

  • Call-and-response: time_offset to shift the copy later

  • Counterpoint layer: same rhythm, different transposition

Args: unit_index: Source audio unit index track_index: Source track index within the unit name: Optional name for the cloned track (default: same as source) transpose: Semitone transposition applied to cloned notes (-24 to +24, default 0 = same pitch) velocity_scale: Multiply note velocities by this factor (0.1-2.0, default 1.0 = same velocity) time_offset_beats: Shift all notes by this many beats (-16 to +16, default 0.0 = same position) new_unit: If true, create a new audio unit for the clone (requires same instrument type). If false (default), adds a new track to the source audio unit.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo
new_unitNo
transposeNo
unit_indexYes
track_indexYes
velocity_scaleNo
time_offset_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that a new track is created, optionally in a new audio unit, and details parameter effects (transpose, velocity scale, time offset). It does not mention potential limits or undo behavior, but it is largely transparent about the core actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, clarification, comparison, use cases, and parameter list. The use case list is slightly long but adds value. The content is informative without being overly verbose, though could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values are not needed. The description covers tool behavior, when to use, and parameters. It does not explicitly mention error conditions or prerequisites (e.g., track must exist), but the required parameters imply these. Overall, it is fairly complete for a cloning tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (no parameter descriptions). The tool description compensates with an 'Args' section that explains each parameter, including ranges, defaults, and semantics (e.g., transpose -24 to +24, velocity_scale 0.1-2.0). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Clone a track — full duplication of notes, regions, and structure.' It further explains that it creates a new track from scratch with all notes, and explicitly distinguishes from copy_notes_to_track. The use cases (doubling, octave layering, etc.) reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description directly contrasts clone_track with copy_notes_to_track, stating when to use each. It also lists essential scenarios (doubling, octave layering, parallel harmony, etc.) providing clear guidance on when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_compact_tracksA

Remove empty tracks from an audio unit (or all AUs).

Calls ProjectApi.compactTracks() — removes tracks with no regions. Useful cleanup after deleting regions or editing.

unit_index: Audio unit index (-1 = all AUs).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the underlying API call and states removal of tracks with no regions, but does not detail destructiveness, reversibility, or permissions. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three lines with a blank line separating purpose from parameter explanation. Every sentence adds value; no wasted words. Front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple cleanup tool with one parameter and an output schema, the description provides sufficient context. It explains the operation and parameter meaning. Could mention return details, but output schema likely covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no parameter descriptions (0% coverage). The description fully explains the sole parameter: 'unit_index: Audio unit index (-1 = all AUs).' This adds crucial meaning beyond the schema's title, making the tool easy to invoke correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Remove empty tracks' and the resource 'from an audio unit (or all AUs)'. It specifies 'removes tracks with no regions', making the purpose unambiguous and distinct from siblings like 'delete_track'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context: 'Useful cleanup after deleting regions or editing.' This implies when to use it, though explicit alternatives or when-not-to-use guidance is missing. The context is clear enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_compare_to_profileA

Compare your mix against a professional genre reference profile.

Tells you exactly where your mix deviates from genre standards:

  • LUFS: too loud/quiet for this genre?

  • Spectrum: which frequency bands are off?

  • Stereo width: appropriate for genre?

  • Dynamics: too compressed or too wild?

  • Spectral centroid: too dark or too bright?

Gives per-dimension deviation + specific recommendations.

filename: WAV file in exports dir, or absolute path. genre: One of: pop, rock, hip_hop, electronic, edm, metal, lo-fi, ambient, cinematic

Returns deviation analysis with severity-ranked suggestions.

Example: compare_to_profile("my_mix.wav", "lo-fi")

→ {lufs_deviation: +3.4, spectral_deviations: [...], suggestions: [...]}

ParametersJSON Schema
NameRequiredDescriptionDefault
genreYes
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes the return output (deviation analysis with suggestions) but does not explicitly state whether the tool is read-only or has side effects. The example gives a sense of output structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with a short intro, bullet points for analysis dimensions, parameter documentation, return clarification, and an example. No redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description provides a good overview of return structure. It covers the main use case, parameter ranges, and an example. However, it does not mention error conditions, file size limits, or prerequisites beyond file path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds significant value: it documents the 'filename' parameter as a WAV file in exports or absolute path, and lists all valid genres for the 'genre' parameter. This goes beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares a mix against a genre profile, listing specific dimensions (LUFS, spectrum, stereo width, dynamics, spectral centroid). It effectively distinguishes from siblings like 'compare_to_reference' which is for comparing to a specific reference track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: when you need to see deviations from genre standards. It implicitly distinguishes from alternative sibling tools but does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_compare_to_referenceA

A/B compare your mix against a reference track across all dimensions.

Shows exactly where your mix differs from a professional reference:

  • LUFS difference (loudness gap)

  • Spectral curve deviation per band

  • Stereo width comparison

  • Dynamic range comparison

  • Spectral centroid (brightness) comparison

This is how you learn how pros mix your genre. Drop in a reference track you admire and see exactly what's different.

filename: Your mix WAV (exports dir or absolute path). reference: Reference track WAV (exports dir or absolute path).

Returns per-dimension comparison + actionable deltas.

Example: compare_to_reference("my_mix.wav", "pro_reference.wav")

→ {lufs_delta: +2.3, spectral_deltas: [...], suggestions: [...]}

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
referenceYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It describes the output as 'per-dimension comparison + actionable deltas' and gives an example return structure. It implies a read-only comparison but does not explicitly state that no files are modified or mention constraints like sample rate compatibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a bold title, bullet points of dimensions, parameter explanations, and an example usage. Every sentence adds value without redundancy. It is concise yet informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mix comparison) and lack of annotations, the description covers the what, why, and how effectively. It includes an example return shape and explains both parameters. However, it could mention prerequisites like matching sample rates or lengths of the two files.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), but the description adds meaning: 'filename: Your mix WAV (exports dir or absolute path)' and 'reference: Reference track WAV (exports dir or absolute path).' This compensates well for the schema gap, though it could specify supported file formats beyond WAV.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'A/B compare your mix against a reference track across all dimensions.' It lists specific comparison dimensions (LUFS, spectral curve, stereo width, dynamic range, spectral centroid) and differentiates from siblings like 'compare_to_profile' by focusing on reference tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use: 'This is how you learn how pros mix your genre. Drop in a reference track you admire.' However, it does not explicitly mention when not to use or compare with the sibling 'compare_to_profile', which could be a potential alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_connect_modular_modulesC

Connect two modules in a Modular device (create a patch cable).

au_index: Audio unit index. effect_index: Effect index within the AU. source_module_index: Index of the source module. source_output_name: Name of the output connector (e.g. "Output", "Result"). target_module_index: Index of the target module. target_input_name: Name of the input connector (e.g. "Input", "X", "Y").

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
au_indexYes
effect_indexYes
target_input_nameYes
source_output_nameYes
source_module_indexYes
target_module_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only says 'Returns success or error.' It does not mention whether connections are overwritten, if multiple connections are allowed, or any side effects (e.g., cable routing conflicts). This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for the purpose, followed by a bullet list of parameters, and a note on return value. It is front-loaded and easy to scan, though the parameter list could be more structured (e.g., grouping source vs target).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of modular devices (multiple modules, output/input connectors), the description lacks essential context: how to obtain module indices, what connector names are valid, and whether `list_modular_modules` should be called first. The presence of an output schema does not compensate for this missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must compensate. It lists parameters with one-line descriptions (e.g., 'Audio unit index', 'Effect index within the AU'), which add minimal context beyond the parameter names. It does not explain how to find valid module indices or connector names, nor does it provide example values or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Connect two modules in a Modular device (create a patch cable).' This provides a specific verb ('connect') and resource ('modules in a Modular device'), and it distinguishes this tool from siblings like `add_modular_module` or `remove_modular_module`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives, prerequisites (e.g., modules must exist), or when not to use it (e.g., if a connection already exists). The description lacks any contextual usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_connect_sidechainA

Connect one audio unit's output as sidechain source to a Compressor/Gate on another unit.

source_unit_index: Audio unit whose output triggers the sidechain (e.g. drums). target_unit_index: Audio unit with the Compressor/Gate effect (e.g. bass). effect_index: Effect position on the target unit (must have a sideChain field).

The target effect must be Compressor, Gate, Vocoder, or any effect with Pointers.SideChain.

ParametersJSON Schema
NameRequiredDescriptionDefault
effect_indexYes
source_unit_indexYes
target_unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It states constraints on allowed effects but does not disclose side effects, reversibility, or state dependencies. Basic transparency but gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three precise sentences: purpose, parameter examples, and constraint. No redundant words; each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description doesn't need to cover return values. However, it lacks information about prerequisites (e.g., units must exist, effect must already be added). Adequate for a specialized tool but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It provides meaningful examples for each parameter (e.g., source unit: drums, target: bass) and explains the sideChain field requirement. This adds significant context beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear action verb ('Connect') and identifies the specific resource (sidechain from an audio unit to a Compressor/Gate on another). It distinguishes from siblings like 'mcp_opendaw_apply_sidechain' by specifying direct routing between units.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the target effect requirement (must have sideChain field) but lacks explicit when-to-use or when-not-to-use guidance relative to alternative sidechain tools. Usage is implied but not directly contrasted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_consolidate_clipA

Consolidate a clip's event collection — make it unique (not shared/mirrored).

If a clip shares its event collection with other clips (mirrored), this creates a new independent copy so edits don't affect other clips.

unit_index: AU index. track_index: Track index within the AU. clip_index: Clip index to consolidate.

Returns success, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that it creates a new independent copy when shared, which is good. However, it does not mention undo behavior, performance implications, or whether calling on a non-mirrored clip is safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a title sentence, a conditional explanation, a parameter list, and a return note. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and simple parameter structure, the description is mostly complete. It covers the core behavior and parameter roles, but could mention prerequisites (e.g., clip existence) and whether the tool has effect on non-mirrored clips.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It provides brief descriptions for each parameter (unit_index, track_index, clip_index), but they are minimal and assume domain knowledge (e.g., 'AU index' is not explained). More detail would help.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool consolidates a clip's event collection to make it unique, not shared/mirrored. It uses a specific verb (consolidate) and resource (clip's event collection). This distinguishes it from sibling tools like clone_clip.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (when clip shares events with others and you want independent edits). It provides clear context but does not explicitly mention when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_consolidate_noteA

Consolidate a repeated note (playCount > 1) into individual separate notes.

If a note has playCount > 1, it represents N repeats controlled by playCurve. This expands it into N independent notes, each with playCount=1, positioned according to the curve. The original note is deleted.

unit_index: AU index. track_index: Note track index. region_index: Note region index. note_index: Note index within the region.

Returns the number of notes created, or error if note has playCount=1.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_indexYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behaviors: the original note is deleted, the expansion creates N independent notes with playCount=1 positioned by the curve, and the return value. This is transparent, but could mention potential side effects on region or track state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear first sentence, explanatory paragraph, parameter list, and return value. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, prerequisites, parameters, and return value. It could mention if the region length is affected, but overall it is adequately complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are missing (0% coverage), but the tool description adds meaningful parameter explanations (e.g., 'unit_index: AU index') for all four parameters, greatly aiding the agent in correctly identifying hierarchical indices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool consolidates a repeated note (playCount > 1) into individual separate notes. It explains the concept, parameters, and return value, distinguishing it from siblings as a specific note expansion operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: when a note has playCount > 1. It also notes the error condition for playCount=1, indicating when not to use it. However, it doesn't mention alternative tools for similar operations like merge or split notes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_consolidate_regionA

Consolidate a region's event collection — make it unique (not shared/mirrored).

If a region shares its event collection with other regions (mirrored), this creates a new independent copy so edits don't affect other regions.

unit_index: AU index. track_index: Track index within the AU. region_index: Region index to consolidate.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool creates a new independent copy and returns success/error, but does not mention side effects, permissions, or reversibility. The description adds value beyond the schema but could be more comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise and well-structured: a one-line purpose, a condition explanation, a parameter list, and a return note. Every sentence earns its place, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 required integer params, output schema exists, no annotations), the description covers purpose, usage condition, parameters, and return type. It is sufficiently complete for an AI agent to select and invoke the tool correctly, though it could mention idempotency or errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It gives brief but clear explanations: unit_index is 'AU index', track_index is 'Track index within the AU', region_index is 'Region index to consolidate.' This adds meaning and clarifies hierarchy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Consolidate a region's event collection — make it unique (not shared/mirrored).' It clearly names the action and resource, distinguishing it from sibling tools like consolidate_clip and consolidate_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: when a region shares its event collection with others (mirrored), you can make a copy. It provides clear context but does not explicitly name alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_constrain_note_rangeA

Constrain notes to a pitch range — clamp or octave-wrap out-of-range notes.

After AI generation, transcription, or aggressive transposition, notes can land outside the playable range of an instrument. This tool brings them back inside.

Two modes:

  • "clamp" — notes below min_pitch are set to min_pitch, notes above max_pitch are set to max_pitch. Preserves the note but loses pitch information. Use when exact range matters (e.g. MIDI 0-127 safety).

  • "octave_wrap" — notes are shifted by octaves (±12 semitones) until they fall within [min_pitch, max_pitch]. Preserves pitch class and musical relationship. Use for instrument range constraints (violin, guitar, vocal, flute). If a note can't fit even after wrapping (range < 12 semitones), it's clamped.

Common instrument ranges (MIDI note numbers):

  • Guitar (standard tuning): E2(40) to E6(88)

  • Bass guitar: E1(28) to G4(67)

  • Violin: G3(55) to A7(105)

  • Cello: C2(36) to C6(84)

  • Flute: C4(60) to D7(98)

  • Vocal soprano: C4(60) to A5(81)

  • Vocal bass: E2(40) to E4(64)

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). min_pitch: Minimum allowed MIDI pitch (0-127, default 0 = no lower bound). max_pitch: Maximum allowed MIDI pitch (0-127, default 127 = no upper bound). mode: "clamp" (hard limit) or "octave_wrap" (shift by octaves to fit).

Returns per-track notes adjusted, clamped count, wrapped count.

Example:

Constrain to guitar range with octave wrapping

constrain_note_range(unit_index=0, track_index=2, min_pitch=40, max_pitch=88, mode="octave_wrap")

Safety clamp to MIDI range

constrain_note_range(mode="clamp", min_pitch=0, max_pitch=127)

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoclamp
max_pitchNo
min_pitchNo
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully explains both modes, including the fallback to clamp when range < 12 semitones. It also describes the return value. Missing details on whether modifications are in-place or return new data, but acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is relatively long but well-organized with clear sections (modes, instrument ranges, parameter list, example). Front-loaded with core action. Slightly verbose but justified by detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all relevant aspects: modes, edge cases, parameter explanations, example, and return value. No output schema provided, but description compensates. Complete for a 6-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds complete meaning for all 6 parameters, including defaults, ranges, and an example call. This compensates fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it constrains notes to a pitch range using 'clamp' or 'octave_wrap'. It distinguishes from sibling tools like transposition or note manipulation by focusing on range correction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies when to use: after AI generation, transcription, or aggressive transposition. Provides common instrument ranges and mode selection guidance (clamp for MIDI safety, octave_wrap for instrument constraints).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_convert_audioA

Convert an exported WAV file to MP3 or FLAC using system ffmpeg.

filename: Source WAV filename (without .wav extension, in the export dir). format: 'mp3' or 'flac' (default 'mp3'). bitrate: MP3 bitrate for CBR mode (default '320k'). Ignored for FLAC. quality: MP3 VBR quality 0-9 (0=best, 9=worst). Use -1 for CBR (default).

Requires system ffmpeg (not browser WASM). Falls back gracefully if missing. Returns path to the converted file and size info.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNomp3
bitrateNo320k
qualityNo
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions the tool used (ffmpeg), that it's not browser WASM, and returns path/size. It could clarify if the source is modified, but overall discloses key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear opening sentence and bullet-like parameter explanations. Every sentence adds value without redundancy. Very efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and the presence of an output schema, the description covers inputs, external dependency, and return info. Lacks error scenarios but is fairly complete for a conversion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning for each parameter: filename (without .wav, in export dir), format (mp3/flac), bitrate (CBR, default 320k, ignored for FLAC), quality (VBR 0-9, -1 for CBR). This compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Convert an exported WAV file to MP3 or FLAC using system ffmpeg', specifying the action, source, target formats, and tool. It distinguishes from siblings like export tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the filename must be in the export dir, requires system ffmpeg, and falls back gracefully. It does not explicitly list when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_copy_notes_to_trackA

Copy notes from one track/region to another track — MIDI layering and doubling.

Copies all notes from a source region to a destination track's first region. Optional transpose (semitones), time offset (beats), and velocity scaling.

Use cases:

  • Layer drums: copy drum track to second track with different instrument

  • Create harmony: copy melody +12 (octave) or +7 (fifth)

  • Call-and-response: copy with time_offset to create echo

  • Doubles: copy to same track position with slight transpose for thickening

source_unit_index: Source AU index. source_track_index: Source note track index. dest_track_index: Destination note track index. source_region_index: Source region (-1 = first region). dest_unit_index: Destination AU index (-1 = same as source). transpose: Semitone offset (-127 to 127, 0 = same pitch). time_offset: Beat offset for copied notes (0 = same position, 2 = two beats later). velocity_scale: Multiply velocity of copied notes (1.0 = same, 0.7 = quieter layer).

Returns count of notes copied.

Example:

Layer drums — copy track 0 to track 2

copy_notes_to_track(0, 0, 2)

Create octave harmony — copy melody +12

copy_notes_to_track(0, 3, 4, transpose=12, velocity_scale=0.7)

Echo effect — copy 2 beats later at half velocity

copy_notes_to_track(0, 0, 1, time_offset=2, velocity_scale=0.5)

ParametersJSON Schema
NameRequiredDescriptionDefault
transposeNo
time_offsetNo
velocity_scaleNo
dest_unit_indexNo
dest_track_indexYes
source_unit_indexYes
source_track_indexYes
source_region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral transparency. It states the tool copies notes from a source region to a destination track's first region, returns a count, and supports optional transformations. It does not mention whether the source is modified, permissions needed, or error handling, but the core behavior is clearly disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, bullet use cases, parameter definitions, return value, and examples. Every section adds value, and the most important information (purpose) is front-loaded. Despite length, it is efficient and not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (8 parameters, 3 required), the description covers all parameters, explains the return value, and provides multiple examples. It addresses potential use cases and parameter options, making it complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite the input schema having 0% description coverage, the tool's description provides a line for each parameter (e.g., 'source_unit_index: Source AU index'), adding meaningful explanation beyond the schema's type and defaults. This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Copy notes from one track/region to another track', using a specific verb and resource. It further distinguishes the tool by mentioning 'MIDI layering and doubling' and provides concrete use cases (e.g., layer drums, create harmony), differentiating it from sibling tools that copy regions or entire tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases (layer drums, harmony, call-and-response, doubles) and provides examples, giving clear context for when to use the tool. However, it does not explicitly state when NOT to use it or mention alternatives, though the use cases imply appropriate scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_copy_playfield_sampleA

Copy a Playfield (drum machine) sample to a new index slot.

Duplicates the sample with all its parameters (mute, solo, pitch, attack, release, sampleStart, sampleEnd, gate, exclude, polyphone) to a new slot.

unit_index: AU index containing the Playfield instrument. sample_index: Source sample slot index. target_index: Destination slot index.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
sample_indexYes
target_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states that the sample is duplicated with all listed parameters and returns success or error. However, it does not specify whether overwriting an existing target_index is allowed, whether the target slot must be empty, or any constraints like index bounds. This leaves gaps in understanding the tool's exact behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, starting with the core purpose, then listing duplicated parameters, then parameter explanations. Every sentence provides value without redundancy. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple copy operation with 3 integer parameters, the description covers the essential behavior, parameter meanings, and return type. It lacks details on error cases (e.g., out-of-range indices) but is otherwise complete given the tool's complexity. The presence of an output schema (not shown) reduces the need to describe return values in detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It clearly explains each parameter: unit_index (AU containing Playfield), sample_index (source slot), target_index (destination slot). This adds meaning beyond mere integer types, making it clear what each value represents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it copies a Playfield sample to a new index slot, duplicating all parameters. It uses a specific verb (copy) and resource (Playfield sample), distinguishing it from sibling tools like copy_notes_to_track or duplicate_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need to duplicate a sample with all its parameters to a new slot, but it does not explicitly state when to use this tool versus alternatives or provide any when-not guidance. Among many copy-related siblings, it relies on the name for differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_copy_region_fadesA

Copy fade in/out settings from one audio region to another.

Copies fadeIn, fadeOut, fadeInSlope, fadeOutSlope from the source region's Fading object to the destination region's Fading object.

src_unit/src_track/src_region: Source region coordinates. dst_unit/dst_track/dst_region: Destination region coordinates.

Returns the copied fade values.

ParametersJSON Schema
NameRequiredDescriptionDefault
dst_unitYes
src_unitYes
dst_trackYes
src_trackYes
dst_regionYes
src_regionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It states what is copied and that it returns copied values, but does not address whether it overwrites existing fades, is destructive, or handles errors (e.g., missing Fading object). It provides basic transparency but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one line for purpose, one for what is copied, one for parameter grouping, and one for return value. It is front-loaded with the key action and has no redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no schema descriptions, no annotations, and an output schema, the description covers parameters briefly and mentions return value. However, it lacks details about preconditions, behavior when source/destination are same or invalid, and whether fades are replaced or merged. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It groups source and destination parameters as 'coordinates' and names specific fields (src_unit, etc.), adding some meaning beyond the schema. However, it does not explain what unit, track, or region indices represent (e.g., integer IDs), leaving interpretation open.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool copies fade in/out settings between audio regions, listing the specific properties (fadeIn, fadeOut, fadeInSlope, fadeOutSlope). It distinguishes itself from sibling tools like set_audio_region_fade (which sets fades) and copy_region_to_track (which copies entire regions), making its purpose highly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for copying fade settings but does not explicitly state when to use this tool versus alternatives like set_audio_region_fade or copy_region_to_track. It lacks guidance on prerequisites (e.g., regions must exist) or when not to use it, though the purpose is clear enough for an agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_copy_region_to_trackA

Copy a region to a different track (or same track at new position).

Works with note, audio, and automation regions. The copy includes all content — notes, audio content, or automation events.

src_unit/src_track/src_region: Source region coordinates. dst_unit/dst_track: Destination track coordinates. position: New position in PPQN (omit to use source position).

Returns new region position and duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
dst_unitYes
positionNo
src_unitYes
dst_trackYes
src_trackYes
src_regionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It explains that the copy includes all content (notes, audio, automation events), mentions optional position, and states return values (new position and duration). It doesn't mention side effects or constraints, but for a copy operation, key behaviors are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lean and well-structured: purpose statement, supported types, parameter list, and return value. Every sentence adds value without redundancy. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and no annotations, the description adequately covers parameters and return. It doesn't address error handling or preconditions (e.g., region existence), but the output schema documents return values. It is sufficiently complete for a copy operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must compensate. It explains each parameter's role ('src_unit/src_track/src_region: Source region coordinates', 'position: New position in PPQN'), adding crucial semantics beyond names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Copy a region to a different track (or same track at new position),' specifying action (copy) and resource (region) with target (track). It distinguishes from siblings like 'move_region_to_track' and 'copy_notes_to_track' by implying a full region copy including all content types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions region types (note, audio, automation) implying generality but does not explicitly contrast with alternative tools like 'copy_notes_to_track'. No direct when-to-use or when-not-to-use guidance is provided, leaving inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_acid_arrangementA

Create an acid house arrangement — TB-303 squelch bassline.

Acid house is a subgenre of house music born in Chicago (1985-87) defined by the Roland TB-303 bass synthesizer with its distinctive squelchy, resonant filter sweeps. Key characteristics:

  • TB-303 bassline: monophonic, sequenced 16th notes with filter cutoff sweeps (open↔closed), accent and glide (slide) between notes. The signature "squelch" sound.

  • 909 drum machine: 4-on-floor kick, open hat on offbeats, clap on 2&4, ride cymbal

  • 125 BPM, 4/4 time

  • Minimal, hypnotic, repetitive structure with gradual evolution

  • Often in minor key with chromatic bassline movement

Creates 3 tracks:

  1. Drums (track_index): 909-style — kick on every beat, clap on 2&4, open hat on offbeats, closed hat on 16ths, ride on quarter notes

  2. Bass (track_index+1): TB-303-style 16th note pattern with chromatic movement, octave jumps, and accent patterns. Notes have varied velocity to simulate filter envelope.

  3. Lead (track_index+2): Sparse, hypnotic stab on beat 1 of every 4 bars, minor key pad-like sustained note

Default key: A minor (classic acid key).

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoA
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior. It details the three tracks created and their patterns, but lacks information on side effects, prerequisites (e.g., track index conflicts), or whether it overwrites existing content. Adequate but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear opening and breakdown, but includes lengthy historical background on acid house that, while informative, is not essential for tool usage. Could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While output schema exists, the description lacks parameter guidance and does not explain how inputs affect the generated arrangement. For a creation tool with 7 undocumented parameters, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; the description does not explain any of the 7 parameters (bpm, bars, key_root, velocity, start_beat, unit_index, track_index). It only mentions default key A minor. This fails to add meaning beyond the schema, which is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an acid house arrangement, specifying the TB-303 bassline and 909 drums. It distinguishes from sibling genre arrangement tools by providing genre-specific characteristics and track details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for creating acid house arrangements with specific characteristics. It doesn't explicitly state when not to use it or compare to alternatives, but the genre focus makes selection natural among many genre-specific siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_additive_rhythmA

Create an additive rhythm — unequal groupings within a bar.

The defining technique of Messiaen, Stravinsky, Bartok, Ligeti, and modern math rock / prog metal. Instead of dividing a bar into equal parts (eighth-eighth-eighth-eighth), the bar is divided into unequal groups (3+2+2 = 7 eighths, 2+3+2 = shifting accent, 5+3 = 8 eighths).

The resulting accent pattern creates a sense of irregular meter within a nominal time signature — the pulse "turns" inside the bar.

Examples: create_additive_rhythm("3+2+2", "eighth") -> 7 eighth notes grouped as 3-2-2, accents on notes 1, 4, 6 (Bartok "Bulgarian Rhythm", Math rock 7/8 feel) create_additive_rhythm("2+3+2", "eighth", repeats=4) -> shifting accent pattern, 4 bars create_additive_rhythm("5+3", "eighth", pitch="scale_up") -> 8 eighths in 5+3 grouping, ascending scale create_additive_rhythm("3+2+2", "sixteenth", repeats=2, decay=0.1) -> 7 sixteenths per bar, velocity decay within groups

Args: grouping: Plus-separated group sizes (e.g. "3+2+2", "5+3", "2+1+2"). Each number = count of notes in that group. Sum = total notes per bar. 2-6 groups, 2-16 notes total. unit: Note value — "eighth", "quarter", "sixteenth", "thirty_second". repeats: Number of bars (1-16). pitch: Pitch mode — "root" (same note), "scale_up" (ascending scale), "scale_down" (descending), "alternating" (up/down per note), "octave_bounce" (root->octave->root). scale: Scale for pitch modes (minor, major, dorian, phrygian, etc.). root: Root note (C, C#, D, ...). octave: Base octave (1-6). accent_mode: Where to place accents — "group_start" (first note of each group gets accent), "group_end" (last note), "every_note" (all same velocity). accent_velocity: Velocity for accented notes (0-1). normal_velocity: Velocity for non-accented notes (0-1). decay: Velocity decay within each group (0-0.3). Each subsequent note in a group gets slightly softer. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, grouping structure, accent pattern, and bar layout.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
unitNoeighth
decayNo
pitchNoroot
scaleNominor
octaveNo
repeatsNo
groupingYes
start_beatNo
unit_indexNo
accent_modeNogroup_start
track_indexNo
accent_velocityNo
normal_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral transparency burden. It explains the output (notes, grouping, accents, bar layout) and provides examples showing the resulting accent pattern. However, it does not disclose whether the operation is additive/non-destructive or if it modifies existing notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a conceptual overview, examples, and parameter list. It front-loads the key idea. While a bit lengthy, every section earns its place; minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (14 params) and the presence of an output schema, the description adequately explains what the tool does and returns. It could mention how it interacts with the project (e.g., adds to a specific track) but overall covers the essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the tool description's Arg section provides complete and detailed explanations for all 14 parameters, including defaults, valid ranges, and behavior. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an additive rhythm (unequal groupings within a bar) and distinguishes it from other rhythm tools by defining the specific musical technique. The name also reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool via examples referencing specific composers and genres (Messiaen, Stravinsky, math rock) but does not explicitly compare with sibling tools like create_euclidean_rhythm or create_polyrhythm. No direct when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_afrobeat_arrangementA

Create a full afrobeat arrangement — polyrhythmic drums + bass + horns + guitar across 4 tracks.

Fela Kuti-style afrobeat with all elements locked in polyrhythmic interlock:

  • Track 0: Drums — layered polyrhythm: kick pattern, shaker pattern, clave-like accents. The foundation is 12/8 feel in 4/4 time — triplets over straight beats, the African polyrhythmic heartbeat.

  • Track 1: Bass — repetitive ostinato bassline, rooted in the key, driving and hypnotic. Afrobeat bass doesn't rest — it's the engine alongside the drums, locking with the kick.

  • Track 2: Horns — brass section stabs and sustained chords. Call-and-response between horn hits and space. Minor key, soulful.

  • Track 3: Guitar — rhythmic chord stabs on the off-beats, the "chanka" pattern that defines the groove. Two-note voicings, percussive and tight.

At 120 BPM (default), this creates the classic afrobeat feel — not too fast, not too slow, with room for polyrhythmic layering. The 4-track arrangement (first non-electronic genre) is the key difference: horns and guitar add organic texture that electronic arrangements don't have.

bpm: Tempo (100-130, default 120 = classic afrobeat). bars: Arrangement length (8-32, default 8). Afrobeat needs long forms. root: Root note (F is the classic afrobeat key — Fela's preference). octave: MIDI octave for bass (2 = C2=36, audible low end). unit_index: AU index with note tracks. drum_track / bass_track / horn_track / guitar_track: Track indices.

Returns notes created per track and total.

Example: create_afrobeat_arrangement(bpm=120, root="F", bars=8) create_afrobeat_arrangement(bpm=110, root="Ab", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
horn_trackNo
start_beatNo
unit_indexNo
guitar_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It details the polyrhythmic interlock and track roles, but does not disclose whether existing notes on those tracks are overwritten, or if track creation is handled. Some behavioral aspects are implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: starts with purpose, then details each track, followed by parameter explanations and examples. Every sentence adds value, and the length is appropriate for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and output schema existence, the description covers musical intent, track roles, parameter defaults, and example calls. It lacks details on handling missing tracks or the velocity/start_beat parameters, but is largely complete for the genre-specific arrangement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description compensates. It explains 9 of 11 parameters with musical context, defaults, and examples. However, 'velocity' and 'start_beat' are not mentioned in the parameter descriptions, leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full afrobeat arrangement' with specific verb and resource, and distinguishes it from sibling tools like create_acid_arrangement or create_ambient_arrangement by specifying the genre and track layout.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool for Fela Kuti-style afrobeat and contrasts with electronic arrangements. It provides defaults and example use cases, but does not explicitly state when not to use it or mention alternative tools for other genres.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ambient_arrangementA

Create an ambient arrangement — 70 BPM atmospheric soundscape.

Ambient music (Brian Eno, Stars of the Lid, Aphex Twin Selected Ambient Works) focuses on atmosphere, texture, and sustained sound over rhythm and melody. Key characteristics:

  • 60-80 BPM (or no clear pulse), 4/4 time

  • Long sustained pad notes with slow evolution

  • Sparse, minimal percussion (or none)

  • Drifting melodic fragments, no clear phrase structure

  • Reverb-drenched, wide stereo, cinematic

  • Modal harmony (sustained chords, slow changes)

Creates 4 tracks:

  1. Pad (track_index): Long sustained chord notes (8 bars each), mode-based (major/minor/dorian/lydian), very slow harmonic rhythm. Root, fifth, octave — open voicings.

  2. Melody (track_index+1): Sparse, drifting melodic fragments — long notes (2-4 bars), wide intervals, lots of space. Starts after 8 bars.

  3. Drums (track_index+2): Extremely sparse — single kick on bar 1 of every 8 bars, occasional shaker. Almost subliminal pulse.

  4. Bass (track_index+3): Sustained sub-bass drone, root note only, changes with pad harmony. Very low octave.

Default key: C major (most common ambient key). Default 32 bars for proper ambient evolution length.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoC
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses the arrangement's structural details: track roles, default BPM/keys/bars, and harmonic approach. It does not cover side effects like project state modifications or prerequisites, but the creation behavior is well-documented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but verbose, including a mini-tutorial on ambient music characteristics. While this adds context, it could be more concise for quick agent parsing. The key functionality is front-loaded, but excess text may dilute efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and an output schema, the description covers the arrangement's core behavior and defaults. It lacks explanation for three parameters but otherwise provides a solid mental model. The output schema exists, so return value explanation is unnecessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains several parameters (track_index, bars, key_root, bpm) and their defaults. However, velocity, start_beat, and unit_index are not addressed, leaving gaps. The explanation of track_index plus offsets is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an ambient arrangement and enumerates the 4 tracks it generates (Pad, Melody, Drums, Bass). It provides specific genre characteristics and default settings, making the purpose immediately clear and distinct from sibling arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for ambient soundscapes but does not explicitly state when to use this tool over other arrangement creation tools. No direct comparisons or exclusions are provided, though the genre-specific naming helps the agent infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_appoggiaturaA

Create an appoggiatura — leaning grace note that resolves to the main note.

The appoggiatura is the fourth and final essential baroque ornament (trill, mordent, turn, appoggiatura). Unlike a mordent (quick flick), the appoggiatura is expressive: it plays a neighbor note FIRST (usually longer), then resolves into the main note. The approach note creates harmonic tension that the main note releases. Think Bach cello suites, Mozart operas, Chopin nocturnes.

An appoggiatura above approaches from higher (e.g. D → C). An appoggiatura below approaches from lower (e.g. B → C). The approach note typically takes 2/3 of the total duration, leaving 1/3 for the resolution — but this is adjustable.

main_pitch: The resolution note (default 60 = C4). This is where tension releases. approach_pitch: The grace note played first (default 62 = D4). Can be above or below main. duration_beats: Total length of both notes combined (0.5-8, default 1.0 = quarter). appoggiatura_ratio: Fraction of duration for the approach note (0.5-0.9, default 0.67 = 2/3). Higher = more tension (longer grace, shorter resolution). 0.5 = equal split. velocity: Base velocity 0-1 (default 0.85). Approach note is slightly accented. unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the appoggiatura begins.

Returns notes created, pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
velocityNo
main_pitchNo
start_beatNo
unit_indexNo
track_indexNo
approach_pitchNo
duration_beatsNo
appoggiatura_ratioNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully carries the burden. It explains the sequential nature (approach note first, then resolution), the ratio affecting tension, and the effect of approach direction. It also mentions return value. Lacks details on permissions or side effects, but the behavior is well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured: a concise one-line summary, followed by contextual paragraphs, then individual parameter descriptions. Front-loaded with key information. Could be slightly more concise, but appropriate for a complex ornament.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, behavior, parameters, and output. An output schema exists, so the description doesn't need to detail return values beyond mentioning 'notes created, pitches used'. For a music notation tool with moderate complexity, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides detailed explanations for all eight parameters: default values, ranges, musical meaning (e.g., 'approach_pitch: The grace note played first (default 62 = D4). Can be above or below main.'). This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an appoggiatura, defines it as a leaning grace note resolving to main note, and explicitly differentiates it from mordent (quick flick) and other baroque ornaments like trill and turn. It uses specific verbs and musical context, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use (expressive ornament) and contrasts with mordent ('unlike a mordent'). It gives examples of above/below approach and adjustable ratio, but does not explicitly state when not to use or name alternative tools beyond ornaments. Still clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_arabic_percussionA

Create an Arabic/Middle Eastern percussion ensemble — darbuka, daf, and zills.

Middle Eastern percussion is built on the interplay between the darbuka (tabla, goblet drum) playing the core rhythm with dum (low) and tek/ka (high) strokes, the daf (frame drum) providing sustained resonance and rolls, and zills (sagat, finger cymbals) adding shimmering accents. The rhythms are cyclical with distinctive asymmetry — maqsum has a characteristic gap between dum strokes that creates tension.

The stroke vocabulary: DUM — Low, resonant center stroke on darbuka (bass register) TEK — High, ringing rim stroke (right hand, accented) KA — High, snapping rim stroke (left hand, lighter) SLAP — Sharp, accented stroke (mid register)

rhythms: "maqsum" — The most common Arabic rhythm: D-T- -T-D- -T-. 4/4, 8 beats. Dum on 1 and 4.5, tek on 2, 3, 5.5, 7. The "mother of all Arabic rhythms". Used in almost all Arabic pop, classical, and folk music. "baladi" — Urban Egyptian version of maqsum: D-D- -T-D- -T-. Dum on 1 and 1.5 (double dum), tek on 3, 5.5, 7. Heavier, more driving. The "baladi groove" of Cairo. "saidi" — Upper Egyptian rhythm: D-T- -T-D-D- -T-. 4/4. Dum on 1, 4.5, and 5 (double dum). Tek on 2, 3, 6.5, 7. From the Said region. Used in Saidi dance and music. "ayoub" — 2/4 cyclical rhythm: D- -T- -D-D-. 4 beats. Dum on 1, 3, 3.5. Tek on 2. Used in Sufi trance, zar ceremonies, and religious processions. "malfouf" — 2/4 fast rhythm: D- -T- -T-. 3 beats. Dum on 1, tek on 2, 2.5. Used in fast entrances, processions, and folk dances. "Running" feel. "chiftetelli" — 8/4 slow rhythm: D- -T- -T- -D- -T-. 8 beats. Dum on 1 and 5.5, tek on 2.5, 3.5, 7.5. Used in Turkish and Greek music, belly dance slow sections.

Args: bars: Pattern length in bars (2-16, even). rhythm: Rhythm name (maqsum, baladi, saidi, ayoub, malfouf, chiftetelli). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. darbuka_pitch: Darbuka MIDI pitch (36 = C1). daf_pitch: Daf (frame drum) MIDI pitch (42 = F#1). zills_pitch: Zills (finger cymbals) MIDI pitch (50 = D2).

Returns notes created, instrument breakdown, stroke types, and rhythm info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rhythmNomaqsum
velocityNo
daf_pitchNo
start_beatNo
unit_indexNo
track_indexNo
zills_pitchNo
darbuka_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns notes, an instrument breakdown, stroke types, and rhythm info. It also explains the instruments and stroke mappings, providing moderate transparency. However, it does not explicitly state whether notes are added to an existing track or if there are side effects, though the parameters (unit_index, track_index, start_beat) imply placement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose sentence, but it is lengthy due to extensive educational material on Arabic percussion. While well-structured (purpose, background, stroke types, rhythms, args), it could be more concise without losing essential information. The educational content is valuable but adds verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's cultural complexity and 9 parameters, the description is highly complete. It covers all parameters, explains stroke vocabulary and rhythms in detail, and mentions return values. The output schema exists (though not shown), so the description's lack of return format detail is acceptable. No gaps remain for the intended use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes an 'Args' section that lists and explains all 9 parameters with brief, meaningful descriptions (e.g., 'bars: Pattern length in bars (2-16, even).'). This adds substantial meaning beyond the bare schema, compensating fully for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear, specific verb and resource: 'Create an Arabic/Middle Eastern percussion ensemble.' This immediately distinguishes it from sibling tools like create_djembe_ensemble (African) or create_taiko_ensemble (Japanese), as well as generic create_drum_pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, but the rich educational content about Arabic rhythms, instruments, and stroke vocabulary provides clear context for when this tool is appropriate. It implicitly guides the agent toward Middle Eastern music creation without specifying exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_arpeggiated_progressionA

Create an arpeggiated chord progression — synthwave/trance arp engine.

Takes a chord progression string (same format as create_chord_pads: "Am-F-C-G") and generates arpeggiated notes cycling through chord tones. This is the synthwave arpeggiated bass, the trance supersaw arp, the house plucked chord stab — all from a simple progression string.

Unlike create_arpeggio (which takes a single chord), this cycles through a full progression, changing chord tones every bars_per_chord bars.

progression: Hyphen-separated chords (same as create_chord_pads). "Am-F-C-G" = i-VI-III-VII in A minor. "C-G-Am-F" = I-V-vi-IV in C major (pop).

pattern: Arpeggio pattern: "up" — root, third, fifth, root(oct) — classic synthwave "down" — oct root, fifth, third, root — descending "updown" — root, third, fifth, oct, fifth, third — full cycle "random" — random chord tones — dreamy, unpredictable "bass" — root only, 8th notes — driving bass arp (synthwave bass)

bars_per_chord: Bars per chord (default 4). octave: MIDI octave (3 = bass arp, 4 = mid arp, 5 = lead arp). velocity: Note velocity (0-1). step_duration: Note length in beats (0.25 = 16th, 0.5 = 8th, 0.125 = 32nd). track_index: Track for arp notes (typically melody track = 3).

Returns chords arpeggiated, total notes, pattern used.

Example:

Synthwave bass arp (16th notes, octave 2)

create_arpeggiated_progression("Am-F-C-G", pattern="bass", octave=2, step_duration=0.25, track_index=1)

Trance supersaw arp (16th up, octave 4)

create_arpeggiated_progression("Fm-Db-Ab-Eb", pattern="up", octave=4, step_duration=0.25, track_index=3)

Pop arp (8th updown, octave 5)

create_arpeggiated_progression("C-G-Am-F", pattern="updown", octave=5, step_duration=0.5, track_index=3)

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
patternNoup
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
step_durationNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Explains arpeggio generation, pattern cycling, and return values (chords, total notes, pattern). Does not mention side effects or limitations, but behavior is well-described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose statement, parameter descriptions, and examples. Reasonably concise for the level of detail, though some genre names repeat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and output schema exists, the description covers essential aspects: parameter explanations, examples, sibling differentiation. Return values are mentioned. Lacks details on start_beat and unit_index.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. Describes key parameters (progression, pattern, octave, velocity, step_duration, track_index) with examples and allowed values. However, start_beat and unit_index are omitted, leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an arpeggiated chord progression and distinguishes it from create_arpeggio (single chord vs. full progression). Specific verb 'create' and resource 'arpeggiated chord progression' are used.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly contrasts with create_arpeggio and gives genre-specific examples (synthwave, trance, house, pop). Provides clear context for when to use, though lacks explicit 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_arpeggioA

Create an arpeggio from a chord name — one call instead of 8-32 create_note calls.

chord: Chord name in format RootType, e.g. "Cmin7", "F#maj", "Abmin7", "Ddim". Root: C, C#, D, D#, E, F, F#, G, G#, A, A#, B (or flats Db, Eb, Gb, Ab, Bb). Type: maj, min, dom7, maj7, min7, sus2, sus4, add9, dim, aug. pattern: Arpeggio direction/pattern:

  • "up" — bottom to top, repeat

  • "down" — top to bottom, repeat

  • "updown" — up then down (includes top and bottom twice)

  • "downup" — down then up

  • "random" — random chord tones

  • "chord" — play full chord on each step (block chords) rate: Note rate: "32" (32nd), "16" (16th), "8" (8th), "4" (quarter), "16t" (16th triplet). octave: MIDI octave for the chord root (4 = C4=60). steps: Number of arpeggio steps (default 16 = one bar of 16th notes). unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the arpeggio starts (0 = bar 1). velocity: Note velocity 0-1 (default 0.65 for arpeggios).

Returns the total notes created and pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateNo16
chordYes
stepsNo
octaveNo
patternNoup
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description shoulders the full burden. It comprehensively describes the chord format, pattern options, rate semantics, defaults, and return value ('Returns the total notes created and pitches used'). All behavioral aspects are disclosed without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but structured: a one-line headline followed by a clean parameter list. It is efficient but could potentially be more concise by grouping related parameters (e.g., unit_index and track_index). Overall, it is well-organized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 9 parameters and the existence of an output schema, the description covers all inputs, defaults, return value, and provides examples. It places the arpeggio in context (track, unit, start beat) and explains the pattern behavior. No gaps are evident for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must fully document each parameter. It does so: chord format with examples, pattern list with explanations, rate values, octave, steps, velocity, start_beat, unit_index, and track_index all explicitly described. This adds substantial meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb-resource pair ('Create an arpeggio from a chord name') and immediately provides a comparative efficiency hook ('one call instead of 8-32 create_note calls'), clearly distinguishing this tool from its sibling 'mcp_opendaw_create_note'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states the tool's purpose for arpeggio creation and contrasts it with create_note, giving strong contextual usage guidance. However, it does not explicitly list when not to use this tool or mention alternative arpeggio methods, though for a specialized tool this is less critical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_arrangement_variationA

Create a musically varied section — not a repeat, a real variation.

Unlike create_genre_sections (which repeats the same loop at different velocities), this tool applies actual musical transformations to each track independently:

  • Drums: density control (0.3 = sparse, 1.0 = full, 1.5 = busy with ghosts)

  • Bass: octave shift (bass_octave_shift = +1/-1/-2)

  • Melody: inversion, transposition, retrograde, or fragment

  • Track inclusion: skip drums/bass/harmony/melody independently

This lets you build a song where each section has real musical variation, not just energy changes. The drop has full drums, the breakdown has inverted melody + no bass, the bridge has sparse drums + octave-up bass.

genre: Any of the 14 arrangement genres (dnb/house/trap/techno/dubstep/ synthwave/trance/disco/afrobeat/rock/jazz/pop/funk/reggae). section_name: Label for this section (e.g. "verse2", "bridge", "drop2"). bpm: Override tempo (None = genre default). root: Override key (None = genre default). bars: Section length in bars (4-32, default 8). start_beat: Where this section starts in the timeline. velocity: Base velocity 0-1. drum_density: 0.3 = sparse (half notes removed), 1.0 = normal, 1.5 = busy (extra ghost notes between hits). bass_octave_shift: 0 = normal, +1 = octave up, -1 = octave down, -2 = sub. melody_transform: "none", "invert", "transpose:5", "transpose:-7", "reverse", "fragment", "octave_up", "octave_down". include_drums/include_bass/include_harmony/include_melody: Set False to skip that track (e.g. breakdown = no drums, no bass).

Returns notes per track and transformations applied.

Example:

Breakdown section: sparse drums, no bass, inverted melody

create_arrangement_variation("dnb", section_name="breakdown", drum_density=0.3, include_bass=False, melody_transform="invert", velocity=0.6)

Bridge: octave-up bass, retrograde melody

create_arrangement_variation("house", section_name="bridge", bass_octave_shift=1, melody_transform="reverse", start_beat=64, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNo
genreYes
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
drum_densityNo
include_bassNo
melody_trackNo
section_nameNovariation
harmony_trackNo
include_drumsNo
include_melodyNo
include_harmonyNo
melody_transformNonone
bass_octave_shiftNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses behavioral traits: applies independent transformations to drums, bass, melody, and harmony; explains the effect of parameters like drum_density, bass_octave_shift, and melody_transform; and states that it returns 'notes per track and transformations applied.' This provides good transparency for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but well-structured. It starts with a clear purpose statement, then breaks down transformations per track, lists parameters with explanations, and provides two usage examples. Every sentence adds value, and the examples help illustrate usage. Could be slightly more concise, but it earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (19 parameters, 1 required) and the existence of an output schema, the description adequately covers the main parameters, explains transformations, and provides examples. It mentions return values. It doesn't cover all edge cases, but for a creative music tool, it is complete enough to guide an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates exceptionally. It explains each parameter with concrete examples: drum_density ('0.3 = sparse, 1.0 = normal, 1.5 = busy'), bass_octave_shift ('0 = normal, +1 = octave up'), melody_transform lists allowed values, and include_* booleans. This adds substantial meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description immediately states the tool creates 'a musically varied section — not a repeat, a real variation.' It explicitly contrasts with sibling tool create_genre_sections (which repeats loops at different velocities), clearly distinguishing the tool's unique capability. The verb 'create' and resource 'arrangement variation' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: 'to build a song where each section has real musical variation, not just energy changes.' It differentiates from create_genre_sections and provides concrete examples (breakdown, bridge). It does not explicitly state when not to use it, but the contrast with the sibling and the detailed parameter guidance imply appropriate contexts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_audio_busA

Create a new audio bus (aux bus) with its own audio unit and track.

Follows the upstream AudioBusFactory.createAudioBus pattern: creates AudioUnitBox (Aux) + AudioBusBox + TrackBox, wires them together. Uses separate editing.modify() blocks — pointer refer() inside box constructor fails due to deferred pointer update resolution.

name: Bus label.

Returns the new bus index.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must fully convey behavioral traits. It discloses that the tool creates multiple internal boxes (AudioUnitBox, AudioBusBox, TrackBox) and wires them, and notes a specific failure scenario with pointer refer() and deferred pointer update resolution. This adds valuable context about side effects and constraints beyond a simple 'create' call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description starts with a clear summary sentence, which is good. However, it then includes a paragraph of internal implementation details that may not be essential for an agent's decision to invoke the tool. This adds length without significantly aiding selection or invocation, making it less concise than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values are not needed. The description covers the internal pattern and a known failure case, providing implementation-level completeness. However, it lacks information about idempotency, maximum bus limits, or if the operation can be undone. For a creation tool, some additional context about side effects would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must add meaning. It states 'name: Bus label' which clarifies the purpose of the 'name' parameter beyond the schema's title. However, no additional constraints, format, or usage tips are provided; the explanation is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new audio bus (aux bus) with its own audio unit and track.' It uses a specific verb 'create' and a clear resource 'audio bus', distinguishing it from sibling creation tools like create_audio_track or create_send.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description focuses on internal implementation details (e.g., AudioBusFactory pattern, pointer refer() failure) rather than usage context or conditions. It does not explain when creating an audio bus is appropriate or what prerequisites are needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_audio_clipA

Create an audio clip in the session view (clip launcher).

Audio clips are the session-view counterpart to audio regions. They appear in the clip launcher and can be triggered independently.

sample_id: The ID returned by mcp_opendaw_load_audio. unit_index: Audio unit index (default 0). clip_index: Slot index in the clip launcher (0, 1, 2, ...). track_index: Track index within the audio unit (default 0). bpm: Source BPM of the sample (for warp marker calculation).

Returns clip UUID and index.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
sample_idYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states it creates an audio clip and returns UUID and index, but does not mention side effects (e.g., overwriting existing clips), required prerequisites (e.g., sample already loaded), or whether this is destructive. The description is minimal on behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a clear opening sentence stating the purpose, a brief explanation of what audio clips are, and then a list of parameter definitions. Every sentence adds value without unnecessary words. It is front-loaded with the most important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has five required parameters and an output schema, the description adequately explains the parameters and confirms return values. It could mention that the clip is added to the session view and not the arrangement view, but overall it provides sufficient context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides meaning for all five parameters beyond the schema's type and title. For example, it explains sample_id as 'The ID returned by mcp_opendaw_load_audio', clip_index as 'Slot index in the clip launcher (0, 1, 2, ...)', and bpm as 'Source BPM of the sample (for warp marker calculation)'. This adds useful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create an audio clip' and specifies the resource 'in the session view (clip launcher)'. It distinguishes audio clips from audio regions, and among siblings like create_note_clip, it is the only one that creates session-view audio clips. This provides a clear and specific purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that audio clips are session-view counterparts and can be triggered independently, but it does not explicitly state when to use this tool versus alternatives like create_note_clip or create_audio_track. It provides context but lacks explicit when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_audio_trackB

Create a new audio track on the primary audio unit.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose side effects, but it only states the action. No mention of what happens to existing tracks, whether it is destructive, or any required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 11 words, no redundancy. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no parameters, the description fails to explain the tool's context (e.g., what 'primary audio unit' is, what the output contains). Given an output schema exists, the return value explanation is not required, but other context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (empty schema). The description adds no value beyond the schema, but the baseline for zero-param tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a new audio track', distinguishing it from siblings like create_instrument_track. However, the phrase 'on the primary audio unit' is ambiguous without further context, slightly reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like create_instrument_track or create_audio_bus. No preconditions or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_automation_eventA

Create a single automation event at a specific position on a value track.

Adds a point to the automation curve with the given interpolation type. If an event already exists at the same position, its value is updated.

unit_index: AU index. track_index: Value (automation) track index. position_beats: Position in beats (float). value: Normalized value 0.0-1.0. interpolation: "none" (step), "linear" (ramp), or "curve" (custom slope). curve_slope: Slope for curve interpolation (0.0-1.0, 0.5 = linear). Only used if interpolation="curve".

Returns the created/updated event info, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
curve_slopeNo
track_indexYes
interpolationNolinear
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It discloses upsert behavior, interpolation types, and parameter constraints. It mentions return info/error. However, it omits side effects, undo capability, or permission needs, which would enhance transparency. Nonetheless, it covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact (6 sentences) with clear front-loading of purpose, then behavior, then parameter explanations. Every sentence adds value; no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 params, output schema present), the description adequately explains behavior and parameters. It mentions return value. It could be more complete by including error scenarios or examples, but it is sufficient for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must document parameters. It explains all 6 parameters: unit_index, track_index, position_beats, value, interpolation (with options), and curve_slope (when used). Defaults and valid values are given, fully compensating for absent schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Create a single automation event at a specific position on a value track.' It specifies the resource (automation event) and its location (value track, position). This distinguishes it from siblings like 'add_automation' (likely bulk) and 'update_automation_event' (update only), as it covers both create and update (upsert behavior).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for single-point automation manipulation and mentions upsert, but does not explicitly compare with siblings like 'add_automation' or 'update_automation_event'. No guidance on when to use this tool over alternatives or prerequisites for unit_index/track_index.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_balkan_meterA

Create a Balkan additive meter pattern — asymmetric time signatures with unequal beat groupings.

Balkan music uses "additive" meters: time signatures like 7/8, 9/8, 11/8, 13/8 where the measure is divided into unequal groups of 8th notes. Unlike Western "odd time" (which counts uniformly), Balkan music groups beats into patterns like 2+2+3 (7/8), 2+2+2+3 (9/8), 2+2+3+2+2 (11/8). Each group has a distinct accent pattern, creating the characteristic "limping" feel.

The tapan (large frame drum, similar to daire/def) plays the bass pattern: a low hit at the start of each group, high hits on the internal beats. The accent structure is the defining feature — the groups are not equal, so the listener perceives a lopsided, driving rhythm.

meters: "7_8" — 7/8: groups 2+2+3. The most common Balkan meter. Found in Macedonian, Bulgarian, Greek folk music. Accents on 1, 3, 5. "9_8" — 9/8: groups 2+2+2+3. Used in Bulgarian horo, Greek kalamatianos. Accents on 1, 3, 5, 7. Longer "limp" at the end. "11_16" — 11/16: groups 2+2+3+2+2. Bulgarian krivo horo. Very asymmetric. "13_8" — 13/8: groups 2+2+3+2+2+2. Bulgarian elenino horo. Longest common additive meter. "7_8_sand" — 7/8: groups 3+2+2 (reversed). Sandansko oro, Macedonian. Different accent placement, "backwards" feel. "9_8_ska" — 9/8: groups 2+3+2+2. Deviationska variant.

variations: "classic" — Traditional tapan pattern. Kick on group starts, snare on internal beats, hi-hat on all 8ths. "modern" — Modern Balkan fusion (Shantel, Balkan Beat Box). Kick patterns more syncopated, added ghost snares. "wedding" — Wedding band style. Denser hi-hat, more snare fills, tapan rolls at cycle end.

Args: meter: Meter name (7_8, 9_8, 11_16, 13_8, 7_8_sand, 9_8_ska). cycles: Number of measure cycles (1-32). variation: Pattern variation (classic, modern, wedding). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. kick_pitch: Kick/tapan low MIDI pitch (36 = C1). snare_pitch: Snare/tapan high MIDI pitch (40 = E1). hh_pitch: Hi-hat MIDI pitch (42 = F#1). tapan_pitch: Tapan roll MIDI pitch (45 = A1).

Returns notes created, meter grouping, accent positions, and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
meterNo7_8
cyclesNo
hh_pitchNo
velocityNo
variationNoclassic
kick_pitchNo
start_beatNo
unit_indexNo
snare_pitchNo
tapan_pitchNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the output (notes, grouping, accents) and the tapan pattern, but does not disclose side effects (e.g., whether existing notes are modified, or the interaction with track/unit indices). Constraints like velocity range (0-1) are mentioned, but error conditions are not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: concept overview, meter listing, variations, then parameter list. Front-loaded with purpose. Slightly verbose with extensive meter background, but appropriate for a specialized creative tool. No wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, output schema exists), the description is fairly complete: it explains the theory, all parameters, and return values. Missing details about DAW state interaction (e.g., whether tracks/units must pre-exist) and validation assumptions, but overall adequate for an informed agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. Each parameter has a brief description (e.g., meter names, cycles range, pitch roles), adding meaning beyond type/defaults. Some descriptions (like pitches) could be more detailed, but overall the tool's parameters are adequately explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates Balkan additive meter patterns, a specific verb+resource. It distinguishes itself from sibling rhythm tools by focusing on asymmetric time signatures with detailed meter and variation options.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the description of Balkan meters, but no explicit guidance on when to use this tool versus alternatives like create_cross_rhythm or create_euclidean_rhythm. No when-not-to-use or prerequisite conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_bariolageA

Create a bariolage — rapid alternation between a fixed pedal pitch and moving notes.

Bariolage is a Baroque string technique (Bach, Vivaldi, Handel) where a fixed note (typically an open string) rapidly alternates with moving notes that ascend, descend, or follow a melodic pattern. This creates a layered, cross-register texture — two streams of sound perceived simultaneously.

Unlike arpeggiator (cycles chord tones) or montuno (syncopated chord stabs), bariolage creates a two-voice illusion from a single voice: the pedal pitch acts as a drone/anchor while the moving notes create melodic interest above or below it.

Moving patterns: scale_asc — ascending scale notes scale_desc — descending scale notes scale_wave — alternating ascending/descending arpeggio — chord tones rotating chromatic — chromatic approach notes

Subdivisions: 8th, 16th, 32nd — determines speed of alternation

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, mixolydian, harmonic_minor). bars: Number of bars (1-8). octave: Starting MIDI octave (2-6). pedal_pitch: MIDI pitch for the fixed pedal note. If -1, uses root at the specified octave (e.g., G4 = 67). moving_pattern: Pattern for moving notes (scale_asc, scale_desc, scale_wave, arpeggio, chromatic). subdivision: Note subdivision (8th, 16th, 32nd). velocity: Base velocity for moving notes 0-1. pedal_velocity: Velocity for pedal notes 0-1 (usually louder). accent_pedal: If True, pedal notes get accent (slightly louder). unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, pedal/moving note counts, and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoG
scaleNomajor
octaveNo
velocityNo
start_beatNo
unit_indexNo
pedal_pitchNo
subdivisionNo16th
track_indexNo
accent_pedalNo
moving_patternNoscale_asc
pedal_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers what the tool creates, the parameters, and the return value. It does not fully disclose whether it modifies existing tracks or creates new ones, but the parameter names suggest it operates on existing tracks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear headings and a concise first line. However, it includes historical context that may be extraneous for an AI agent, making it slightly longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (13 params, no schema descriptions), the description covers all parameters and return info. It lacks explicit context on how the created notes integrate into the project (e.g., whether a new clip is created or notes are added to an existing region).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides detailed explanations for all 13 parameters, including default behavior (e.g., pedal_pitch -1 uses root at octave). This compensates for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence clearly states 'Create a bariolage' and explains the technique. It distinguishes from siblings by explicitly contrasting with arpeggiator and montuno, making the purpose distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts with arpeggiator and montuno, giving context for when to use this technique (Baroque string). However, it does not explicitly list alternative tools or provide a decision tree for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_bass_dropA

Create a bass drop — descending pitch sweep into sustained sub bass.

Generates a pitched sweep downward (the "wub" or "fall") followed by a sustained low note. The quintessential dubstep/bass music drop. Also works for EDM build-and-drop, trap bass falls, and impact transitions.

The tool creates two phases:

  1. Sweep phase: notes descend from start_pitch to end_pitch over sweep_beats

  2. Hold phase: a single sustained note at end_pitch for hold_beats

start_pitch: Starting MIDI pitch for the sweep (default 48 = C3). end_pitch: Landing pitch for the sustained bass (default 24 = C1, sub bass). sweep_beats: Duration of the descending sweep in beats (0.5-8, default 2). hold_beats: Duration of the sustained bass after landing (0-16, default 4). sweep_curve: Pitch curve — "linear" (even), "exp" (fast start, slow landing), "log" (slow start, fast landing). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the drop begins. velocity: Base velocity (0-1, default 1.0 = maximum impact).

Returns notes created, sweep/hold details.

ParametersJSON Schema
NameRequiredDescriptionDefault
velocityNo
end_pitchNo
hold_beatsNo
start_beatNo
unit_indexNo
start_pitchNo
sweep_beatsNo
sweep_curveNoexp
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It details the two-phase generation process, parameter roles, and return value. However, it does not clarify if notes are appended or overwritten on the track.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, context, phase breakdown, parameter list, and return value. It is slightly long but every part is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no required, output schema exists), the description covers the purpose, usage, parameters, output, and genre context comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description thoroughly explains all 9 parameters with defaults, ranges, and musical context, adding significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a bass drop with two phases (sweep and hold). It specifies the sound effect and use cases (dubstep, EDM, trap), distinguishing it from sibling tools like create_buildup or create_riser.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use it (e.g., 'quintessential dubstep/bass music drop') but does not explicitly mention when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_bass_from_progressionA

Create a bass line from a chord progression string.

The harmonic trio: create_chord_pads (sustained harmony) + create_arpeggiated_progression (melodic movement) + THIS (bass foundation). All three take the same "Am-F-C-G" string.

pattern: Bass pattern: "root" — root notes on beat 1 + 3, quarter notes (universal) "root_fifth" — root on 1, fifth on 3 (rock, pop) "walking" — 4 quarter notes per bar: root → passing → chord tone → approach to next root (jazz) "pedal" — one sustained root per chord (techno, house sub-bass) "octave" — root + octave in 8th notes (disco, funk) "root_octave" — root on 1, octave up on 3 (pop, rock power)

bars_per_chord: Bars per chord (default 4). octave: MIDI octave for bass (2 = C2=36, typical bass range). velocity: Note velocity (0-1, default 0.9 = strong bass). track_index: Track for bass (typically bass track = 1).

Example:

Jazz walking bass from ii-V-I-vi

create_bass_from_progression("Dm7-G7-Cmaj7-Am7", pattern="walking", octave=2)

Rock root-fifth from I-IV-V

create_bass_from_progression("A-D-E", pattern="root_fifth", octave=2, velocity=0.95)

House pedal sub-bass

create_bass_from_progression("Fm-Fm-Db-Ab", pattern="pedal", octave=1, bars_per_chord=4)

Disco octave bass

create_bass_from_progression("C-Am-F-G", pattern="octave", octave=2, velocity=0.9)

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
patternNoroot
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains each pattern's rhythmic behavior, MIDI octave range, velocity range, and default values. It does not mention side effects or authorization needs, but for a generative tool, it is sufficiently transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose statement, context (harmonic trio), parameter definitions with examples, and multiple usage examples. It is slightly verbose but every sentence adds value, and the formatting aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and the generative nature, the description lacks explicit mention of return value (likely success/failure). It provides comprehensive input guidance but omits what the tool returns, which is a minor gap for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning for 6 of 8 parameters: pattern (with detailed pattern definitions), bars_per_chord, octave (with MIDI note reference), velocity (range and default), track_index, and progression. Two parameters (start_beat, unit_index) are not described, but the overall parameter semantics are well-enhanced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a bass line from a chord progression string' and distinguishes itself from siblings like create_bassline by detailing the harmonic trio (chord pads, arpeggiated progression, bass foundation). Examples further clarify the specific role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool—as part of the harmonic trio for bass foundation—and offers pattern recommendations with genre associations. It does not explicitly state when not to use, but the examples and pattern descriptions serve as adequate guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_basslineA

Create a bassline from root note + rhythmic pattern — one call instead of 8-20 create_note calls.

Basslines use low octaves (default octave 2 = C2=36) and high velocity (default 0.9).

root: Root note name (C, C#, D, D#, E, F, F#, G, G#, A, A#, B or flats Db, Eb, Gb, Ab, Bb). pattern: Rhythmic pattern using scale degrees and special chars. Each step = one 16th note:

  • Numbers 1-7 = scale degree (1 = root, 5 = fifth, etc.)

  • 0 = rest

  • '-' = sustain previous note (tie)

  • '+' = octave up for next note

  • '_' = octave down for next note

  • Example: "1 - - - 5 - - - 1 - - - 4 - - -" = root-fifth-root-fourth bassline

  • Example: "1 0 1 0 5 0 5 0 1 0 1 0 3 0 3 0" = syncopated bass unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the bassline starts (0 = bar 1). octave: MIDI octave for the root (2 = C2=36, typical bass range). velocity: Note velocity 0-1 (default 0.9 for strong bass). scale: Scale type for degree mapping (default "minor"). Same scales as create_melody.

Returns the total notes created and pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes
scaleNominor
octaveNo
patternYes
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: bassline octave and velocity defaults, pattern notation with special characters, return value, and parameter defaults. It provides comprehensive transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough with examples and parameter details, which adds length but remains front-loaded and efficient. Slightly long but acceptable given complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and an output schema, the description covers purpose, pattern syntax, defaults, and return value comprehensively. No missing context for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description explains each parameter in detail, including root note formats, pattern syntax with examples, and defaults for octave, velocity, scale, etc. It fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence clearly states the tool creates a bassline from root note and rhythmic pattern, and explicitly contrasts with multiple create_note calls, differentiating it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for bassline creation efficiently, contrasting with create_note, but does not explicitly mention when not to use it or provide alternatives among other bass-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_binary_formA

Create binary form — two contrasting sections (A|B) with optional repeats.

Binary form is the simplest structural form in Western music: two self-contained sections, each typically repeated. The A section establishes the tonic, the B section departs and returns. Found in Baroque dance suites (Bach, Handel), folk tunes, early jazz, and many pop structures.

Modulation types (how B section relates to A):

  • dominant: B section in the dominant key (V). Classical approach — Bach two-part inventions, Baroque dance movements.

  • relative: B section in the relative minor/major. Romantic and folk approach — gentler contrast.

  • subdominant: B section in the subdominant (IV). Church hymns, modal folk tunes.

  • parallel: B section stays in same key but uses contrasting melodic material. Minimalist/folk approach.

  • no_modulation: B section identical key, same harmonic center.

With repeat=True, each section is played twice (AABB structure), matching the traditional binary form with repeat marks.

A section: stepwise melody around tonic, I-V-I harmony. B section: contrasting melody in modulated key, wider intervals, returns to tonic at end.

Creates melody on track_index, bass on track_index+1.

ParametersJSON Schema
NameRequiredDescriptionDefault
repeatNo
key_rootNoG
velocityNo
modulationNodominant
scale_nameNomajor
start_beatNo
unit_indexNo
track_indexNo
bars_per_sectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses key behavioral details: it creates melody on track_index and bass on track_index+1, explains modulation types, repeat structure, and section characteristics. It does not cover error cases or prerequisites, but for a creation tool, this is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections, but it is somewhat verbose. It front-loads the core purpose and then provides background. A bit more conciseness would improve it, but it is still organized and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (which likely documents return values), the description covers creation aspects adequately but lacks details on prerequisites, error conditions, or how this tool interacts with others. For a 9-parameter tool with no parameter documentation, it is moderately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must compensate. It explains modulation types and repeat in detail, but several parameters like velocity, start_beat, unit_index, bars_per_section, key_root, and scale_name are not described. The description adds some value but not enough to fully compensate for missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a binary form (A|B sections) with optional repeats, distinguishing it from sibling tools like create_ternary_form or create_rondo. It provides a specific verb ('create') and resource ('binary form'), and explains the musical concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides musical context (Baroque, folk, etc.) but does not explicitly state when to use this tool over alternatives. No direct comparisons to other form creation tools or exclusions are given, which limits guidance for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_blues_arrangementA

Create a full blues arrangement — shuffle drums + walking bass + dominant 7th chords + blues scale lead.

Classic 12-bar blues — the foundation of American popular music:

  • Track 0: Drums — shuffle/blues groove: kick on 1 and 3, snare on 2 and 4, shuffled hi-hats (triplet feel). The blues shuffle is the heartbeat — not straight 8ths, not full triplets, but the in-between "swing" that makes blues feel like blues.

  • Track 1: Bass — walking bass: quarter notes outlining the chord changes. I-I-I-I | IV-IV-I-I | V-IV-I-V. Each beat walks to the next chord tone — the jazz/blues lineage.

  • Track 2: Chords — dominant 7th voicings (I7, IV7, V7). The blues doesn't use triads — every chord is a 7th. Stab pattern on beats 1 and 3, with shuffle feel.

  • Track 3: Lead — blues scale (root, b3, 4, b5, 5, b7) with blue notes. Bends, slides, long held notes. The "crying guitar" quality — pentatonic minor with the flat 5 blue note for tension.

At 120 BPM (default), this is the classic Chicago blues tempo. At 90 BPM, it's a slow blues (B.B. King). At 140, it's a fast shuffle (Stevie Ray Vaughan).

The 12-bar form: I-I-I-I-IV-IV-I-I-V-IV-I-V. This is the most important chord progression in popular music — the DNA of rock, jazz, soul, and R&B.

bpm: Tempo (70-160, default 120 = classic Chicago blues). bars: Arrangement length (must be multiple of 12 for full blues form. 12 = one chorus, 24 = two choruses, default 12). root: Root note (A is the most common blues key — guitar-friendly). octave: MIDI octave for bass (2 = A2=45, standard blues bass register). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_blues_arrangement(bpm=120, root="A", bars=12) create_blues_arrangement(bpm=90, root="E", bars=24) # slow blues, 2 choruses

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoA
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
chord_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the musical output but does not disclose operational behaviors such as whether existing track data is overwritten, what happens with invalid track indices, or if the tool is idempotent. No annotations are provided, so the description carries the full burden, which it partially meets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose and includes extensive musical education, which may be informative but could be more concise. The key information is front-loaded, but the later sections repeat concepts (e.g., the 12-bar progression).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description comprehensively covers the tool's purpose, musical structure, parameter usage, and examples. It provides sufficient context for an AI agent to understand the output and constraints, especially given that an output schema exists (not shown here).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining most parameters (bpm, bars, root, octave, tracks) and providing examples. However, parameters like 'velocity' and 'start_beat' are not described, leaving some gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a full blues arrangement with specific instrumentation (drums, bass, chords, lead) and musical details. It distinguishes itself from sibling arrangement tools by focusing on the blues genre and 12-bar form.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive musical context and parameter usage but lacks explicit guidance on when to use this tool versus sibling arrangement tools. It implies usage through genre specificity but does not directly advise against using it for non-blues styles.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_boom_bapA

Create a boom-bap hip-hop drum pattern — the foundational beat of hip-hop.

Boom-bap: "boom" = kick drum, "bap" = snare. The pattern places kicks on beats 1 and 3, snares on beats 2 and 4 — the backbone of hip-hop from Run-DMC to Nas to Kendrick Lamar. Hi-hats fill the 8th or 16th notes between. The feel comes from swing/groove and kick placement variations.

boom_bap_type: "classic" — 90s boom-bap: kick on 1 and 3, snare on 2 and 4, hats on every 8th. The "Untitled" / Nas "Illmatic" feel. 2-bar cycle with kick variation on bar 2. "old_school" — 80s old school: simpler, kick strictly on 1 and 3, snare on 2 and 4, hats on quarter notes. Run-DMC / LL Cool J style. Less syncopation. "trap" — Trap: rolling hi-hats (16ths with occasional triplets), kick on 1 and "and of 2" and 3.5, snare on 4 only. Faster hats. Migos / Future style. "lofi" — Lo-fi hip-hop: laid-back, kick slightly behind beat (0.95 and 2.95), snare on 2 and 4, hats on 8ths with subtle swing. J Dilla / Nujabes feel. "drill" — UK drill: sliding bass kicks, snare on 3 only, chaotic hi-hat patterns with rolls. Headie One / Central Cee style. More aggressive kick patterns.

bars: Pattern length (2-16, 2 = one boom-bap cycle). kick_pitch: MIDI pitch for kick (36 = C1). snare_pitch: MIDI pitch for snare (38 = D1, acoustic snare). hat_pitch: MIDI pitch for hi-hats (42 = F#1, closed hat). velocity: Base velocity 0-1. Ghost hats -0.2, snares -0.05.

Returns notes created, boom-bap type, and stroke breakdown.

Example: create_boom_bap(boom_bap_type="classic", track_index=0) create_boom_bap(boom_bap_type="lofi", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
hat_pitchNo
kick_pitchNo
start_beatNo
unit_indexNo
snare_pitchNo
track_indexNo
boom_bap_typeNoclassic

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains pattern structure, parameter effects on rhythm, and return values, but lacks details on side effects (e.g., whether existing notes are cleared) and does not fully disclose the behavior for each parameter combination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and provides structured subtype explanations, but parameter descriptions are embedded in prose rather than listed, making it slightly less scannable. Still efficient for the amount of detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main pattern types and parameters, but misses details on start_beat, unit_index, and track_index. It mentions return values partially, and does not address how the tool interacts with existing track content. Adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description adds meaning for bars, pitches, velocity, and boom_bap_type with examples, but fails to describe start_beat, unit_index, and track_index, leaving these parameters underdefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a boom-bap hip-hop drum pattern', explains the core concept, and distinguishes from sibling tools by focusing on a specific genre pattern with detailed subtype definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (for hip-hop drum patterns) and provides context for each subtype, but it does not explicitly state when not to use it or compare it to alternatives like create_trap_arrangement or create_lofi_arrangement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_bordunA

Create a bordun — continuously sustained drone chord as a textural layer.

A bordun (bourdon) is a continuously sounding tone or chord that provides a harmonic foundation beneath changing melody. Unlike pedal_point (which is a single repeated/anchored note), the bordun is a sustained textural layer — often an open fifth, octave, or drone chord. Found in Scottish bagpipes, Indian tanpura, hurdy-gurdy, ambient drone music, and folk.

root: Root note name (e.g. "C", "Ab", "F#"). octave: Octave for the bordun (1-6, default 3 = low register). intervals: Comma-separated semitone intervals from root (e.g. "0,7" = open fifth, "0,7,12" = octave+fifth, "0,3,7" = minor triad drone, "0,5" = open fourth). bars: Total length in bars (1-16, default 4). beats_per_bar: Time signature beats (3/4=3, 4/4=4, 6/8=6, default 4). velocity: Velocity of bordun notes (0-1, default 0.55 — softer than melody). retrigger_bars: If >0, re-triggers the bordun every N bars (e.g. 2 = retrigger every 2 bars). If 0, one continuous sustained note for entire duration. unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the bordun begins.

Returns notes created, pitches, total duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
octaveNo
velocityNo
intervalsNo0,7
start_beatNo
unit_indexNo
track_indexNo
beats_per_barNo
retrigger_barsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It details the effect (creates sustained drone chord) and parameters, but does not disclose potential side effects, mutability, or whether it overwrites existing notes. Some behavioral aspects like note creation and retriggering are covered, but safety and idempotency are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear definition, musical context, and a parameter list. It is somewhat lengthy but each sentence adds value. It could be slightly more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters, distinguishes from sibling tools, and mentions return values. With an output schema present, the return value description is adequate. The musical examples provide rich context, making it complete for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the tool description provides exhaustive explanations for all 10 parameters, including defaults, ranges, and musical semantics. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a bordun — continuously sustained drone chord as a textural layer.' It provides a specific verb and resource, and explicitly contrasts with the sibling tool pedal_point, making it easy to differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what a bordun is and where it is used, and contrasts it with pedal_point. However, it does not explicitly state when to use or not use this tool, nor does it specify alternatives beyond the one contrast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_breakA

Create a classic drum break — the foundation of jungle, DnB, hip-hop, breakbeat.

Generates iconic drum break patterns from presets, with optional variation and swing. Each preset is a 1-bar pattern that can be repeated for multiple bars.

break_type: Classic break pattern preset.

  • "amen" — Amen Break (The Winstons, 1969). The most sampled break in history. Kick on 1 and 3, snare on 2 and 4, with syncopated ghost.

  • "think" — Think Break (Lyn Collins, 1972). Kick on 1, 1.75, 3.25 — distinctive off-beat kick pattern.

  • "ashanti" — Ashanti Roosevelt break. Kick on 1, 2, 3.25 — funky displaced kicks.

  • "funky_drummer" — Clyde Stubblefield break (James Brown). Straight kicks, dense 16th hi-hats.

  • "when_the_levee" — When the Levee Breaks (Led Zeppelin). Heavy kick/snare, sparse hi-hat. The boom-bap template.

  • "synthetic" — Electronic breakbeat. Off-beat hi-hats, four-on-the-floor kick. bars: Number of bars to generate (1-8, default 1). Each bar is a repeat with optional variation. variation: Per-bar variation mode.

  • "none" — exact repeat

  • "fill" — last bar gets a fill (denser snare/hihat)

  • "humanize" — subtle timing/velocity variation per bar

  • "drop" — last bar drops the kick (tension before drop) unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the break starts. swing: Swing amount (0.0-0.65, 0 = straight, 0.58 = classic hip-hop swing).

Returns notes created, break type, and bars.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
swingNo
variationNonone
break_typeNoamen
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior fully. It describes that it generates patterns, repeats bars, applies variation, and returns notes. However, it does not mention side effects like whether it overwrites existing notes, prerequisites (e.g., the track must have an audio unit with note tracks), or potential destructive actions. Given no annotations, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description starts with a concise value proposition, then a structural overview, then parameter details. Every sentence adds value; the parameter descriptions are detailed but necessary due to low schema coverage. It is front-loaded with the primary purpose. Minor redundancy is acceptable given the need for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the tool's core function, all parameters, and the return value. It lacks explicit prerequisites (e.g., the existence of a note track) and does not clarify the behavior of default values like 'unit_index: -1'. However, given the complexity and the presence of an output schema, the description is mostly complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description carries the full burden for parameter meaning. It provides detailed explanations for all 7 parameters, including the enum-like breakdown of 'break_type' with musical context for each preset, and clear options for 'variation'. Each parameter's role is clearly defined, fully compensating for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Create a classic drum break.' It distinguishes itself from siblings like 'create_drum_pattern' and 'create_breakbeat' by emphasizing it generates patterns from presets with specific iconic break types (amen, think, etc.), making its unique value obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it's for generating classic drum breaks from presets with optional variation and swing. However, it does not explicitly contrast with alternative tools (e.g., 'create_drum_pattern' for arbitrary patterns), nor does it state when not to use it. The context is clear but lacks explicit exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_breakbeatA

Create a breakbeat pattern — the syncopated skeleton of jungle, DnB, big beat, and breakbeat hardcore.

Breakbeats are "broken" drum patterns where the snare and kick don't sit on clean quarter notes. Instead they syncopate, stutter, and displace — creating the forward-leaning momentum that powered hip-hop's early years (Amen break), then jungle/DnB (160-180 BPM chopped breaks), big beat (Fatboy Slim, Prodigy), and UK garage/2-step.

breakbeat_type: "amen" — The Amen break: G.C. Coleman's performance in The Winstons "Amen, Brother" (1969). The most sampled 6-second loop in history. Kick at 0, 2.66; snare at 1, 3; ghost snare at 2.66. Hats on 8ths. The DNA of jungle and DnB. "dnb" — Drum & bass: chopped Amen-style at DnB tempo. Kick on 0 and 2.5, snare on 1 and 3, rapid 16th hats, ghost snares on the "e" and "a". Rolling, driving. Andy C / Noisia style. "big_beat" — Big beat: mid-tempo (120-130) fat breaks. Kick on 0 and 2.66, snare on 1 and 3, with a kick+snare syncopation on beat 2. Big, swaggering. Fatboy Slim / Prodigy "Firestarter". "2_step" — UK garage 2-step: kick on 1 and 3, snare on 2 and 4, but the second kick is shifted to 2.66 and there's a ghost snare on 3.5. Swung 16ths. The "skipping" feel. MJ Cole / Disclosure style. "funky_drummer" — Clyde Stubblefield's break from James Brown "Funky Drummer" (1970). Kick at 0, 2, 2.66; snare at 1, 3; hats throughout with ghost notes. The most funk-sampled break. Public Enemy, NWA, LL Cool J all built on this.

bars: Pattern length (2-16, 2 = one breakbeat cycle). kick_pitch: MIDI pitch for kick (36 = C1). snare_pitch: MIDI pitch for snare (38 = D1). hat_pitch: MIDI pitch for hi-hats (42 = F#1). ghost_pitch: MIDI pitch for ghost snares (37 = F#1, side-stick). velocity: Base velocity 0-1. Snares -0.05, hats -0.15, ghosts -0.3.

Returns notes created, breakbeat type, and stroke breakdown.

Example: create_breakbeat(breakbeat_type="amen", track_index=0) create_breakbeat(breakbeat_type="dnb", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
hat_pitchNo
kick_pitchNo
start_beatNo
unit_indexNo
ghost_pitchNo
snare_pitchNo
track_indexNo
breakbeat_typeNoamen

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that notes are created, returns notes created, breakbeat type, and stroke breakdown. It details pitch defaults, velocity adjustments per stroke, and examples. However, it does not mention whether it clears existing notes or requires a specific track state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear purpose, then provides musical context, type details, parameter explanations, and examples. While somewhat lengthy, the structure is logical. A minor reduction in historical detail could improve conciseness without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 params, no annotations, output schema exists), the description is comprehensive. It covers breakbeat types, pitches, velocity, and return values. Missing explicit mention of start_beat and unit_index slightly reduces completeness, but overall it is well-rounded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains breakbeat_type with extensive details, describes pitch defaults, velocity behavior, and bars. Examples show track_index usage. However, parameters like start_beat and unit_index are not described, leaving some gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a breakbeat pattern' and specifies it's 'the syncopated skeleton of jungle, DnB, big beat, and breakbeat hardcore.' It distinguishes from sibling tools that create other patterns (e.g., create_boom_bap, create_four_on_floor) by focusing on breakbeats and listing detailed types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what breakbeats are and when they are used (e.g., jungle, DnB, big beat). However, it does not explicitly state when not to use this tool or compare it to alternatives like create_drum_pattern or create_boom_bap. The guidance is implicit through the type descriptions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_buildupA

Create a complete build-up — riser + snare roll in one call.

Combines two transition elements for a full build-up before a drop/chorus:

  1. Pitch riser (ascending notes with velocity ramp)

  2. Snare roll (increasing density + velocity crescendo)

style: Build-up character:

  • "edm" — 1/4 snare → 1/8 → 1/16 → 32nd roll, exp riser C2→C6

  • "trap" — 1/4 snare → triplets → 32nd roll, exp riser C1→C5

  • "techno" — ride cymbal buildup + open hat crescendo, exp riser C2→C4

  • "rock" — tom roll buildup, linear riser C2→C4

  • "minimal" — just riser, no snare roll (subtle build)

unit_index: AU index (-1 = find first AU with note tracks). track_index: Note track index for riser. start_beat: Where the build-up begins. length_beats: Total build-up length (default 8 = 2 bars). velocity: Base velocity (0-1, ramped up during build).

Returns notes created for riser and snare roll.

Example:

8-beat EDM build-up before a drop

create_buildup(start_beat=0, length_beats=8, style="edm")

Then drop

create_impact(start_beat=8, impact_type="sub_boom")

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoedm
velocityNo
start_beatNo
unit_indexNo
track_indexNo
length_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool creates notes for riser and snare roll, details style-specific behaviors, and explains the meaning of each parameter. It does not mention whether it appends or overwrites existing notes, but overall is transparent about its operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a brief intro, bullet points for style options, and parameter list. While it is longer than needed, every sentence adds value and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description provides sufficient information about return values. It covers all parameters, styles, and usage context. It could mention alternative tools like create_riser or create_section_transition, but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description provides detailed explanations and default values for all 6 parameters. For the 'style' parameter, it explicitly lists all possible values and their musical effects, which adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool creates a complete build-up combining a riser and snare roll, specifying it is for use before a drop/chorus. It distinguishes itself from siblings like create_riser and create_trap_rolls by being a combined call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use (before a drop/chorus) and includes a usage example with create_impact. It does not explicitly state when not to use or list alternative tools, but the example and style options give clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_cadenzaA

Create a cadenza — an unmeasured virtuosic solo passage with rubato.

A cadenza is a solo passage where the performer has rhythmic freedom. Unlike all other tools that use quantized beat grids, cadenzas use irregular, speech-like rhythm — accelerando, rallentando, fermatas, and dramatic pauses. The notes follow a virtuosic contour: rapid runs, wide leaps, trills, and dramatic peaks.

Styles: classical — Mozart/Beethoven style: balanced phrases, cadential trills romantic — Liszt/Chopin style: dramatic octaves, cascading runs jazz — Coltrane/Parker style: bebop lines, chromatic turns modern — Ligeti/Berio style: extreme registers, clusters

The cadenza is built from segments, each with its own tempo character:

  • Flourish: rapid ascending/descending run

  • Leap: dramatic wide interval jump

  • Trill: alternating two pitches rapidly

  • Fermata: held note with pause after

  • Cascade: descending arpeggio pattern

  • Climb: gradual ascending with crescendo

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, harmonic_minor, etc.). duration_beats: Approximate total duration in beats (4-64). octave: Starting MIDI octave (2-6). style: Cadenza style (classical, romantic, jazz, modern). virtuosic: If True, more rapid passages and wider leaps. breath_marks: Comma-separated beat positions for pauses/breaths. velocity: Base velocity 0-1 (cadenzas have wide dynamic range). unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, segment breakdown, and cadenza statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNominor
styleNoclassical
octaveNo
velocityNo
virtuosicNo
start_beatNo
unit_indexNo
track_indexNo
breath_marksNo
duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that cadenzas use irregular, speech-like rhythm, can include accelerando, rallentando, fermatas, and pauses, and mentions output (notes created, segment breakdown, statistics). It lacks detail on potential side effects or permissions but is thorough for a creative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for definition, contrast, styles, segment types, and arguments. However, it is slightly verbose; some sentences could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and only a mention of output schema, the description is exceptionally complete. It explains the tool's unique role, styles, segment types, all parameters, and expected return data, making it fully actionable for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains every parameter (root, scale, style, octave, velocity, virtuosic, breath_marks, duration_beats, unit_index, track_index, start_beat) and adds context about segment types (Flourish, Leap, Trill, etc.), providing meaning far beyond the schema's defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a cadenza — an unmeasured virtuosic solo passage with rubato.' It defines a cadenza, contrasts it with quantized beat grid tools, and lists styles and segment types, making the purpose specific and distinguishable from many sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (for unmeasured, rubato passages) by contrasting with other tools that use quantized beat grids. It provides clear context but does not explicitly list alternatives or when not to use it, which would make it a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_call_and_responseA

Create call-and-response — two phrases in musical dialogue.

Call-and-response is the most fundamental musical conversation: a leader phrase (call) followed by a response phrase. Root of blues, gospel, African music, jazz, work songs, and hip-hop.

Response types:

  • echo: exact repeat of the call (African tradition, gospel)

  • transpose: repeat transposed by response_interval semitones (blues, jazz — response at IV or V)

  • variation: same pitches, varied rhythm (jazz, bebop)

  • complementary: contrasting phrase using scale degrees (gospel, soul — response "answers" the call)

  • fill: shorter response — last note only, or 2-note fill (blues turnaround, funk fills)

Call pattern: space-separated scale degrees (0=root, 2=2nd, etc.). Call rhythm: space-separated durations in beats. Response interval: for transpose type, semitones to shift (5 = perfect 4th up, 7 = perfect 5th up, -5 = 4th down). Pairs: number of call-response pairs. Gap beats: silence between call and response.

Creates call on track_index, response on track_index+1.

ParametersJSON Schema
NameRequiredDescriptionDefault
pairsNo
key_rootNoC
velocityNo
gap_beatsNo
scale_nameNomajor
start_beatNo
unit_indexNo
call_rhythmNo0.5 0.5 0.5 1.0 0.5 0.5
track_indexNo
call_patternNo0 2 4 7 4 2
response_typeNoecho
response_intervalNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It transparently explains that the tool creates call on track_index and response on track_index+1, and details response type behaviors. It omits potential overwrite behavior or permissions, but provides adequate transparency for a creative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with bullet points for response types and parameter explanations. Some information could be condensed, but the musical context justifies the length for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lacks explanation of return values or output format. It covers key behavioral aspects and many parameters, but misses some parameter explanations and the return value, leaving some gaps for a tool with 12 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add value. It provides detailed explanations for call_pattern, call_rhythm, response_interval, response_type, gap_beats, and pairs, including enumeration of response types. It does not explain key_root, velocity, scale_name, start_beat, unit_index, or track_index, though some are self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates call-and-response patterns, with a specific verb ('create') and resource ('call-and-response'). It distinguishes from sibling tools like create_arpeggio, create_bassline, etc., which create different musical structures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains call-and-response as a concept and lists response types, implying appropriate contexts. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. With many sibling tools, more explicit differentiation would help.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_call_responseB

Create a call-and-response pattern — antecedent/consequent phrase structure.

The call (antecedent) poses a musical question, the response (consequent) answers it. This is the foundation of blues, jazz, hip-hop, electronic, and folk music. The pattern alternates: call → response → call → response, with the response starting after the call ends.

scale: Scale type (major, minor, blues, dorian, etc. — 14 types from music_theory). root: Root note name (C, C#, D, ... B). call_pattern: Scale degrees for the call phrase, space-separated (1-7, 0=rest, -=sustain). Example: "1 3 5 3" — rising and falling 4-note motif response_pattern: Scale degrees for the response phrase, space-separated. Example: "5 4 3 2" — descending answer repeats: Number of call+response pairs (1-8). 2 = call-response-call-response. octave: Starting octave (1-7, default 4). velocity: Note velocity 0-1. step_duration: Duration of each step in beats (0.25 = 16th, 0.125 = 8th triplet).

Returns total notes created and phrase structure.

Example: create_call_response(scale="blues", root="A", call_pattern="1 3 5 3", response_pattern="5 4 3 2", repeats=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes
scaleYes
octaveNo
repeatsNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo
call_patternYes
step_durationNo
response_patternYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description indicates returns (notes created, phrase structure) but does not disclose side effects like whether it overwrites existing notes or how track/unit parameters affect behavior. Moderate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with purpose and well-organized into explanation, parameter definitions, and example. Slightly verbose with redundant genre listing but overall concise for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core usage and musical concept, but lacks guidance on valid scale values (14 types from music_theory not enumerated), exact note syntax for patterns, and integration context (track/unit defaults). Agent may need additional knowledge to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining key parameters (scale, root, patterns, repeats, etc.) and providing examples. A few parameters like track_index and unit_index are omitted, but the main musical parameters are well-covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates call-and-response patterns with antecedent/consequent phrase structure. However, it fails to distinguish from the sibling tool `mcp_opendaw_create_call_and_response`, which likely serves a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like `create_melody` or the similarly named sibling. Lacks context on prerequisites or scenarios for optimal use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_canonA

Create a canon — strict melodic imitation with delayed voice entries.

The foundation of contrapuntal music: a single melody is repeated in multiple voices, each entering after a delay, optionally transposed. Think Pachelbel's Canon, "Row Row Row Your Boat", Bach's fugue subjects, or modern call-and-response layers in film scores. Unlike create_counterpoint (which generates a new line), a canon copies the SAME melody into each voice — just shifted in time and pitch.

melody: Comma-separated MIDI pitches of the lead voice (e.g. "60,62,64,67"). voices: Number of imitating voices (2-6, default 3). Voice 1 enters first. entry_delay_beats: Beats between each voice entry (1-16, default 4 = one bar in 4/4). transposition: Comma-separated semitone offsets per voice (e.g. "0,7,12" = unison, fifth, octave). Must have exactly voices values. "0,0,0" = all at same pitch (round/canon). velocity_decay: Velocity reduction per voice (0-0.3, default 0.15). Later voices are quieter, simulating natural ensemble hierarchy. direction: Voice entry order — "up" (low to high) or "down" (high to low). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the first voice begins. velocity: Base velocity for the first voice (0-1, default 0.85).

Returns notes created, voice count, total length, transpositions used.

ParametersJSON Schema
NameRequiredDescriptionDefault
melodyNo60,62,64,67,64,62,60,57
voicesNo
velocityNo
directionNoup
start_beatNo
unit_indexNo
track_indexNo
transpositionNo0,7,12
velocity_decayNo
entry_delay_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility. It describes the core behavior: copying a melody into multiple voices with time and pitch shifts, and notes return values. However, it does not explicitly state whether the tool is destructive or read-only, or if it modifies existing track content versus creating new regions. Still, it is fairly transparent about inputs and outputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear opening sentence defining the tool, a paragraph explaining the musical concept and distinguishing from siblings, followed by a bulleted list of parameters. Every sentence adds value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, no required fields, no enums) and that an output schema exists, the description is complete. It explains all parameters, provides examples, and mentions return values. The only minor gap is potential side effects, but the output schema covers return info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema (which has 0% coverage). Each parameter is explained with ranges, defaults, examples, and constraints (e.g., 'transposition must have exactly voices values'). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's purpose: 'Create a canon — strict melodic imitation with delayed voice entries.' It specifies the verb 'create' and the resource 'canon', and distinguishes from sibling tool 'create_counterpoint', which generates a new independent melody rather than copying the same melody.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (to create a canon) and when not to (for generating new independent counterpoint). It directly contrasts with 'create_counterpoint' and gives real-world examples like Pachelbel's Canon and 'Row Row Row Your Boat' to clarify usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_cascaraA

Create an Afro-Cuban cáscara pattern — the timbale shell rhythm that fills space around the clave.

Cáscara ("shell") is played on the sides of the timbale drums. It weaves between the clave and tumbao, filling the rhythmic gaps with a flowing, continuous feel. Together with clave and tumbao, it forms the three pillars of the Afro-Cuban rhythm section. The pattern uses two stroke heights: high (rim/edge, accented) and low (shell body, unaccented), creating a call-and-response within the pattern.

cascara_type: "son_3_2" — Son cáscara, 3-2 direction (forward clave). Bar 1: &2 high, 3 low, &3 high, &4 low Bar 2: &2 high, 3 low, &3 high, 4 low "son_2_3" — Son cáscara, 2-3 direction (reverse clave). Bar 1: &2 high, 3 low, &3 high, 4 low Bar 2: &2 high, 3 low, &3 high, &4 low "guaguanco" — Rumba guaguancó cáscara. Adds ghost strokes on beat 1 and &1 of each bar for a denser, more driving feel. "mambo" — Mambo cáscara. Adds syncopated accents on &4 of bar 2 and a fill on beat 4 of bar 2. Brighter, more showy.

bars: Pattern length (2 = one cáscara cycle, repeat for longer). high_pitch: MIDI pitch for high strokes (rim/edge of timbale, 76 = high wood block). low_pitch: MIDI pitch for low strokes (shell body, 60 = mid tom). velocity: Base velocity 0-1. High strokes +0.1, low strokes -0.05.

Returns notes created, cáscara type, direction, and stroke breakdown.

Example: create_cascara(cascara_type="son_3_2", track_index=0) create_cascara(cascara_type="guaguanco", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
low_pitchNo
high_pitchNo
start_beatNo
unit_indexNo
track_indexNo
cascara_typeNoson_3_2

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that high/low stroke pitches are used, velocity adjustments, and return values (notes created, type, direction). It does not mention destructive actions or permissions, but covers key behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and musical context, then details each parameter and type, ending with examples. It is somewhat lengthy but every sentence adds value. Minor redundancy in explaining the three pillars.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, musical pattern) and absent schema descriptions, the description is comprehensive about musical intent and parameter effects. It covers return values and includes examples. Missing details on positional parameters like start_beat prevent a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains cascara_type, bars, high_pitch, low_pitch, and velocity in detail, including stroke patterns and velocity offsets. However, start_beat, unit_index, and track_index are not described, leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates an Afro-Cuban cáscara pattern. It explains what cáscara is and its role alongside clave and tumbao, distinguishing it from sibling pattern tools like create_clave and create_tumbao.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for cáscara patterns within Afro-Cuban rhythm sections, mentioning clave and tumbao as counterparts. However, it lacks explicit guidance on when to use this tool versus alternatives, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_chaconneA

Create a chaconne — repeating bass + chord progression + developing variations.

A chaconne is a set of variations over a repeating bass line and harmonic progression. Unlike ground bass (bass only) or passacaglia (bass + variations), a chaconne explicitly repeats both the bass AND the chord progression, building variations on top of this fixed harmonic framework.

Bass pattern: space-separated note names (e.g. "C2 G2 A2 E2"). Bass rhythm: space-separated durations in beats (e.g. "1 1 1 1"). Chord pattern: comma-separated chord names aligned with bass notes (e.g. "C,Em,Am,G"). Supports major, minor, dim, aug, maj7, m7, 7. Variation styles:

  • baroque: descending stepwise lines with suspensions, ornaments accumulate

  • romantic: wide intervals, expressive phrases, rubato-like timing

  • jazz: syncopated, chromatic passing tones, swing-like rhythm

  • minimalist: repeating cells with gradual phase shift

  • contemporary: dissonant clusters, intervallic leaps, pointillistic

Creates bass on track_index, chord pads on track_index+1, variation on track_index+2.

ParametersJSON Schema
NameRequiredDescriptionDefault
repeatsNo
velocityNo
start_beatNo
unit_indexNo
bass_rhythmNo1 1 1 1
track_indexNo
bass_patternNoC2 G2 A2 E2
chord_patternNoC,Em,Am,G
variation_styleNobaroque

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden for behavioral disclosure. It explains the track layout (bass on track_index, chord pads on track_index+1, variation on track_index+2) and variation styles, which adds value. However, it does not discuss safety, idempotency, error conditions, or implications of repeated calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a clear definition and purpose, then detailing parameter formats and styles, and ending with track layout. It is appropriately sized with minimal redundancy, though slightly verbose in the variation style descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema (per context signals), the description provides sufficient conceptual and behavioral context. It covers the chaconne structure, parameter semantics, and track placement. Minor gaps exist, such as error handling or validity of inputs, but overall it is complete for a creative tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains formats for bass_pattern, bass_rhythm, chord_pattern, and variation_style, adding meaning beyond the schema. However, it leaves repeats, velocity, start_beat, unit_index, and track_index unexplained, covering only about 5 of 9 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines what a chaconne is, specifies it creates a repeating bass line and chord progression with variations, and explicitly distinguishes it from ground bass and passacaglia. This helps the agent understand the tool's unique purpose among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use a chaconne by defining it and contrasting with ground bass and passacaglia. However, it does not explicitly state when not to use this tool or recommend alternatives, though the sibling tools for ground bass and passacaglia exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_chopA

Create a chop — slice source pitches into segments and rearrange them.

The quintessential hip-hop/EDM sampling technique: take a sequence of pitches, cut it into equal segments, then rearrange (reverse, stutter, shuffle, ping-pong). Think Dilla chops, Madlib sample flips, Virtual Riot bass chops, or glitch-hop stutter effects. Each segment becomes a self-contained musical cell.

pitches: Comma-separated MIDI pitches to use as source material (e.g. "60,62,64,67"). chop_mode: How to rearrange segments — "reverse" (play segments backwards), "stutter" (repeat each segment N times — glitch/stutter effect), "shuffle" (random segment order, seeded), "ping-pong" (forward then backward — ABBA pattern), "gate" (silence every other segment — chopped break feel). segment_beats: Duration of each segment in beats (0.25-4, default 0.5 = 8th note). stutter_count: For stutter mode, times to repeat each segment (2-8, default 2). octave_shift: Shift all pitches by N octaves (default 0). -1 = down an octave for bass chops. velocity_variation: Vary velocity between segments (0-0.5, default 0.2). Adds human feel. reverse_pitch_in_segment: If true, reverse pitch order within each segment (inner chop). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the chop begins. velocity: Base velocity (0-1, default 0.9). seed: Random seed for reproducibility.

Returns notes created, segment count, mode used.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo
pitchesNo60,62,64,67,60,64,62,60
velocityNo
chop_modeNoreverse
start_beatNo
unit_indexNo
track_indexNo
octave_shiftNo
segment_beatsNo
stutter_countNo
velocity_variationNo
reverse_pitch_in_segmentNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool creates new notes and modifies their arrangement, but doesn't explicitly state whether it modifies existing notes or works non-destructively. The return value is mentioned, but permissions or side effects are not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear summary, contextual explanation, and parameter list. It is front-loaded with the main purpose. A few sentences could be trimmed, but overall it is appropriately sized for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 12 parameters, no annotations, and presence of output schema, the description provides a solid understanding of the tool's functionality, including modes, parameters, and return values. It lacks discussion of prerequisites or error cases, but is sufficient for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by explaining each parameter in detail with musical context (e.g., chop_mode explanations, segment_beats range, stutter_count range). It adds meaning beyond the schema property names, though some parameter details (like exact format for pitches) could be clearer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a chop — slice source pitches into segments and rearrange them.' It uses a specific verb-resource pair and distinguishes this tool from siblings by emphasizing the hip-hop/EDM sampling technique with references to Dilla, Madlib, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('quintessential hip-hop/EDM sampling technique') with examples of musical applications. However, it does not explicitly state when not to use it or mention alternative tools (e.g., create_stutter for stutter-only effects).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_choraleA

Create a 4-voice SATB chorale with voice-leading rules.

Generates soprano, alto, tenor, and bass voices from a chord progression with proper voice leading: common tones preserved, smooth voice movement (no unnecessary leaps), no parallel fifths or octaves between adjacent chords, and voices stay within their ranges (S: 60-81, A: 55-74, T: 48-67, B: 36-62). The soprano voice gets the melody line (chord roots or nearest chord tones). Classic Bach chorale style — foundational for vocal harmonies, string arrangements, synth pad layering.

chord_pattern: Comma-separated chord names (e.g. "C,Am,F,G"). Supports: maj, min, m7, maj7, dom7, sus2, sus4, dim, aug. beats_per_chord: Duration of each chord in beats (default 4 = 1 bar in 4/4). beats_per_bar: Time signature beats (3/4=3, 4/4=4, 6/8=6, default 4). key_root: Key root note for voice-leading context (e.g. "C", "F#", "Bb"). key_mode: Key mode — "major" or "minor" (affects voice assignment). soprano_velocity: Velocity of soprano voice (0-1, default 0.7). alto_velocity: Velocity of alto voice (0-1, default 0.6). tenor_velocity: Velocity of tenor voice (0-1, default 0.6). bass_velocity: Velocity of bass voice (0-1, default 0.65). note_duration: Note duration as fraction of chord length (0-1, default 0.9). voice_spread: Extra spacing between voices in semitones (0-12, default 0). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the chorale begins.

Returns notes created, chord count, voice ranges, voice-leading info.

ParametersJSON Schema
NameRequiredDescriptionDefault
key_modeNomajor
key_rootNoC
start_beatNo
unit_indexNo
track_indexNo
voice_spreadNo
alto_velocityNo
bass_velocityNo
beats_per_barNo
chord_patternNoC,Am,F,G
note_durationNo
tenor_velocityNo
beats_per_chordNo
soprano_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It details voice-leading rules, voice ranges, and that it returns notes created and voice-leading info. It does not explicitly state side effects (e.g., whether notes are appended or overwritten), but the behavior is largely transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and structured with paragraphs for voice-leading rules and parameter details. While somewhat lengthy, each sentence adds value. Parameter descriptions are clear but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 voices, voice-leading, 14 parameters), the description is thorough. It covers voice-leading rules, range constraints, parameter semantics, and output description. The presence of an output schema helps, but the description still adds necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description fully compensates by providing clear, detailed explanations for all 14 parameters, including defaults, formats, and supported values (e.g., chord_pattern lists all chord types). This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a 4-voice SATB chorale with voice-leading rules', specifying both the verb (create) and resource (chorale). The additional context of 'Classic Bach chorale style' distinguishes it from other creation tools like create_chord_pads or create_melody, making its unique purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use the tool, mentioning its suitability for 'vocal harmonies, string arrangements, synth pad layering'. However, it does not explicitly state when not to use or compare with alternatives like create_harmony or create_bassline, which would strengthen guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_chord_padsA

Create chord pads from a human-readable progression string.

Unlike create_chord_progression (which takes JSON arrays), this takes a simple hyphen-separated string like "Am-F-C-G" — much easier for agents and humans to write. Generates sustained chord pads with configurable octave, velocity, and bars per chord.

progression: Hyphen-separated chords. Each chord is root+type: "Am" = A minor, "F" = F major, "Cmaj7" = C major seventh, "G7" = G dominant 7, "Dm7" = D minor 7, "Esus4" = E suspended 4. Supported types: maj, min, dom7, maj7, min7, sus2, sus4, add9, dim, aug. Default "Am-F-C-G" = i-VI-III-VII in A minor (synthwave/trance). "C-Am-F-G" = I-vi-IV-V in C major (pop). "Dm7-G7-Cmaj7-Am7" = ii-V-I-vi in C (jazz).

bars_per_chord: How many bars each chord lasts (default 4 = one chord per 4-bar phrase). 2 = faster changes, 8 = slow pads.

octave: MIDI octave for chord voicing (3 = C3=48, typical pad range). velocity: Note velocity (0-1, default 0.65 = soft pad). unit_index: AU index with note tracks. track_index: Track for chord pads (typically harmony track = 2). start_beat: Where the progression starts. note_duration: Note length in beats (default 3.8 = almost full bar with small gap for articulation).

Returns chords created, pitches per chord, total notes.

Example:

i-VI-III-VII in A minor (synthwave pads)

create_chord_progression("Am-F-C-G", bars_per_chord=4, octave=3)

ii-V-I-vi in C (jazz comping under)

create_chord_progression("Dm7-G7-Cmaj7-Am7", bars_per_chord=2, octave=3)

I-V-vi-IV in C (pop progression)

create_chord_progression("C-G-Am-F", bars_per_chord=4, octave=4, track_index=2, velocity=0.6)

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
note_durationNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility. It explains the tool creates sustained chord pads with configurable parameters, describes return values (chords created, pitches, total notes), and covers default behaviors. However, it does not mention potential side effects or performance implications, which would elevate the score to 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear summary, parameter explanations, and examples. It front-loads the key differentiator and purpose. While comprehensive, it is slightly verbose but each sentence adds value. A score of 4 reflects good economy without being terse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, no annotations, and a complex harmonic domain, the description is remarkably complete. It covers input format, parameter roles, defaults, supported chord types, use case examples, and return values. The presence of an output schema is noted, and the description adequately explains what is returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds extensive meaning for each parameter. It details the chord format (root+type), supported types (maj, min, dom7, etc.), explains bars_per_chord, octave, velocity, and other parameters with default values and examples. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates chord pads from a human-readable progression string. It explicitly distinguishes from the sibling tool create_chord_progression by contrasting the input format (hyphen-separated string vs JSON arrays). The verb and resource are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus the alternative create_chord_progression, noting that this tool is for simpler string inputs. It also gives genre-specific examples (synthwave, pop, jazz) and explains default behaviors, helping the agent decide contextually.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_chord_progressionA

Create a chord progression from chord names — one call instead of 15-50 note creations.

chords: JSON array of chord specs. Each chord is [root_note_name, chord_type]. Root names: C, C#, D, D#, E, F, F#, G, G#, A, A#, B (or flats: Db, Eb, Gb, Ab, Bb) Chord types: maj, min, dom7, maj7, min7, sus2, sus4, add9, dim, aug

Example: '[["C","min"],["F","min"],["G","dom7"],["C","min"]]'

unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the progression starts (0 = bar 1). chord_duration: Length of each chord in beats (4 = one bar at 4/4).

Returns the total notes created and chord voicings used.

ParametersJSON Schema
NameRequiredDescriptionDefault
chordsYes
start_beatNo
unit_indexNo
track_indexNo
chord_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description lacks disclosure of side effects, idempotency, or performance. Only mentions return value, not behavioral traits like whether it is destructive or requires specific permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: purpose statement, then parameter details. Slightly verbose but each sentence adds value. Example and lists are clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and return value. Mentions output format briefly. Given no annotations and an output schema exists, the description is sufficiently complete for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Detailed explanation of all parameters with valid values, examples, and defaults. Compensates for 0% schema coverage by providing full semantic context for 'chords', 'start_beat', 'unit_index', 'track_index', and 'chord_duration'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Create a chord progression from chord names'. Distinguishes from siblings by emphasizing efficiency: 'one call instead of 15-50 note creations'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the batch advantage over individual note creation. Provides context for when to use, though no direct exclusion or alternative mention beyond the implicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_claveA

Create an Afro-Cuban clave pattern — the 5-note rhythmic skeleton that defines the feel.

The clave is not a drum pattern — it's a timeline pattern that all other rhythms align to. Every Afro-Cuban rhythm has a clave direction (3-2 or 2-3) that determines where the downbeats fall relative to the clave strokes.

clave_type: "son_3_2" — Son clave, 3-side first (forward clave). Beats: 0, 0.5, 1, 2.5, 3 "son_2_3" — Son clave, 2-side first (reverse clave). Beats: 0, 1.5, 3, 3.5, 4 "rumba_3_2" — Rumba clave, 3-side first. Last stroke shifted to 3.5 (and 2.5→2.66) "rumba_2_3" — Rumba clave, 2-side first. "bossa_nova" — Bossa nova clave. Beats: 0, 2.5, 3, 4.5, 5 (over 2 bars) "6_8" — 6/8 Afro-Cuban clave. 5 strokes across 2 bars of 6/8.

bars: Pattern length in bars (2 for son/rumba, 2 for bossa, 2 for 6/8). pitch: MIDI pitch for clave strokes (76 = high wood block). velocity: Velocity 0-1. duration: Note duration in beats.

Returns notes created, clave type, and direction (3-2 or 2-3).

Example: create_clave(clave_type="son_3_2", track_index=0) create_clave(clave_type="bossa_nova", track_index=1)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
pitchNo
durationNo
velocityNo
clave_typeNoson_3_2
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description is the sole source for behavioral insight. It details that notes are created, returns notes with type and direction, but does not specify if existing notes are cleared or if there are side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loading the purpose, then providing conceptual context, parameter details, return info, and an example. It is somewhat verbose but efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, parameters, return values, and includes examples. It explains clave direction and types thoroughly. Missing edge cases like invalid track_index, but adequate for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds substantial value by explaining each parameter, especially clave_type with beat positions. It compensates fully for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an Afro-Cuban clave pattern, distinguishes it from drum patterns, and explains its role as a timeline skeleton. This sets it apart from sibling tools like create_drum_pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to create clave patterns) and implicitly contrasts with drum patterns. No explicit alternatives are listed, but the unique purpose is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_colotomicA

Create a colotomic structure — interlocking gong layers marking cyclic time.

Gamelan music uses colotomic instruments (gongs of different sizes) to mark the cyclic structure of a piece. Each gong level has its own periodicity, creating an interlocking temporal grid. The largest gong (gong ageng) marks the end of a full cycle, while smaller gongs subdivide it into sections. The melodic instruments (saron, bonang) fill in between the gong strikes.

Unlike polyrhythm (simultaneous conflicting meters) or additive rhythm (unequal groupings), colotomic structure is hierarchical: each layer subdivides the cycle at a different level, creating a nested temporal hierarchy. This is the foundation of Indonesian gamelan, Javanese klenengan, and Balinese ritual music.

Structures: slendro — 8-beat gong cycle (gongan): gong at beat 8, kenong at 4, kempul at 2+6, kethuk at every odd beat. Slendro scale. pelog — 16-beat gong cycle: gong at 16, kenong at 8+12, kempul at 4+12, kethuk at every 2 beats. Pelog-inspired. lancaran — 8-beat with doubled kethuk (faster surface rhythm) ketawang — 16-beat with half-speed gong (longer cycle feel)

Tempo density: sparse — gong layers only, no melodic fill medium — gong layers + basic saron (elaboration) dense — gong layers + saron + bonang (full interlock)

Args: root: Root note name (C, C#, D, ...). scale: Scale name (pentatonic_minor, pentatonic_major, major, minor). Default pentatonic_minor for slendro-like feel. cycles: Number of gongan cycles (1-8). octave: Starting MIDI octave (2-5). structure: Structure type (slendro, pelog, lancaran, ketawang). tempo_density: Density level (sparse, medium, dense). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, gong layer breakdown, and cycle info.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNopentatonic_minor
cyclesNo
octaveNo
velocityNo
structureNoslendro
start_beatNo
unit_indexNo
track_indexNo
tempo_densityNomedium

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions the return value ('notes created, gong layer breakdown, and cycle info') but does not explain side effects such as whether existing notes are modified, which track is affected, or what happens on parameter failure. The description provides useful context but omits important behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a clear purpose, then background, detailed structure definitions, and a parameter list. Each section earns its place, though it is somewhat lengthy. It is front-loaded with the most important information (purpose and differentiation) and remains focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 10 parameters and no output schema. The description covers return values vaguely ('notes created, gong layer breakdown') but does not specify the exact format or how the tool integrates with the DAW project (e.g., whether it adds to an existing track or creates a new one). It also assumes familiarity with gamelan terminology, which may not be sufficient for all agents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes an 'Args' list that adds meaning beyond the schema titles and defaults. For example, it specifies that 'cycles' ranges 1-8, 'octave' 2-5, and defines the allowed structures (slendro, pelog, lancaran, ketawang). This significantly compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a colotomic structure — interlocking gong layers marking cyclic time,' clearly stating the specific verb and resource. It distinguishes this tool from siblings like 'create_polyrhythm' by explaining how colotomic structures are hierarchical and nested, unlike polyrhythm or additive rhythm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts colotomic structure with polyrhythm and additive rhythm, helping the agent choose when to use this tool over conceptual alternatives. However, it does not explicitly name sibling tools like 'create_polyrhythm' or 'create_additive_rhythm' as alternatives, leaving the guidance somewhat implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_comparsaB

Create Cuban comparsa — carnival procession percussion.

Comparsa is the percussion ensemble that accompanies Cuban carnival street processions (conga line). Rooted in Afro-Cuban tradition, it is the ancestor of salsa and modern Latin pop. The driving energy comes from layered conga drums with interlocking patterns.

Instruments (GM percussion mapping):

  • Conga low (54) — tumbadora, bass tone

  • Conga high (63) — quinto, slap tone

  • Conga open (64) — conga open tone

  • Clave (75) — wooden claves, the timeline

  • Cowbell (56) — cencerro, driving pulse

  • Maracas (70) — shaker

  • Guiro (73) — scraped gourd

Styles:

  • habanera: Classic Havana carnival. Conga pattern with clave 3-2, cowbell steady 8ths, maracas on offbeats. The street procession feel. 90-110 BPM.

  • santiago: Eastern Cuba, rumba-influenced. More syncopated conga patterns, guiro scrapes, claves 2-3. Looser feel.

  • matanzas: Rumba columbia roots. Quinto improvisation feel, open conga tones, sparse cowbell. Afro-Cuban spiritual energy.

  • conga_line: Street procession — marching feel. Steady bass conga on every beat, quinto syncopation, cowbell accent pattern. Designed for dancing in a line.

  • comparsa_moderna: Modern carnival — faster, denser, 16th-note maracas, driving cowbell, layered congas. Salsa-influenced energy.

Creates notes on track_index using GM percussion.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNohabanera
velocityNo
tempo_bpmNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It explains that notes are created on a track using GM percussion, and lists styles and instruments. However, it does not specify whether existing notes are overwritten or appended, nor any potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, but the description is lengthy with cultural background, instrument mapping, and style details. While informative, some content could be trimmed for conciseness without losing essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, no annotations, has output schema), the description lacks essential parameter explanations and does not mention the output schema. It provides cultural context but omits practical invocation details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no explanation of the 7 parameters (bars, style, velocity, etc.). The style list in the description is not explicitly linked to the 'style' parameter. The agent gets no help understanding parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a Cuban comparsa percussion pattern, explaining the cultural context and differentiating it from siblings like create_clave or create_songo_pattern. The verb 'create' and resource 'comparsa' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implicitly clear from the domain-specific purpose, but there is no explicit guidance on when to use this tool versus alternatives like create_clave or create_tumbao. No when-not conditions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_compingA

Create comping — rhythmic chordal accompaniment.

The most common accompaniment style in modern music: play chords in a rhythmic pattern rather than sustained blocks. Jazz piano comping, funk guitar chops, reggae skanks, country boom-chick, Neo-soul chords. Unlike create_chord_progression (sustained blocks) or create_stab (house stabs), comping gives each chord a rhythmic identity — the chord follows the groove.

chords: JSON array of chord specs, same as create_chord_progression. Each chord is [root_note_name, chord_type]. Root names: C, C#, D, D#, E, F, F#, G, G#, A, A#, B (or flats: Db, Eb, Gb, Ab, Bb) Chord types: maj, min, dom7, maj7, min7, sus2, sus4, add9, dim, aug Example: '[["C","min7"],["F","min7"],["G","dom7"],["C","min7"]]' rhythm: Rhythmic pattern string. Each char = one step of note_spacing beats: 'x' = play chord, '-' = rest, '.' = ghost (quiet chord) Default "x-x-x-x-" = off-beat eighths (classic jazz comping) "x--x--x-" = syncopated funk "x...x..." = boom-chick (country) "x-x-x-x-x-x-x-x" = reggae skank (every off-beat 16th) unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Where comping starts. chord_octave: MIDI octave for chord root (4 = C4=60). velocity: Base velocity (0-1, default 0.7). note_spacing: Duration of each rhythm step in beats (0.25=16th, 0.5=8th, default 0.5). syncopation: Probability of pushing a note slightly off-grid (0-0.5, default 0). Adds human feel — 0.1 = subtle, 0.3 = pronounced.

Returns notes created, chords played, rhythm pattern used.

ParametersJSON Schema
NameRequiredDescriptionDefault
chordsYes
rhythmNox-x-x-x-
velocityNo
start_beatNo
unit_indexNo
syncopationNo
track_indexNo
chord_octaveNo
note_spacingNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description bears the full burden. It explains that the tool creates notes on a track with specific parameters and returns notes, chords, and rhythm pattern. While it doesn't explicitly state non-destructive behavior or permission requirements, it gives sufficient detail about what the tool modifies and returns. Minor gap: no mention of whether it overwrites existing notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise purpose statement, sibling differentiation, then detailed parameter breakdown. It is front-loaded with the key concept. However, it is somewhat long; a few sentences could be trimmed without losing clarity. Still, it earns its length with useful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no annotations, but output schema exists), the description is complete. It covers all parameters with examples, explains the return value, and provides musical context. No gaps remain for an agent to understand invocation requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for parameters, so the description must provide full meaning. It does: every parameter (chords, rhythm, unit_index, track_index, start_beat, chord_octave, velocity, note_spacing, syncopation) is explained with format, defaults, and examples. The rhythm parameter even includes multiple pattern examples with musical context. This far exceeds schema capabilities.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates 'comping — rhythmic chordal accompaniment' and explicitly distinguishes it from sibling tools like create_chord_progression and create_stab by contrasting sustained vs rhythmic patterns. The verb 'create' and resource 'comping' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Unlike create_chord_progression (sustained blocks) or create_stab (house stabs), comping gives each chord a rhythmic identity — the chord follows the groove.' This clearly explains the context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_counter_melody_from_progressionA

Create a counter-melody (second melodic line) from a chord progression.

A counter-melody is a secondary melodic line that plays alongside the primary melody. It provides harmonic depth and contrapuntal interest without competing for the listener's attention.

This completes the harmonic quintet: chord_pads + arpeggiated_progression + bass_from_progression + melody_from_progression + THIS (counter-melody). Place on track 4 (default) to avoid clashing with melody (track 3).

pattern: Contrapuntal pattern: "contrary" — moves opposite to chord root motion (if root goes up, counter goes down). Classic species-1 counterpoint feel. "oblique" — one note sustained across the chord, changes only when the harmony forces it. Minimalist, drone-like. "parallel_third" — parallels the chord tones a third above. Sweet, consonant, pop/folk counter-melody. "parallel_sixth" — parallels the chord tones a sixth above. Open, spacious, cinematic. More independent than parallel third. "call_response" — answers after the melody would play: rests on beats 1-2, plays on beats 3-4. Antiphonal, gospel/soul feel.

bars_per_chord: Bars per chord (default 4). octave: MIDI octave (default 4 = below typical melody at 5). velocity: Lower than melody (0-1, default 0.6 = supportive, not competing). track_index: Track for counter-melody (default 4, above melody track 3).

Example:

Counter-melody below the lead

create_counter_melody_from_progression("Am-F-C-G", pattern="contrary", octave=4, velocity=0.6)

Cinematic parallel sixths

create_counter_melody_from_progression("Dm-G-C-Am", pattern="parallel_sixth", octave=4, velocity=0.55)

Gospel call-and-response

create_counter_melody_from_progression("C-Am-Dm-G", pattern="call_response", octave=5, velocity=0.65)

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
patternNocontrary
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It discloses that the tool places the counter-melody on track 4 by default to avoid clashing with melody, that velocity should be lower than melody, and describes five contrapuntal patterns. It does not mention return values, but the output schema exists. Overall, good behavioral disclosure for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a definition, explanation of patterns, parameter descriptions, and examples. It is front-loaded with purpose and uses bullet-like formatting for patterns. Every sentence adds value; no redundancy. Concise yet comprehensive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, no annotations, and a large sibling list), the description provides sufficient context. It explains the musical role, track placement, pattern variations, and parameter usage. The output schema exists but is not described, which is acceptable. The description is complete for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by explaining the pattern options in detail, providing defaults and ranges for velocity, octave, bars_per_chord, and track_index. However, parameters start_beat and unit_index are not mentioned in the description. The examples illustrate usage for progression. Strong coverage for most parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a counter-melody from a chord progression. It distinguishes itself from similar tools by placing it in a quintet of harmonic tools and specifying track placement to avoid clashes with melody. The verb 'create' and resource 'counter_melody' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use: as part of a harmonic quintet and on a specific track. It explains the role of the counter-melody relative to melody and bass. However, it does not explicitly state when not to use or list alternatives, but the quintet positioning and pattern descriptions imply usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_counterpointA

Generate a counter-melody in contrary motion to existing notes.

Reads notes from a melody and creates a counterpoint that moves in the opposite direction: when the melody goes up, the counterpoint goes down, and vice versa. Each note is offset by a fixed interval from the melody's midpoint pitch, then mirrored.

unit_index: Source AU index. track_index: Source note track index. region_index: Source region index. interval: Base interval in semitones between melody and counterpoint (default 7 = fifth). The counterpoint is placed interval semitones below the melody's average pitch, then each note is mirrored around that center. new_unit_index: Target AU index (-1 = create new synth track). new_track_index: Target note track index on the target AU. velocity: Velocity for counterpoint notes (default 0.6, quieter than melody).

Returns source notes read and counterpoint notes created.

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNo
velocityNo
unit_indexYes
track_indexNo
region_indexNo
new_unit_indexNo
new_track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description explains the algorithm, that it reads notes and creates new ones, and returns counts. It does not mention side effects (e.g., non-destructive read) but is otherwise thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: concept overview, then parameter list, then return note. It is concise (about 150 words) and front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers algorithm, parameters, and return values. Missing preconditions (e.g., source track must have notes) and edge cases. Output schema exists but description mentions return structure anyway.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain all 7 parameters. It does so with clear explanations (e.g., interval default and usage, velocity quieter, new_unit_index -1 means new track).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb and resource: 'Generate a counter-melody in contrary motion to existing notes.' It explains the concept and distinguishes from siblings like create_canon or create_fugue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when wanting contrary motion counterpoint but does not explicitly state when to use this vs alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_country_arrangementA

Create a full country arrangement — boom-chick guitar + root-five bass + major pentatonic fiddle lead.

Classic country/Americana — the foundation of American roots music:

  • Track 0: Drums — straight 8th backbeat: kick on 1 and 3, snare on 2 and 4, steady 8th hi-hats. Country drums are straight, not shuffled like blues — the groove comes from the guitar, not the drums.

  • Track 1: Bass — root-five pattern: root on beat 1, fifth on beat 3. The classic country bass — simple, steady, and unmistakable.

  • Track 2: Chords — boom-chick guitar: alternating bass note (beat 1) + chord strum (beat 2), bass note (beat 3) + chord strum (beat 4). Triads, not 7ths — country harmony is cleaner than blues. The boom-chick is the Carter Family/Johnny Cash pattern.

  • Track 3: Lead — major pentatonic (root, 2, 3, 5, 6) with occasional blue notes (b3, b7). Fiddle-style: long sustained notes, fast scale runs, and bends. The crying fiddle quality.

At 120 BPM (default), this is a classic country two-step tempo. At 90 BPM, it's a country ballad. At 140, it's a fast bluegrass breakdown feel.

The I-IV-V progression: I-I-IV-I-V-I-IV-I (8 bars). Simple, direct, and the backbone of country, folk, and Americana.

bpm: Tempo (80-160, default 120 = classic country two-step). bars: Arrangement length (must be multiple of 8, default 8). root: Root note (G is the most common country key — guitar/capo friendly). octave: MIDI octave for bass (2 = G2=43, standard country bass register). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_country_arrangement(bpm=120, root="G", bars=8) create_country_arrangement(bpm=90, root="D", bars=16) # ballad, 2 verses

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoG
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
chord_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It describes the generated arrangement structure and mentions return values ('Returns notes created per track and total'), but does not clarify side effects like overwriting existing data, prerequisites (e.g., existing tracks), or system interactions beyond note creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured, starting with a concise purpose then detailing tracks and parameters. Some redundancy exists (e.g., repeating tempo adjustments), and the level of detail may be excessive for a simple creation tool, but it remains organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 11-parameter complexity and no annotations, the description covers the musical output thoroughly—track roles, progression, tempo suggestions. However, it omits system-level context (e.g., whether it creates new tracks or modifies existing ones) and does not leverage the existing output schema to explain return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden. It explains most parameters (bpm, bars, root, octave, track indices) with specific details like range and defaults. However, velocity, start_beat, and unit_index are not explicitly described, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a full country arrangement — boom-chick guitar + root-five bass + major pentatonic fiddle lead.' It specifies the genre and instrumentation, effectively distinguishing it from sibling genre-specific arrangement tools like create_rock_arrangement and create_blues_arrangement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through genre details but does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance. It assumes the agent will infer from the genre focus, but lacks explicit usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_crescendoA

Apply a crescendo or decrescendo to existing notes in a region.

Gradually changes note velocities from start_velocity to end_velocity across all notes in the region. Useful for building tension or fading out.

unit_index: AU index. track_index: Track index. region_index: Region index (-1 = first region). start_velocity: Starting velocity 0-1 (low = quiet beginning). end_velocity: Ending velocity 0-1 (high = loud end). curve: "linear", "exp" (exponential, starts slow), "log" (logarithmic, starts fast).

Returns number of notes modified and velocity range applied.

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNolinear
unit_indexYes
track_indexYes
end_velocityNo
region_indexNo
start_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description explains that the tool modifies velocities across all notes in a region, gradually from start to end, and returns the number of notes modified and velocity range. This is transparent about the effect. It does not mention potential side effects like overwriting existing velocities or undo behavior, but given no annotations, it provides reasonable behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is around 120 words, front-loaded with purpose and use case, then lists parameters succinctly. No redundant sentences. Slightly longer than minimal, but still efficient. Could be tighter, but earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers the main behavior, parameters, and return values. It lacks discussion of error conditions or prerequisites (e.g., region must exist). Given the complexity (6 params, output schema), it is fairly complete but could mention edge cases. Still well above average.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, valid ranges (e.g., velocities 0-1), and interpretation of special values (e.g., region_index -1). It also describes the curve options and their behavior. This adds essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'apply crescendo or decrescendo' and resource 'existing notes in a region'. It explains the gradual velocity change and contrasts with other velocity tools by focusing on contour. While it doesn't explicitly differentiate from every sibling, the purpose is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides context for use: 'building tension or fading out'. This implies when to use but does not explicitly exclude alternatives or provide when-not-to-use guidance. Could be improved with reference to other velocity tools like apply_velocity_curve, but still helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_cross_rhythmA

Create a cross-rhythm — multiple voices with independent period lengths creating shifting alignment.

Unlike polyrhythm (which divides one bar into n and m equal parts), cross-rhythm gives each voice its own period length in beats. The voices cycle independently, creating continuously shifting alignment patterns that only realign after the LCM of all periods.

African cross-rhythms, Steve Reich, Talking Heads, minimalism.

voices: Comma-separated period lengths per voice. E.g., "5,7,3" creates 3 voices with period 5, 7, and 3 beats respectively. 2-6 voices supported. bars: Total length in bars (1-16). The pattern cycles until bars×4 beats is filled. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. duration: Note duration in beats. base_velocity: Base velocity 0-1. Each voice gets slightly attenuated (voice 0 = full).

Returns total notes created, voice periods, and alignment interval (LCM).

Common cross-rhythms: "5,7" — 5-beat vs 7-beat (African, shifts every 35 beats) "3,4,5" — triple cross-rhythm (minimalism) "4,5,6" — dense shifting pattern "3,5,7" — prime cross-rhythm (longest alignment cycle = 105 beats)

Example: create_cross_rhythm(voices="5,7", bars=8, track_index=0)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
voicesYes
durationNo
start_beatNo
unit_indexNo
track_indexNo
base_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It details how voices cycle independently, alignment after LCM, output structure (total notes, voice periods, alignment interval), and constraints (2-6 voices, 1-16 bars). It does not mention error handling or side effects, but covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat lengthy but well-structured: starts with definition, contrasts with sibling, explains parameters, lists common cross-rhythms, and provides an example. Every sentence adds value, though some text (e.g., lengthy list of common rhythms) could be more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers the concept, parameter details, usage examples, and return value. It implicitly references sibling tools and provides sufficient context for an agent to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, which it does excellently. It explains the 'voices' parameter format (comma-separated periods, 2-6 voices), 'bars' as total length in beats, and other parameters like 'base_velocity' (attenuation per voice). It also describes the return value, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines what the tool does: 'Create a cross-rhythm — multiple voices with independent period lengths creating shifting alignment.' It distinguishes cross-rhythm from polyrhythm, provides musical context (African cross-rhythms, Steve Reich), and gives examples, making the purpose highly specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts cross-rhythm with polyrhythm, guiding when to use this tool versus a sibling (e.g., 'Unlike polyrhythm...'). It includes common cross-rhythm patterns and an example call, providing clear usage context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_dembowA

Create a dembow rhythm — the foundational beat of reggaeton and Latin dancehall.

The dembow is a 3-3-2 syncopated pattern that drives virtually all reggaeton and Latin dancehall music. It derives from the "Dembow" riddim by Bobby Dixon (1990, Jamaica) and was popularized in Puerto Rico. The pattern creates a distinctive galloping feel through its uneven grouping of 3+3+2 within a 4/4 bar. Every reggaeton track from Daddy Yankee's "Gasolina" to Bad Bunny's "Tití Me Preguntó" is built on this rhythm.

dembow_type: "classic" — Classic reggaeton dembow. Kick on 1 and 3, snare on 3.5, 4.5, 5.5 (the 3-3-2 gallop). 1-bar cycle. "dancehall" — Dancehall variant. Sparser, kick on 1 and 3, snare on 3.5 and 4.5. Less gallop, more pulse. "trap_latino" — Latin trap variant. Kick on 1, 3.5, and 4.75 (syncopated), snare on 2.5 and 4.5. More modern, less rigid. "perreo" — Perreo (old-school reggaeton). Denser snare pattern with ghost hits on 2.75 and 6.75. Rougher, underground feel. "urbano" — Urbano latino (modern fusion). Kick on 1, 3, 4.75, snare on 3.5, 4.5, 5.5. Blends reggaeton with trap.

bars: Pattern length (1-16, 1 = one bar cycle). kick_pitch: MIDI pitch for kick (36 = C1, acoustic bass drum). snare_pitch: MIDI pitch for snare (40 = E1, electronic snare). velocity: Base velocity 0-1. Ghost hits -0.2, main hits +0.05.

Returns notes created, dembow type, and stroke breakdown.

Example: create_dembow(dembow_type="classic", track_index=0) create_dembow(dembow_type="trap_latino", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
kick_pitchNo
start_beatNo
unit_indexNo
dembow_typeNoclassic
snare_pitchNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the dembow pattern and parameter effects but does not disclose side effects like overwriting existing notes, requiring a track index, or potential destructive behavior. The return value is mentioned but not where the notes are placed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description includes a lengthy historical background and cultural references that, while educational, are not essential for tool usage. The parameter listing is well-structured with bullet points, but the overall length could be trimmed. Every sentence does not directly earn its place for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and no annotations, the description covers the most important aspects but misses key details like where the notes are placed (e.g., track_index is required but not explained), and whether the tool replaces existing content. The output schema is indicated but not described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It provides detailed explanations for dembow_type with 5 variants, and explains bars, kick_pitch, snare_pitch, and velocity with real-world context. However, start_beat, unit_index, and track_index are not documented, leaving some parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a dembow rhythm, the foundational beat of reggaeton and Latin dancehall. It explains the pattern origin and structure, and the specific verb 'Create' plus resource 'dembow rhythm' is distinct from sibling tools like create_clave or create_breakbeat.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It describes the tool's purpose and parameters but lacks guidance on context, prerequisites, or exclusions. The agent must infer usage from the name and description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_disco_arrangementA

Create a full disco arrangement — four-on-floor + octave bass + string sustains + wah guitar across 4 tracks.

Classic 70s disco with the signature groove — fundamentally different from house (its descendant):

  • Track 0: Drums — four-on-floor with 16th OPEN hats (not closed 8ths like house). Kick on every quarter, clap on 2 & 4. The 16th-note open hi-hat pattern is the disco signature — busier and more open than house's closed 8th hats. The groove that launched dance music.

  • Track 1: Bass — SYNCOPATED OCTAVE bass: the "good times" bass line. Root on beat 1, then syncopated octave jumps on the "and" of beats 2 and 4. Not off-beat 8ths like house, not arpeggiated like synthwave — it's a melodic bass line with octave leaps. The bass IS the hook in disco.

  • Track 2: Strings — sustained chord pads with octave doubling. Full bar sustain, lush and smooth. The orchestral element that separates disco from house — house uses stabs, disco uses sustained strings. Minor or major triad depending on chord.

  • Track 3: Guitar — wah-wah chops: 16th-note rhythmic scratching with accent pattern. Root + minor seventh voicing (funk-influenced). The "chukka-chukka" that drives the groove. Different from reggae skank (off-beat only) — disco guitar plays ALL 16ths with accents.

Uses I-vi-IV-V progression (G-Em-C-D in G major) — the classic disco four-chord loop. Different from house (minor vamp), pop (I-V-vi-IV), rock (I-IV-V). Disco's progression is major-key and optimistic — the "feel good" sound of the 70s.

At 120 BPM (default), this creates the classic disco groove — the tempo that defined the genre. The syncopated octave bass and 16th open hats are the fundamental differences from all 13 other arrangements: house has off-beat bass stabs with closed 8th hats, disco has melodic octave bass with 16th open hats.

bpm: Tempo (110-130, default 120 = classic disco). bars: Arrangement length (4-16, default 8). Must be multiple of 4. root: Root note (G is a classic disco key — G major). octave: MIDI octave for bass (2 = G2=43, standard disco bass register). unit_index: AU index with note tracks. drum_track / bass_track / string_track / guitar_track: Track indices.

Returns notes created per track and total.

Example: create_disco_arrangement(bpm=120, root="G", bars=8) create_disco_arrangement(bpm=115, root="C", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoG
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
guitar_trackNo
string_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It exhaustively explains the generated output: tracks, rhythmic patterns, chord progression, tempo, and expected note densities. It also mentions the return format (notes created per track and total).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with headers and bullet points. It is informative and avoids fluff, though some repetition (e.g., tempo reference appears twice) could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, no annotations), the description is remarkably thorough. It covers the arrangement's musical content, parameter roles, and output format. The existence of an output schema further supports completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates for many parameters (bpm, bars, root, octave, track indices) but leaves out velocity, start_beat, and unit_index. Partial coverage prevents a higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a full disco arrangement with four specific tracks, chord progression, and tempo. It distinguishes itself from other arrangement tools by detailing unique disco characteristics and contrasting with house and other genres.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by detailing when to create a disco arrangement versus house or other styles, with explicit comparisons. However, it lacks a succinct statement like 'Use this tool to generate a classic 70s disco arrangement.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_djembe_ensembleA

Create a West African djembe/dunun ensemble — cyclical ostinato with call-and-response.

West African drumming (Mali, Guinea, Senegal) is built on layered cyclical patterns. Three bass drums (dununs) play interlocking ostinato patterns that define the rhythmic foundation. The kenkeni (highest) plays the fastest cycle, the sangban (middle) plays the core pulse, and the dundunba (lowest) plays the slow anchor. A bell (kenken) plays the timeline — the reference pattern all drummers orient to. Two djembes play lead and accompaniment parts: djembe 1 improvises calls and echauffements (heating-up sections), djembe 2 plays a fixed accompaniment (accompagnement) that interlocks with the dununs.

Unlike samba (parade ensemble) or songo (drum kit), West African drumming is cyclical: the accompaniment loops indefinitely while the lead djembe improvises on top. The structure is call-and-response: the lead plays a signal (appel) and the ensemble responds, then the groove continues.

styles (traditional rhythms): "danza" — Malian welcoming rhythm. Kenkeni steady 8ths, sangban pulse on 1+3, dundunba on 2+4. Bell timeline E(3,2,3). Djembe 2 accompagnement: slap-tone-slap-bass. "kuku" — Guinean celebration rhythm. Kenkeni offbeat pattern, sangban syncopated, dundunba sparse. Bell E(7,12). Djembe 2: rolling 16th tone-slaps. "djole" — Sierra Leonean rhythm (originally on sikko drums). Kenkeni 16ths, sangban 3-3-2, dundunba on 1. Bell E(3,2,3). Djembe 2: spaced bass-slap pattern. "doundounba" — The "dance of the strong men" (Guinea). Sangban drives with a dense 16th pattern, dundunba on downbeats, kenkeni sparse. Bell E(3,2,3). Aggressive djembe 2.

bars: Pattern length (4-16, even). style: Rhythm name (danza, kuku, djole, doundounba). velocity: Base velocity (0-1). kenkeni_pitch: Kenkeni (high dunun) MIDI pitch (35 = B0). sangban_pitch: Sangban (mid dunun) MIDI pitch (36 = C1). dundunba_pitch: Dundunba (low dunun) MIDI pitch (38 = D1). djembe1_pitch: Lead djembe MIDI pitch (42 = F#1). djembe2_pitch: Accompaniment djembe MIDI pitch (46 = A#1). bell_pitch: Bell (kenken) timeline MIDI pitch (50 = D2).

Args: bars: Pattern length in bars (4-16, even). style: Rhythm style (danza, kuku, djole, doundounba). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. kenkeni_pitch: Kenkeni MIDI pitch. sangban_pitch: Sangban MIDI pitch. dundunba_pitch: Dundunba MIDI pitch. djembe1_pitch: Lead djembe MIDI pitch. djembe2_pitch: Accompaniment djembe MIDI pitch. bell_pitch: Bell timeline MIDI pitch.

Returns notes created, instrument breakdown, and rhythm info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNodanza
velocityNo
bell_pitchNo
start_beatNo
unit_indexNo
track_indexNo
djembe1_pitchNo
djembe2_pitchNo
kenkeni_pitchNo
sangban_pitchNo
dundunba_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the behavioral burden. It discloses that the accompaniment loops indefinitely, the lead improvises, and the structure is call-and-response. However, it does not explicitly mention whether the tool is destructive (overwrites existing data) or safe, but the creative context implies it adds new material.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with paragraphs, bullet-pointed style details, and a clear parameter list. It front-loads the overall purpose and structure, then details styles and parameters. A slightly more concise version could improve readability, but given the complexity, it is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, multiple styles, musical context), the description is complete. It explains the instrument roles, style differences, and return values ('notes created, instrument breakdown, and rhythm info'). The output schema exists, so return value explanation is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by listing all 12 parameters with detailed explanations, including purpose, defaults, and pitch values. It even enumerates the four style options with rhythmic characteristics. This makes the parameters fully understandable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a West African djembe/dunun ensemble with cyclical ostinato and call-and-response. It uses specific verbs ('create') and resources ('djembe ensemble'), and distinguishes itself from related tools like samba and songo by contrasting the cyclical vs. linear structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use this tool (for West African drumming) and contrasts it with samba (parade ensemble) and songo (drum kit), providing clear alternatives. It also describes the intended musical context and structure.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_dnb_arrangementA

Create a full drum & bass arrangement — drums + bass + pad across 3 tracks in one call.

This is the first multi-track genre arrangement tool. Instead of creating individual patterns, it generates a complete DnB section with all elements locked together:

  • Track 0: Drums — chopped Amen-style breakbeat with kick, snare, hats, ghost notes

  • Track 1: Bass — Reese-style bassline with sustained notes and syncopated stabs

  • Track 2: Pad — sustained minor chord pad that creates harmonic foundation

The arrangement is tempo-aware: at 174 BPM (default), the patterns are optimized for the classic 170-180 DnB feel. The bass and drums lock rhythmically — bass sustains when drums break, stabs when drums roll.

bpm: Tempo (160-185, default 174 = classic DnB). bars: Arrangement length (4-32, default 8 = typical section). root: Root note for bass and pad. octave: MIDI octave for bass (2 = C2=36). unit_index: AU index with note tracks. drum_track: Track index for drums. bass_track: Track index for bass. pad_track: Track index for pad. velocity: Base velocity 0-1.

Returns notes created per track and total.

Example: create_dnb_arrangement(bpm=174, root="A", bars=8) create_dnb_arrangement(bpm=170, root="F#", bars=16, drum_track=2, bass_track=3, pad_track=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoA
octaveNo
velocityNo
pad_trackNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: tempo-aware, rhythmic locking, track assignments, return value. Lacks details on whether it overwrites existing notes or creates missing tracks. With no annotations, description carries full burden; mostly adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded purpose, bullet points, parameter list, and examples. Slightly verbose but each section adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete description for a complex multi-track arrangement tool. Covers behavior, parameter semantics, and examples. Output schema handles return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Provides detailed explanations for all 10 parameters (ranges, defaults, meanings) despite 0% schema description coverage. Fully compensates with clear semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it creates a full drum & bass arrangement across 3 tracks. Uses specific verb-resource combination, distinct from sibling genre-specific arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames as multi-track alternative to creating individual patterns, with genre-specific guidance. Provides examples and notes when to use (DnB genre) vs. other arrangement tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_downtempo_arrangementA

Create a downtempo/trip-hop arrangement — 85 BPM Bristol sound.

Downtempo/trip-hop emerged from Bristol, UK (early 1990s) — a fusion of hip-hop breaks, dub bass, atmospheric samples, and melancholic vocals. Key characteristics:

  • 80-90 BPM, laid-back, heavy groove

  • Boom-bap drums with swing, vinyl crackle aesthetic

  • Deep, melodic sub-bass with long notes

  • Minor key, dark/jazzy harmony (m7, m9, half-diminished)

  • Atmospheric pads, Rhodes piano, sparse melodies

  • Sample-based, cinematic, nocturnal mood

Creates 5 tracks:

  1. Drums (track_index): Boom-bap pattern — kick on 1 & 3, snare on 2 & 4, swung hats, ghost notes, occasional fills

  2. Bass (track_index+1): Deep sub-bass with long sustained notes, melodic movement, octave drops

  3. Chords (track_index+2): Minor 7th/9th Rhodes-style chords, sparse, on beat 1 of every 2 bars

  4. Melody (track_index+3): Sparse, melancholic minor key melody with wide intervals and long rests

  5. Atmosphere (track_index+4): Sustained pad notes, root and fifth, very low velocity, cinematic texture

Default key: D minor (classic trip-hop key — Portishead, Massive Attack).

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoD
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It details output structure (5 tracks) and musical style, but does not disclose side effects (e.g., where tracks are added, any overwrite behavior, or project state dependencies).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized (action, genre context, track breakdown) but includes verbose historical and musical exposition that may not be necessary for tool invocation. Could be trimmed without losing core guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters with 0% schema coverage and no annotations, the description should provide more actionable parameter guidance. It explains the genre and track roles well but lacks details on how to adjust parameters to customize the arrangement. Existence of output schema is noted but not described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description only clarifies bpm (85 default) and key_root (D minor), and indirectly implies track_index from track descriptions. Parameters like velocity, start_beat, unit_index, and bars are not explained, leaving significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear action verb and specific genre ('Create a downtempo/trip-hop arrangement — 85 BPM Bristol sound'), and the detailed characteristics and track list distinguish it from sibling genre tools like create_lofi_arrangement or create_ambient_arrangement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through genre specification and musical characteristics, but does not explicitly state when not to use (e.g., against other genres) or name alternatives among the many sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_drum_fillA

Create a drum fill or transition pattern — one call replaces 10-30 note creations.

Generates rhythmic fills between song sections with increasing/decreasing density. Useful for transitions: verse→chorus, breakdown→drop, outro buildup.

fill_type: Type of fill:

  • "build" — density increases toward end (leading into a drop/chorus)

  • "break" — density decreases (winding down after a section)

  • "roll" — sustained snare/tom roll with accents

  • "crash" — crash + sparse hits for impact

  • "tom" — descending tom pattern

bars: Length in bars (1-4). Each bar = 4 beats = 16 sixteenth steps. start_beat: Position in beats where the fill begins. density: Note density — "sparse", "medium", "dense".

unit_index: AU index with a note track (-1 = find first AU with note tracks).

Returns notes created per lane and total.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
densityNomedium
fill_typeNobuild
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions that the tool 'Generates rhythmic fills... with increasing/decreasing density' and lists fill types with behaviors (e.g., 'build' increases density). It also explains the unit_index default. However, it does not disclose whether existing notes are overwritten or if the tool is purely additive, leaving some ambiguity about side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, a separate list of fill types, and parameter explanations. It is informative without being overly verbose, though some information (like the bar breakdown) could be integrated more efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, parameter details, and return value ('Returns notes created per lane and total'). However, it lacks explicit prerequisites (e.g., requiring a drum track or empty note area) and does not fully specify behavior when the target track already contains notes. Given the output schema exists, the description is largely complete but could add more context about the required state of the project.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (only titles), so the description fully compensates by explaining each parameter: fill_type with enumerated options, bars (1-4, each bar = 4 beats = 16 steps), start_beat, density (sparse/medium/dense), unit_index (default -1 finds first AU with note tracks). This provides complete semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a drum fill or transition pattern' with a specific verb (create) and resource. It explains that one call replaces 10-30 note creations and provides fill types. This distinguishes it from sibling tools like create_drum_pattern and create_break by focusing on fills and transitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: 'Useful for transitions: verse→chorus, breakdown→drop, outro buildup.' This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like create_drum_pattern.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_drum_patternA

Create a drum beat from compact step-sequencer notation — one call replaces 10-20 note creations.

pattern: JSON object with drum lanes, each lane is a string where each char is a 16th-note step:

  • 'x' = hit (velocity 0.9)

  • 'o' = soft hit (velocity 0.5)

  • '.' = rest

  • 'X' = accent (velocity 1.0)

Lanes: kick, snare, hihat, clap, perc (each optional).

Example (4/4 house beat): '{"kick":"x...x...x...x...","snare":"....x.......x...","hihat":"....o...o...o..."}'

unit_index: AU index with a note track (-1 = find first AU with note tracks).

Returns the number of notes created per lane.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternYes
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the step-sequencer notation format, default unit_index behavior, and return value (notes created per lane). However, it does not state whether it is destructive or additive, or prerequisites like needing a drum track.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an opening sentence, parameter details, notation legend, and example. It is front-loaded with purpose. Only minor redundancy (the example could be shorter).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of creating a drum pattern, the description covers all essential aspects: input format, notation, unit_index, and output. The output schema exists and the description mentions return value sufficient for the agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully explains the pattern parameter (JSON object, lanes, step characters) and unit_index parameter (default -1, finds first AU with note tracks). This adds significant meaning beyond the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('create') and resource ('drum pattern') with unique compact notation. It clearly states it replaces 10-20 note creations, distinguishing it from siblings like create_drum_fill or create_boom_bap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for efficient drum pattern creation but does not explicitly state when to use this tool versus alternatives such as create_drum_fill or create_four_on_floor. No when-not or alternative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_drum_soloA

Create a genre-specific drum solo with rudimental vocabulary.

Generates a complete drum solo using vocabulary appropriate to the chosen style. Unlike create_drum_fill (short transition), this tool creates a full multi-bar solo with phrasing, build-ups, climax, and genre-specific rudimental patterns:

  • rock: Thunderous 16th-note double kick patterns, crash accents, tom fills, snare ghost notes, building intensity. John Bonham, Neil Peart, Danny Carey.

  • jazz: Brushes + sticks, comping patterns, ride bell, press rolls, polyrhythmic phrasing, trading 4s feel. Max Roach, Elvin Jones, Tony Williams.

  • funk: Ghost-note heavy 16th-note grooves, hi-hat splashes, pocket fills, James Brown/Bootsy aesthetic. Clyde Stubblefield, Jabo Starks, Bernard Purdie.

  • latin: Cascara, mambo bell, timbale fills, clave-based phrasing, 6/8 feel options. Tito Puente, Mongo Santamaria.

  • marching: Rudimental solo — paradiddles, flams, drags, roll building, double-stroke open rolls. DCI, snare line vocabulary.

solo_type: rock | jazz | funk | latin | marching bars: Solo length (2-16, default 4) velocity: Base velocity 0-1 (drum solos are loud, default 0.9) seed: PRNG seed for reproducibility

Returns notes created and solo characteristics.

Example: create_drum_solo(solo_type="rock", bars=4) create_drum_solo(solo_type="jazz", bars=8) create_drum_solo(solo_type="marching", bars=4, seed=100)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
seedNo
velocityNo
solo_typeNorock
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that the tool generates a complete drum solo with specific structural elements and returns notes and solo characteristics. However, it does not explicitly state whether it modifies existing data or creates new content, and does not mention any potential side effects. This is good but not perfect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence, bullet-pointed genre details, parameter list, and examples. Each section adds value without redundancy. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, no annotations, output schema exists), the description covers the core functionality, parameter semantics, and return description well. Minor omission: the standard parameters unit_index and track_index are not explained, which could affect completeness for an agent unfamiliar with the system.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds significant value by documenting parameters: solo_type (with genre-specific details), bars (range 2-16, default 4), velocity (0-1, default 0.9, with note on loudness), and seed (PRNG). It also provides examples. However, parameters start_beat, unit_index, and track_index are not described in the text, which is a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a genre-specific drum solo with rudimental vocabulary.' It distinguishes itself from the sibling 'create_drum_fill' by specifying that it creates a full multi-bar solo with phrasing, build-ups, climax, and genre-specific patterns. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly differentiates this tool from 'create_drum_fill' (short transition) and lists five distinct genres (rock, jazz, funk, latin, marching) with detailed characteristics. It provides clear guidance on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_dubstep_arrangementA

Create a full dubstep arrangement — half-time drums + wobble bass + lead arp across 3 tracks.

Dubstep with all elements locked in half-time feel:

  • Track 0: Drums — half-time at 140 BPM (feels like 70): kick on 1, snare on 3, with percussive fills and ghost notes. The signature dubstep swing.

  • Track 1: Bass — wobble bass: sustained sub notes with rhythmic pitch shifts between root and octave/fifth, creating the "wub-wub" that defines the genre. Cutoff-sweep style pitch modulation via note offsets.

  • Track 2: Lead — minor arpeggio that runs through the arrangement, atmospheric and dark, complementing the wobble bass.

At 140 BPM (default), half-time means the groove feels at 70 BPM — kick on beat 1, snare on beat 3 of each bar. This is the fundamental difference from all other electronic arrangements: the half-time feel creates the heavy, swinging groove.

bpm: Tempo (135-150, default 140 = classic dubstep). bars: Arrangement length (4-16, default 8). root: Root note (G is a classic dubstep key). octave: MIDI octave for wobble bass (1 = C1=24, sub-bass territory). unit_index: AU index with note tracks. drum_track / bass_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_dubstep_arrangement(bpm=140, root="G", bars=8) create_dubstep_arrangement(bpm=145, root="F", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoG
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes track behavior, rhythmic structure, and return value (notes per track and total). No annotations provided, so description carries full burden. Discloses half-time feel and pitch modulation but does not mention potential side effects like overwriting existing tracks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose, then details, then parameter list, then examples. Some repetition of BPM explanation. Well-organized but slightly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers musical intent and main parameters with examples. Lacks explanation for velocity, start_beat, unit_index. No output schema but describes return value. Adequate for a genre arranger but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. Explains bpm, bars, root, octave, and track indices with musical rationale. Misses velocity, start_beat, unit_index. Provides examples. Partially compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Create a full dubstep arrangement' with specific components (half-time drums, wobble bass, lead arp). Distinguishes from sibling genre arrangers by specifying dubstep and half-time feel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use this tool (creating dubstep arrangement with half-time feel). Implicitly contrasts with other electronic arrangements by emphasizing the genre-specific rhythm. Lacks explicit exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_edm_arrangementB

Create a full EDM arrangement — festival/mainstage 4-on-floor + supersaw + pluck + lead.

Electronic Dance Music — festival/mainstage sound:

  • Track 0: Drums — 4-on-the-floor kick (every beat), claps on 2+4, open hats on offbeats, 16th closed hats for energy. Riser/snare buildup at end of 8-bar phrases.

  • Track 1: Bass — offbeat bass (root on the "and" of each beat). Sub-bass frequency, driving, syncopated.

  • Track 2: Supersaw synth — wide chord stabs on beats 1 and 3. Root position triads with spread voicings. The "wall of sound" — mainstage synth.

  • Track 3: Lead synth — melody using scale degrees. Arpeggiated pattern with rhythmic repetition. The "hook".

F minor default — the most common EDM key (nice for both male and female vocals, sits well in club systems). 128 BPM (house/EDM standard). vi-IV-I-V progression (Fm-Db-Ab-Eb) — the "pop punk" progression that drives most festival anthems.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
synth_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It details the output musical content but fails to explain side effects (e.g., whether it creates new tracks, modifies existing project, or requirements). This leaves ambiguity about tool invocation consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose but includes verbose musical details (exact track specifications, chord progression theory). While detailed, it could be more concise without losing essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, 0 required, no schema descriptions), the description is incomplete. It does not explain how parameters map to output, what the output schema contains, or whether the arrangement is additive or destructive. Agents lack sufficient context to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add parameter meaning. It only mentions defaults (128 BPM, F minor) but does not explain how other parameters (bars, octave, velocity, etc.) affect the arrangement. Agents cannot infer parameter impact without additional context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full EDM festival/mainstage arrangement with specific elements (4-on-floor, supersaw, pluck, lead). The verb 'Create' and resource 'EDM arrangement' are precise, and it distinguishes from sibling genre-specific arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for EDM arrangement creation but does not explicitly state when to use this tool versus alternatives (e.g., other genre arrangement tools). No exclusion criteria or when-not-to-use advice is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_electronic_bassA

Create an electronic bassline pattern — genre-specific bass for dance music.

Electronic basslines are fundamentally different from melodic basslines: they're rhythmic engines that lock with the kick drum. Each genre has a characteristic bass technique that defines its sound.

bass_type: "house_offbeat" — House off-beat bass: sustained notes on the "&" of each beat (between kicks). The classic house bass that creates the "untz-untz-untz" feel. Frankie Knuckles / Detroit house. "techno_sub" — Techno sub-bass: one long sustained root per bar, minimal. Pure low-end energy. Berlin techno / Marcel Dettmann. "dnb_reese" — DnB Reese bass: sustained note on beat 1, then syncopated stabs on the "e" and "a" of beats 2-4. Dark, detuned. Noisia. "dubstep_wobble" — Dubstep wobble: quarters on 1+3, wub pattern on 2+4 with repeated 16ths and fifth movement. Skrillex / Excision. "acid_303" — Acid 303: fast 16ths alternating root/octave with fifth drops. TB-303 squelch. Phuture / Hardfloor. "garage_2step" — UK garage 2-step bass: notes on 1 and 2.66, ghost on 3.5. Bouncy, syncopated. MJ Cole / Disclosure.

bars: Pattern length (1-16). root: Root note name (C, C#, D, etc. or flats Db, Eb). octave: MIDI octave (2 = C2=36). velocity: Base velocity 0-1.

Returns notes created, bass type, and pitch info.

Example: create_electronic_bass(bass_type="house_offbeat", root="C", track_index=0) create_electronic_bass(bass_type="dnb_reese", root="A", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
octaveNo
velocityNo
bass_typeNohouse_offbeat
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses return values ('notes created, bass type, and pitch info') but lacks information on side effects, permissions, or safety profile. No annotations are provided, so the description partially fulfills the transparency burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose, background, parameter details, return info, and examples. It is slightly verbose due to the detailed bass_type descriptions, but those provide valuable context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the purpose and core parameters well, but missing explanations for some schema parameters and lacks guidance on how this tool relates to sibling bass creation tools. An output schema exists but is not analyzed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The bass_type parameter is explained in exceptional detail with musical context, but other parameters (bars, root, octave, velocity) receive only brief description, and parameters like start_beat, unit_index, and track_index are not described at all despite being present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates an electronic bassline pattern, explicitly distinguishes from melodic basslines, and provides genre-specific options that differentiate it from sibling tools like create_bassline or create_walking_bass.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for electronic dance music genres through the bass_type examples, but does not explicitly state when to use this tool versus alternatives or provide when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_euclidean_rhythmA

Create a Euclidean rhythm — distributes k onsets across n steps as evenly as possible.

The Euclidean algorithm (BJK algorithm) generates most of the world's classic rhythms: E(3,8) = tresillo (Cuban, Arabic, 3-3-2) E(5,8) = cinquillo (Cuban) E(7,16) = samba, rumba E(7,12) = bembé (West African) E(2,5) = tresillo variant E(4,9) = Aksak (Balkan) E(3,7) = Persian/Arabic

onsets: Number of hits (k). 1-32. steps: Total number of steps (n). 2-64. Must be >= onsets. rotation: Rotate the pattern clockwise by N steps. 0 = no rotation. bars: Number of bars to repeat. Each step = one (4/steps)th of a bar. pitch: MIDI pitch for all hits. velocity: Velocity 0-1. Accents (first onset of each group) get +0.15. duration: Note duration in beats.

Returns notes created, pattern as binary string (1=hit, 0=rest), and Euclidean notation E(k,n).

Example: create_euclidean_rhythm(onsets=3, steps=8, track_index=0) # tresillo create_euclidean_rhythm(onsets=7, steps=16, pitch=38, track_index=1) # samba

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
pitchNo
stepsNo
onsetsNo
durationNo
rotationNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes algorithm, parameter effects (e.g., velocity accent), and return values. Lacks disclosure of error handling or edge cases, but overall covers main behavioral aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and algorithm. Well-structured with examples, parameter list, and return description. Slightly lengthy but information-dense; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers algorithm, parameter constraints, return format, and examples. Output schema exists but its content is not detailed here. Missing some parameter descriptions and potential error scenarios, but overall complete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. Description explains 7 of 10 parameters (onsets, steps, rotation, bars, pitch, velocity, duration) with ranges. Missing descriptions for start_beat, unit_index, track_index. Provides significant added meaning for most parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates a Euclidean rhythm, explaining the algorithm and listing classic rhythms. It uniquely distinguishes from siblings like create_breakbeat or create_polyrhythm by specifying a precise mathematical method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides examples of when to use specific Euclidean patterns but lacks explicit guidance on when to prefer this tool over alternatives like create_samba_pattern or create_breakbeat. Usage context is implied through examples rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_filter_sweepA

Create a filter sweep on a Vaporisateur instrument's cutoff parameter with smart defaults.

The most common transition technique in EDM/techno/house. Sweeps the filter cutoff from closed to open (build-up) or open to closed (breakdown). Optionally boosts resonance during the sweep for that classic "talking filter" effect. Uses exponential curve by default (matches how human hearing perceives frequency changes).

unit_index: AU index with a Vaporisateur instrument. direction: "open" (low→high, build-up) or "close" (high→low, breakdown). start_beat: Start position in beats. duration_beats: Sweep length in beats (default 8 = 2 bars). start_cutoff: Starting cutoff value 0.0-1.0 (default: 0.05 for open, 0.85 for close). end_cutoff: Ending cutoff value 0.0-1.0 (default: 0.9 for open, 0.05 for close). resonance: Fixed resonance value 0.0-1.0 during sweep. Default: current value unchanged. resonance_boost: If True, automates resonance from current to +0.3 at sweep midpoint, then back down — classic filter sweep "whistle" effect. curve: "exp" (exponential, default — natural for filters), "linear", "log". steps: Number of automation points (default 32 = smooth).

Returns events created, sweep config, and a preview of the curve.

Examples: create_filter_sweep(unit_index=0, direction="open", duration_beats=16) → 16-bar filter open from 0.05 to 0.9, exp curve, resonance boost at midpoint create_filter_sweep(unit_index=2, direction="close", duration_beats=4, resonance_boost=False) → Quick 4-beat filter close, no resonance boost

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNoexp
stepsNo
directionNoopen
resonanceNo
end_cutoffNo
start_beatNo
unit_indexYes
start_cutoffNo
duration_beatsNo
resonance_boostNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description explains key behaviors: exponential curve default, resonance_boost effect, default cutoff values. Could mention if it overwrites existing automation, but overall good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: purpose first, then usage context, then parameter list, then examples. Every sentence adds value, though slightly lengthy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all parameters, includes examples, mentions return value (events, config, preview of curve). Output schema exists but description still provides enough context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description thoroughly explains each parameter with defaults, ranges, and typical usage. Examples demonstrate practical values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Create a filter sweep on a Vaporisateur instrument's cutoff parameter' with specific verb and resource. Distinguishes from sibling tools by focusing on a common EDM transition technique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context for when to use: 'The most common transition technique in EDM/techno/house' and describes build-up vs breakdown. Does not explicitly mention alternatives among siblings, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_flamenco_compasA

Create a Flamenco compás — the cyclical rhythmic foundation of Flamenco.

Flamenco compás is the rhythmic cycle that defines each palo (form). Unlike Western meter (uniform bars), Flamenco uses a 12-beat cycle with accents on specific beats (typically 3, 6, 8, 10, 12). The accents create the characteristic Flamenco feel — a tension between the expected downbeat and where the accents actually fall.

The compás is marked by three layers:

  1. PALMAS SECAS — Sharp, dry handclaps on accented beats. The "skeleton" of the compás. Loud, precise.

  2. PALMAS SORDAS — Muffled handclaps on unaccented beats. The "flesh" — fills the gaps between secas. Softer, cupped hands.

  3. CAJÓN — Peruvian box drum adapted to Flamenco. Plays the bass pulse, usually on beats 1 and the main accents. Resonant, deep.

  4. GOLPE — Table tap / footwork accent. Sharp percussive hits for dramatic moments, often at the end of a compás cycle.

palos (forms): "bulerias" — 12 beats, accents on 12, 3, 6, 8, 10. Fast, festive. The most modern and popular palo. Starts on 12. "solea" — 12 beats, accents on 3, 6, 8, 10, 12. Slow, solemn. The "mother of Flamenco". Deep, expressive. "alegrias" — 12 beats, accents on 3, 6, 12 (lighter), 8, 10. Joyful. From Cádiz. Mid-fast tempo. "siguiriyas" — 12 beats, accents on 3, 6, 8, 11 (asymmetric grouping 3+2+3+2+2). Slow, tragic. The most jondo (deep) palo. "tangos" — 4 beats, accents on 1, 3. Simple 4/4 feel, the most accessible palo. Rhythmic, earthy. "rumba" — 4 beats, accents on 1, 2.5, 3 (syncopated). The most accessible Flamenco-pop form. Gypsy Kings style.

Args: palo: Flamenco form (bulerias, solea, alegrias, seguiriyas, tangos, rumba). cycles: Number of compás cycles (1-16). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. palmas_secas_pitch: Palmas secas (sharp clap) MIDI pitch (39 = D#1). palmas_sordas_pitch: Palmas sordas (muffled clap) MIDI pitch (42 = F#1). cajon_pitch: Cajón (box drum) MIDI pitch (36 = C1). golpe_pitch: Golpe (tap) MIDI pitch (50 = D2).

Returns notes created, instrument breakdown, accent positions, and palo info.

ParametersJSON Schema
NameRequiredDescriptionDefault
paloNobulerias
cyclesNo
velocityNo
start_beatNo
unit_indexNo
cajon_pitchNo
golpe_pitchNo
track_indexNo
palmas_secas_pitchNo
palmas_sordas_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully convey behavioral traits. It explains the creation of four layers but omits whether it overwrites existing notes, requires specific track types, or has side effects. Details like 'returns notes created' hint at behavior but are insufficient for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headers and bullet points, but the educational introduction about Flamenco, while valuable, adds length. Each section serves a purpose, but some redundancy could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, no annotations, and an output schema, the description is fairly complete—explains the rhythmic concept, lists parameters, and mentions return values. However, it lacks guidance on how the compás integrates with existing tracks (track_index, unit_index) and the impact on existing notes, leaving some context gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by listing all parameters with brief descriptions, defaults, and some musical context (e.g., pitch names). However, unit_index and track_index lack clear explanation of their roles, and the description could better clarify parameter interactions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a Flamenco compás, the rhythmic foundation, and distinguishes it from Western meter. It lists palos with beat patterns, making the purpose highly specific and differentiated from sibling creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides rich context about Flamenco but does not explicitly state when to use this tool vs alternatives (e.g., create_clave, create_samba_pattern). No 'when not to use' guidance, leaving the agent to infer usage from the specialized content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_four_on_floorA

Create a four-on-the-floor pattern — the foundational beat of house, techno, and disco.

Four-on-the-floor: kick drum on every quarter note (beats 1, 2, 3, 4). This is the pulse that defined dance music from disco (1970s) through Chicago house (1980s) to Berlin techno and beyond. The variation comes from what happens BETWEEN the kicks: off-beat hi-hats, claps on 2+4, percussion, and swing.

floor_type: "classic_house" — Chicago/Detroit house: kick on every quarter, open hat on off-beats (the "&" of each beat), clap on 2 and 4. The Frankie Knuckles / Roland TR-909 sound. 1-bar cycle. "deep_house" — Deep house: kick on quarters, shuffled hats, rimshot on 2/4, sparse percussion on the "e" and "a". Soulful swing. Larry Heard / Kerri Chandler style. "techno" — Detroit/Berlin techno: relentless kick on quarters, 16th hats, industrial clap on 2+4, metallic percussion on off-beats. Driving, minimal. Jeff Mills / Surgeson. "disco" — 70s disco: kick on quarters, open hat on off-beats, tambourine 16ths, conga fills. Giorgio Moroder / Donna Summer "I Feel Love" feel. "tech_house" — Tech house fusion: kick on quarters, swung hats, clap on 2/4, occasional vocal-style percussion stabs. Groovy but driving. Solardo / Fisher style.

bars: Pattern length (1-16, 1 = one bar cycle). kick_pitch: MIDI pitch for kick (36 = C1). hat_pitch: MIDI pitch for closed hi-hat (42 = F#1). open_hat_pitch: MIDI pitch for open hi-hat (46 = A#1). clap_pitch: MIDI pitch for clap (39 = D#1). perc_pitch: MIDI pitch for percussion (75 = high wood block / rim). velocity: Base velocity 0-1. Claps -0.05, hats -0.15, open hats -0.1, ghost -0.3.

Returns notes created, floor type, and stroke breakdown.

Example: create_four_on_floor(floor_type="classic_house", track_index=0) create_four_on_floor(floor_type="techno", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
hat_pitchNo
clap_pitchNo
floor_typeNoclassic_house
kick_pitchNo
perc_pitchNo
start_beatNo
unit_indexNo
track_indexNo
open_hat_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It explains what the tool does, the pattern structure, and floor_type variations. It mentions return values (notes created, floor type, stroke breakdown). Lacks detail on side effects or authentication, but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: purpose, background, parameter explanations, and example calls. Could be slightly more concise, but all information is necessary and ordered logically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and presence of output schema, the description covers tool purpose, all parameters with defaults, examples, and return description. It is comprehensive and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description adds all parameter meaning. It explains each parameter (floor_type, bars, kick_pitch, etc.) with defaults and examples. Adds musical context beyond parameter names, fulfilling the requirement completely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a 'four-on-the-floor pattern' and defines it explicitly. It lists five distinct floor types with musical context, differentiating from other drum pattern tools. The verb-object relationship is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (foundational beats for house, techno, disco). It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to infer appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_fugatoA

Create a fugato — a fugal passage with subject entries and imitation.

A fugato is a fugal section (not a full fugue) that features subject entries in imitation: the subject is stated, then answered at a different pitch level, with optional countersubject and episodic material between entries. This is the building block of fugue writing — Bach, Handel, Shostakovich fugato passages.

Unlike create_voice_exchange (transforms existing notes between tracks), fugato generates the entire fugal texture from scratch:

  • Subject: the main theme (custom or auto-generated)

  • Answer: subject restated at answer_interval (real or tonal)

  • Countersubject: a counter-melody against the answer

  • Episode: connecting material between entries (sequenced motives)

Answer modes: real — exact transposition of the subject tonal — adjusted to stay within the key (5th scaled down)

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, etc.). subject_notes: Custom subject as JSON array of [pitch_offset, duration_beats]. If empty, auto-generates a subject. pitch_offset is semitones from root. Example: [[0, 0.5], [2, 0.5], [5, 1.0], [4, 0.5], [2, 0.5], [0, 1.0]] bars: Total length in bars (4-16). octave: Starting MIDI octave (2-6). voices: Number of voices (2-4). answer_interval: Transposition interval for the answer in semitones. Default 7 = perfect fifth (standard fugue answer). answer_mode: Answer type (real or tonal). include_countersubject: If True, generates a countersubject. countersubject_interval: Starting interval of countersubject from answer pitch (semitones, can be negative). include_episode: If True, generates episodic material between entries. episode_bars: Length of episode sections in bars (1-4). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, subject preview, voice entries, and fugato structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
scaleNominor
octaveNo
voicesNo
velocityNo
start_beatNo
unit_indexNo
answer_modeNoreal
track_indexNo
episode_barsNo
subject_notesNo
answer_intervalNo
include_episodeNo
include_countersubjectNo
countersubject_intervalNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the generation process (subject, answer, countersubject, episode) and answer modes (real/tonal). It does not mention prerequisites (e.g., whether a track must exist) or side effects, but covers the core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a definition, then a differentiation, followed by a clear parameter list. It is somewhat lengthy but appropriate for a complex tool; each section earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 16 parameters, no schema descriptions, and an output schema, the description covers the output (notes, preview, structure). It lacks information about error handling, prerequisites, or track setup, but overall is fairly complete for a creative tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates thoroughly. It explains every parameter in detail, including types, defaults, an example for subject_notes, and the meaning of answer modes. This adds significant value beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool creates a 'fugato' and defines it as a fugal passage with subject entries and imitation. It distinguishes itself from a sibling tool (create_voice_exchange) by noting that fugato generates entirely new texture rather than transforming existing notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with create_voice_exchange, providing clear context on when to use this tool. However, it does not explicitly state when not to use it or list alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_fugueA

Create a fugue — polyphonic composition with subject, answer, and countersubject.

The most complex contrapuntal form. A subject (main theme) is stated in one voice, then imitated in others with a tonal or real answer. Optional countersubject provides contrasting counterpoint. Stretto mode overlaps voice entries for climactic density. Unlike create_canon (strict imitation), a fugue uses tonal answers (adjusted intervals) and independent countersubjects.

subject: Comma-separated MIDI pitches of the fugue subject (e.g. "60,62,64,65"). voices: Number of voices (2-5, default 3). More voices = denser counterpoint. entry_delay_beats: Beats between voice entries (2-8, default 4). answer_type: "tonal" (fifth up, adjusted) or "real" (exact transposition). countersubject: Comma-separated MIDI pitches of countersubject (optional). If empty, no countersubject. Must be same length as subject. key_root: Key root for tonal answer calculation (e.g. "C", "F#", "Bb"). key_mode: "major" or "minor" — affects tonal answer adjustment. note_duration: Note duration as fraction of beat (0-1, default 0.9 = legato). velocity: Base velocity for first voice (0-1, default 0.75). velocity_decay: Velocity reduction per voice (0-0.3, default 0.1). stretto: If true, later voices enter before previous finishes subject. unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the first voice begins.

Returns notes created, voice count, subject length, answer type, stretto status.

ParametersJSON Schema
NameRequiredDescriptionDefault
voicesNo
strettoNo
subjectNo60,62,64,65,64,62,60,57
key_modeNomajor
key_rootNoC
velocityNo
start_beatNo
unit_indexNo
answer_typeNotonal
track_indexNo
note_durationNo
countersubjectNo
velocity_decayNo
entry_delay_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains musical behavior (subject, answer, stretto) and parameter effects but does not disclose operational side effects like whether it overwrites existing notes or requires a pre-existing track. No annotations are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose first, then musical context, sibling comparison, and parameter details. It is efficient, though slightly lengthy due to parameter explanations, which are necessary given no schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers musical concept, parameters, return values, and alternative tool. However, it omits prerequisites (e.g., need for a note track), error conditions, and example usage. Given the complexity, completeness is good but not full.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates fully by explaining all 14 parameters, including defaults, valid ranges (e.g., velocity: 0-1), and constraints (countersubject must match subject length). This adds essential meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a fugue, a specific polyphonic composition, and contrasts it with create_canon, distinguishing it from a sibling tool. The verb 'create' and resource 'fugue' are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with create_canon, explaining when to use a fugue (tonal answers, countersubject) versus strict imitation. However, it does not mention other alternatives or non-use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_full_genre_pipelineA

Create a complete genre track from zero to render-ready in one call.

Full pipeline: setup tracks → arrangement → harmonic layers (optional) → genre mix → mastering chain. One call replaces 5-10 individual tool calls with correct parameters.

Steps performed:

  1. Set BPM to genre-appropriate default

  2. Create a synth track + 4 note tracks

  3. Create regions on all tracks

  4. Call the genre arrangement (rhythm across all tracks)

  5. If progression provided: add harmonic layers (arp + melody on top of genre rhythm; pads/bass skipped since genre already has them)

  6. Apply genre-specific mix (compressor, EQ, saturation, reverb per track)

  7. Apply sidechain (for electronic genres)

  8. Add mastering chain (genre-appropriate LUFS target)

After this call, the project is ready for export_audio / render.

genre: One of: dnb, liquid_dnb, house, trap, techno, dubstep, afrobeat, rock, jazz, pop, funk, reggae, synthwave, trance, disco bpm: Override tempo (None = genre default). bars: Arrangement length (default 8, pop min 16). root: Override key (None = genre default). master_lufs: Mastering target (-14 Spotify, -10 loud, -16 Apple). progression: Chord progression string (e.g. "Am-F-C-G"). If non-empty, adds arp + melody harmonic layers on top of the genre rhythm. Pads and bass are skipped (genre arrangement already has them). Default "" = no harmonic layers (rhythm only). add_counter_melody: If True and progression is set, also adds a counter-melody layer (contrary motion). Default False. add_track_chains: If True, applies genre-appropriate processing chains to each track (drum chain on rhythm tracks, bass chain on bass, instrument chain on melodic). Default False.

Returns complete pipeline status: tracks created, notes per track, effects added, mastering chain, harmonic layers.

Example:

Full DnB track in one call

create_full_genre_pipeline("dnb")

Custom techno

create_full_genre_pipeline("techno", bpm=135, bars=16, master_lufs=-10)

House with harmonic layers

create_full_genre_pipeline("house", progression="Fm-Db-Ab-Eb")

Synthwave with full harmonic quintet

create_full_genre_pipeline("synthwave", progression="Am-F-C-G", add_counter_melody=True)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNo
genreYes
master_lufsNo
progressionNo
add_track_chainsNo
add_counter_melodyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description thoroughly discloses the sequence of operations: setting BPM, creating tracks, arranging, optional harmonic layers, genre mix, sidechain, mastering. It also notes the end state ('ready for export_audio / render'). Lacks details on potential destructive actions or error conditions, but adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a summary, numbered steps, parameter list, return value, and examples. Though lengthy, the information is front-loaded and every sentence serves a purpose. Slightly verbose in the parameter descriptions but necessary due to no schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and schema descriptions, the description fully covers the tool's purpose, parameters, behavior, and output. It addresses the 8 parameters, explains the pipeline, and tells the agent what to expect after invocation. Very complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the tool description provides detailed explanations for all 8 parameters, including defaults, constraints (e.g., 'pop min 16' for bars), and behavior (e.g., 'pads and bass are skipped' when progression is set). Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a complete genre track from zero to render-ready in one call' and lists the step-by-step pipeline. The verb 'create' combined with 'full_genre_pipeline' distinguishes it from sibling tools like create_genre_track or individual arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that one call replaces 5-10 individual tool calls, and provides examples covering various use cases (basic, custom, with harmonic layers). However, it does not explicitly mention when to avoid using it (e.g., for fine-grained control), which would enhance guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_funk_arrangementA

Create a full funk arrangement — funky drummer + slap bass + scratch guitar + horn stabs across 4 tracks.

James Brown / Parliament-Funkadelic style funk — vamp-based, not chord-progression-based:

  • Track 0: Drums — "Funky Drummer" pattern (Clyde Stubblefield, most sampled break in history): syncopated kick with ghost notes, snare with strong ghost accents, hi-hat with 16th-note syncopation. The groove that built hip-hop.

  • Track 1: Bass — slap bass: thumb (root, low) + pluck (octave/fifth, high) alternating, with dead notes (ghost) for percussive attack. The signature Larry Graham technique.

  • Track 2: Guitar — "scratch guitar" / "chank": 16th-note muted strumming on a single chord, with accents on specific 16ths. The rhythmic glue that makes funk tick — Niles Rodgers style.

  • Track 3: Horns — stabs: short, tight horn hits on the "and" of beats, responding to the vocal/instrumental lead. Brown-style section horn hits.

At 100 BPM (default), this creates the classic funk pocket — not too fast, deep in the groove. The vamp (one chord groove, not progression) is the fundamental difference from all other arrangements: pop/rock/jazz change chords, funk stays on one and makes it groove. 16th-note syncopation is the rhythmic DNA — every instrument plays 16ths with different accent patterns.

bpm: Tempo (90-115, default 100 = classic funk pocket). bars: Arrangement length (4-16, default 8). Funk vamps can go long. root: Root note (D is a classic funk key — D minor/D dominant). octave: MIDI octave for bass (2 = D2=38, standard funk bass register). unit_index: AU index with note tracks. drum_track / bass_track / guitar_track / horn_track: Track indices.

Returns notes created per track and total.

Example: create_funk_arrangement(bpm=100, root="D", bars=8) create_funk_arrangement(bpm=108, root="G", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoD
octaveNo
velocityNo
bass_trackNo
drum_trackNo
horn_trackNo
start_beatNo
unit_indexNo
guitar_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool creates MIDI notes on specified tracks with specific patterns, and returns a summary of notes created. It does not mention whether it overwrites existing tracks or layers, nor does it discuss permissions or side effects. Given no annotations, the description provides moderate behavioral context but lacks some details expected for a creative action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose but becomes verbose with historical references (e.g., Clyde Stubblefield, Larry Graham) and extensive musical explanation. While informative, some sentences could be condensed without losing essential guidance for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, no annotations), the description covers the musical concept, parameter meanings (most), and return value. It lacks descriptions for two parameters and assumes familiarity with DAW conventions. Nevertheless, it is sufficiently complete for an agent to understand and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description bears full responsibility for explaining parameters. It describes most parameters (bpm, bars, root, octave, unit_index, track indices) with constraints and musical meaning (e.g., 'classic funk pocket' for 100 BPM). However, it omits 'velocity' and 'start_beat', leaving their semantics unclear. Overall, it adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full funk arrangement' and details the four tracks (drums, bass, guitar, horns). It distinguishes itself from other arrangement tools by emphasizing the vamp-based approach, contrasting with chord-progression-based styles. The verb 'create' and specific resource 'funk arrangement' make the purpose unambiguous and distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that this tool is for funk arrangements and contrasts it with pop/rock/jazz by stating 'vamp-based, not chord-progression-based'. This implicitly tells the agent when to use this tool (for funk) and when not (for other genres). However, it does not explicitly list exclusion criteria or provide alternative tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_future_bass_arrangementA

Create a full future bass arrangement — 4 tracks: drums + bass + chords + lead.

Future bass (Flume, San Holo, Illenium, ODESZA) blends electronic production with melodic/emotional sensibility. Key characteristics:

  • 130-160 BPM, often major key (uplifting feel)

  • Pitching snare rolls before drops (rising pitch + velocity crescendo)

  • Big supersaw chords — wide, detuned, layered

  • Sub-bass under chords, syncopated with kicks

  • Vocal chop aesthetic — short rhythmic melodic fragments

  • Sidechain pumping feel

  • Bright, shimmering, nostalgic

Creates 4 tracks:

  1. Drums (drum_track): Punchy kick on 1 and 3, snare on 2 and 4, 16th hats with rolls, and pitching snare roll at end of phrase (8 bars) — simulated by ascending pitch notes.

  2. Bass (bass_track): Sub-bass following chord roots, syncopated gaps, octave drops. Sustained under chords.

  3. Chords (chord_track): Big supersaw-style chords — major 7th / add9 voicings, wide voicings (root/third/seventh/ninth/octave), 2 bars per chord. I-V-vi-IV progression.

  4. Lead (lead_track): Vocal-chop style melodic fragments — short rhythmic notes in major scale, catchy phrases, starts after 4 bars.

bpm: Tempo (120-170, default 150). bars: Arrangement length (4-32, default 8). root: Root note (default C = common future bass key). octave: MIDI octave for chords (3 = C3=48).

Example: create_future_bass_arrangement(bpm=150, root="C", bars=8) create_future_bass_arrangement(bpm=140, root="G", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
chord_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully explain behavior. It details the creation of 4 tracks with specific musical patterns and parameter defaults. However, it fails to mention that the tool likely modifies existing tracks (via track index parameters) and may overwrite existing content. The description implies generative behavior but lacks explicit warnings about destructive actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a summary sentence but contains a lengthy paragraph on future bass characteristics that is interesting but not essential for tool usage. Track descriptions are detailed but could be more compact. Examples are useful. Slightly verbose overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, genre-specific), the description covers the main aspects: genre characteristics, track roles, musical patterns, defaults, and examples. It does not describe the output schema or side effects (e.g., overwriting behavior), but for a creative arrangement tool it provides sufficient context for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates partially. It explains bpm, bars, root, and octave with ranges and defaults, and implicitly connects track parameters to the 4 tracks. However, parameters like velocity, start_beat, and unit_index are not explained. Examples help but coverage is ~45%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Create a full future bass arrangement — 4 tracks' with specific genre characteristics and track roles. The verb 'create' and resource 'future bass arrangement' are precise, and the description distinguishes this tool from the many other genre-specific arrangement tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for future bass arrangements but does not explicitly state when to use this tool vs alternatives (e.g., other create_*_arrangement tools). No when-not or alternative guidance is provided, though the genre context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_garage_arrangementA

Create a UK garage arrangement — 130 BPM 2-step swing.

UK garage (UKG) is a British electronic genre evolving from US garage house with drum & bass influence. Key characteristics:

  • 2-step drum pattern: kick on 1, snare on 2 & 4, skip beats

  • Swing/shuffle feel (16th note swing)

  • Chopped vocal stabs and chord stabs

  • Deep bassline with melodic movement

  • 130-138 BPM, 4/4 time

  • Smooth, bumping, after-hours energy

Creates 4 tracks:

  1. Drums (track_index): 2-step kick (beat 1, sometimes 3), snare on 2 & 4, swung hats, skip-beat ghost notes

  2. Bass (track_index+1): Melodic bassline with octave jumps and syncopation, walking-ish movement

  3. Chords (track_index+2): Stab chords on offbeats, major 7th and minor 9th voicings, Rhodes-style

  4. Lead (track_index+3): Vocal-chop-style melodic stabs, short rhythmic phrases

Default key: G minor (common UKG key).

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoG
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It details the tracks created and their indices but does not explain side effects (e.g., whether existing tracks are overwritten, what happens if track indices clash, or if required instruments are loaded). Some behavioral aspects are implied but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description starts with a clear one-line summary, then provides genre characteristics and track details. It is fairly concise, though the genre paragraph is detailed and may be unnecessary for tool invocation. Overall well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 parameters, 0% schema coverage), the description lacks parameter explanations and behavioral details. It covers the musical output but not how parameters affect it. An output schema exists but is not referenced, leaving the agent without knowledge of the return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description should explain parameters. It only implicitly references track_index via track indices. The other 6 parameters (bpm, bars, key_root, velocity, start_beat, unit_index) are not explained. Defaults align with description (e.g., 130 BPM, G minor) but semantics are missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a UK garage arrangement' and specifies the 4 tracks created (drums, bass, chords, lead) with genre-specific details. It distinguishes from many sibling tools that create other genre arrangements (e.g., create_acid_arrangement, create_afrobeat_arrangement).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool name and description imply use when a UK garage arrangement is needed. The genre characteristics provide context. However, it does not explicitly state when not to use it or suggest alternatives among the many genre-specific arrangment tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_genre_sectionsA

Create a multi-section electronic track from loop-based arrangements — intro → buildup → drop → breakdown → outro.

Transforms loop-based arrangements into song structure. Each section is a separate arrangement call with different start_beat and velocity, creating dynamic energy progression. For electronic genres only (dnb/house/techno/ trance/dubstep/synthwave/trap/disco).

Section energy progression:

  • Intro (bars 0-N): drums only (kick + hat), no bass/melody. velocity * 0.5. Builds anticipation. Sparse and atmospheric.

  • Buildup (bars N-2N): drums + bass, no harmony/melody. velocity * 0.7. Energy rising, groove established.

  • Drop (bars 2N-3N): ALL tracks at full velocity. The climax — full arrangement with maximum energy. This is where the hook hits.

  • Breakdown (bars 3N-4N): harmony + melody only, no drums/bass. velocity * 0.6. Pull back, breathe, create contrast before final drop.

  • Outro (bars 4N-5N): drums + bass fading. velocity * 0.4. Wind down.

section_lengths: Comma-separated bar counts for each section. Default "4,8,8,8,4" = intro(4) + buildup(8) + drop(8) + breakdown(8) + outro(4) = 32 bars total. For a shorter track: "2,4,8,4,2" = 20 bars. For a longer track: "8,16,16,16,8" = 64 bars.

genre: Electronic genre only: dnb, house, techno, trance, dubstep, synthwave, trap, disco bpm: Override tempo (None = genre default). root: Override key (None = genre default). section_lengths: Comma-separated bar counts (5 sections, must sum to multiple of 4).

Returns sections created, notes per section, total notes, and energy profile.

Example:

32-bar DnB track with song structure

create_genre_sections("dnb", section_lengths="4,8,8,8,4")

64-bar trance epic

create_genre_sections("trance", section_lengths="8,16,16,16,8")

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
rootNo
genreYes
bass_trackNo
drum_trackNo
unit_indexNo
melody_trackNo
harmony_trackNo
section_lengthsNo4,8,8,8,4

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses key behaviors: section structure, velocity multipliers, and instrumentation per section. It states it transforms loop-based arrangements and returns sections created and energy profile. It does not mention whether it overwrites existing data or requires specific permissions, but the core transformation is well-described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose statement, section breakdown, parameter explanations, examples. It is front-loaded with essential info and each sentence adds value. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 params, no schema descriptions, no annotations), the description covers the main concepts and parameters. It explains the section energy progression, parameter usage, and return values. However, it lacks explanation for track indices and unit_index, which are needed for full integration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It does well for genre, section_lengths, bpm, and root with examples and defaults. However, it does not explain bass_track, drum_track, harmony_track, melody_track, or unit_index, leaving 5 of 9 parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a multi-section electronic track with defined sections (intro, buildup, drop, breakdown, outro). It specifies the action ('transforms loop-based arrangements into song structure') and distinguishes from siblings by limiting to electronic genres.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes usage context: 'For electronic genres only' and lists allowed genres. It provides examples with different section_lengths. However, it does not explicitly compare with sibling genre-specific arrangement tools (e.g., create_dnb_arrangement) or state when to use this generic vs. specific tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_genre_trackA

Create a genre-specific starting track with synth, beat, and basic mix — one call builds a full section.

genre: Musical genre preset:

  • "house" — 4/4 kick, offbeat hat, stab bass, 128 BPM

  • "techno" — driving kick, ride hat, acid bass, 130 BPM

  • "lofi" — swing kick/snare, soft keys, 80 BPM

  • "dnb" — breakbeat drums, sub bass, 174 BPM

  • "trap" — 808 kick, hat rolls, melodic lead, 140 BPM

  • "ambient" — pad chord, no drums, 70 BPM

  • "coldwave" — driving kick, dark bass, 110 BPM

  • "hiphop" — boom bap kick/snare, 90 BPM

bpm: Override tempo (default per genre).

Returns created AU indices, note counts, and suggested next steps.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
genreYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses creation of a track with synth, beat, mix and indicates return values (AU indices, note counts, suggested next steps). However, it does not explicitly state that a new track is added to the project, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence, a bullet-like list of genres, a line for bpm, and a returns note. It is concise with no unnecessary words, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions return values, which is good given an output schema exists. However, it could be improved by explicitly stating that a new track is added to the project. Overall, it is complete for a simple creation tool but has a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only 'string' and 'number' types, but the description adds detailed genre definitions with musical content for each option and clarifies bpm as an override with default per genre. With 0% schema coverage, the description fully compensates and adds significant meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a genre-specific starting track with synth, beat, and basic mix — one call builds a full section.' It uses a specific verb+resource and distinguishes itself from siblings like create_genre_sections and create_full_genre_pipeline by emphasizing the one-call full section creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on what genres are available and bpm override but lacks explicit guidance on when to use this tool versus alternatives like create_genre_sections or create_full_genre_pipeline. It does not state prerequisites or exclusions, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ghost_notesA

Add ghost notes (quiet grace notes) to existing drum/MIDI patterns.

Ghost notes are very quiet notes placed between main hits, adding groove and complexity. Essential for funk, R&B, neo-soul, and hip-hop drumming. They fill spaces between snare/kick hits with subtle taps that make the beat feel alive.

Inserts new low-velocity notes at off-beat positions where no notes currently exist. Works on the first note track of the specified AU/track.

unit_index: AU index. track_index: Note track index (-1 = first note track). region_index: Region index (-1 = first region). density: Probability of adding a ghost note at each empty 16th position (0.2 = sparse, 0.5 = busy). velocity: Ghost note velocity 0-1 (0.25 = very quiet, 0.4 = audible). seed: Random seed for reproducibility.

Returns number of ghost notes added and positions.

Example: create_ghost_notes(unit_index=0, density=0.35, velocity=0.3, seed=99)

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo
densityNo
velocityNo
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that it inserts new low-velocity notes at off-beat positions where no notes exist, and works on the first note track if track_index=-1. It mentions returns number of ghost notes added and positions. It could clarify that it does not modify existing notes, but overall good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening statement, detailed explanation, parameter list, return value, and example. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters and no annotations, the description covers all necessary aspects: purpose, mechanism, parameter details, return value, and usage context. It is complete enough for an AI agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds excellent parameter explanations: density (probability at each 16th position), velocity (0-1 with typical ranges), seed (reproducibility), plus index defaults. Example usage further clarifies. This fully compensates for the lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds ghost notes to existing drum/MIDI patterns, explains what ghost notes are, and specifies it works on the first note track. It distinguishes from siblings like create_note or create_drum_pattern by focusing on adding subtle, low-velocity notes to existing patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context by mentioning genres where ghost notes are essential (funk, R&B, neo-soul, hip-hop) and explains they fill spaces between main hits. However, it does not explicitly exclude alternatives or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_glissandoA

Create a glissando — smooth scale run between two pitches.

A continuous-sounding slide through intermediate pitches. Unlike riser/bass_drop (which are pitch sweeps), glissando plays every intermediate note at a fixed rate, creating a true scale run feel. Works chromatically (every semitone) or diatonically (scale tones only) or pentatonically.

start_pitch: Starting MIDI note (default 60 = C4). end_pitch: Ending MIDI note (default 72 = C5). Can be higher or lower. scale_type: "chromatic" (every semitone), "major" (diatonic major scale), "minor" (natural minor), "pentatonic_minor", "pentatonic_major", "whole_tone". duration_beats: Total duration in beats (0.5-16, default 2). rate: Note rate — "32nd", "16th", "8th", "32t", "16t". velocity: Base velocity 0-1 (default 0.8). velocity_curve: "flat" (constant), "ramp_up" (crescendo into landing), "ramp_down" (decrescendo), "arc" (peak in middle). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the glissando begins.

Returns notes created, pitch list, scale type.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateNo16th
velocityNo
end_pitchNo
scale_typeNochromatic
start_beatNo
unit_indexNo
start_pitchNo
track_indexNo
duration_beatsNo
velocity_curveNoramp_up

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It clearly states that glissando creates a continuous-sounding slide through intermediate pitches, works in chromatic/diatonic/pentatonic modes, and mentions the return value: 'Returns notes created, pitch list, scale type.' This is sufficient for an agent to understand the tool's behavior and output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with the purpose stated upfront, followed by a parameter-by-parameter breakdown. It is slightly lengthy, but every sentence adds necessary information. It could be slightly more concise by grouping related parameters, but it remains clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 10 parameters, lack of annotations, and presence of an output schema, the description covers all necessary aspects: parameter semantics, return values, and behavioral context (scale types, differentiation from similar tools). An agent can confidently select and invoke this tool correctly based on this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the tool's description provides detailed explanations for all 10 parameters, including defaults and allowed values (e.g., scale_type options, rate values, velocity_curve types). This adds substantial meaning beyond the schema, fully compensating for its lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear statement: 'Create a glissando — smooth scale run between two pitches.' It then distinguishes this tool from riser/bass_drop by explaining that glissando plays every intermediate note at a fixed rate, unlike pitch sweeps. This effectively differentiates it from sibling tools with similar names, achieving a specific verb+resource pairing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts glissando with riser/bass_drop, indicating when to use this tool instead (for a true scale run feel rather than a pitch sweep). It also explains the three scale types (chromatic, diatonic, pentatonic) to guide usage. However, it does not provide explicit when-not-to-use scenarios or alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_gospel_arrangementA

Create a full gospel arrangement — shuffle drums + walking bass + Hammond organ + choir.

Gospel music — the foundation of soul, R&B, and modern pop:

  • Track 0: Drums — gospel shuffle. Kick on 1, snare on 2+4 with ghost notes, hi-hats with triplet shuffle feel. The "pocket" is deep — slightly behind the beat. Dynamics are expressive.

  • Track 1: Bass — walking bass line through I-IV-V-I progression. Root → 3rd → 5th → approach note. Warm, supportive.

  • Track 2: Hammond B3 organ — chord stabs with Leslie rotation feel. Triadic voicings, 2nd inversion common. The Hammond is the signature sound of gospel — drawbar harmonics.

  • Track 3: Choir — sustained SATB voicings. Call-and-response with organ. Long notes, rich harmony, the "church" sound.

Ab major default — flat keys are traditional for gospel singers. I-IV-V-I progression (Ab-Db-Eb-Ab) with passing diminished approach. 6/8 or 4/4 at 70-85 BPM (slow groove).

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoAb
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
choir_trackNo
organ_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full behavioral transparency burden. It details the four tracks created and their musical roles, key, progression, tempo range, and time signatures. However, it omits side effects like interaction with existing project state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with main purpose, followed by bullet-pointed track details. Some verbose contextual sentences ('Gospel music — the foundation...'), but overall well-structured and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters and no schema descriptions, the description adequately covers the arrangement components and key parameters. However, gaps remain for several parameters (e.g., unit_index, start_beat) that are not explained, affecting agent's ability to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains some parameters (bpm, root, tempo range, track numbers) but not all 11 (e.g., unit_index, start_beat, octave details). Partial but insufficient coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a full gospel arrangement with specific instruments (shuffle drums, walking bass, Hammond organ, choir). It distinguishes from sibling genre-specific tools by detailing the gospel style components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies usage for traditional gospel arrangements, it lacks explicit when-to-use or when-not-to-use guidance compared to other genre arrangement tools. No alternatives or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ground_bassA

Create a ground bass — a repeating ostinato bass line with optional melody.

The ground bass (basso ostinato) is one of the oldest composition techniques: a short bass pattern repeats throughout the piece while melodies above it change and develop. Used in baroque (Purcell's Dido's Lament, Bach's Crucifixus), chaconne/passacaglia tradition, jazz modal vamps, and film scoring (repeating tension ostinati).

Unlike passacaglia (which generates variations above the bass), ground_bass creates the pure repeating bass ostinato + a melody line that develops over the repetitions. The melody changes character per repetition cycle.

melody_styles: "baroque" — Stepwise descending lines over the ground. chromatic passing tones, suspensions on strong beats. Purcell/Bach style. Melody descends gradually across repetitions. "modal" — Modal jazz vamp style. Long sustained notes, sparse placement, emphasis on chord tones. Miles Davis / Kind of Blue aesthetic. Melody floats above the bass. "minimalist" — Steve Reich / Philip Glass style. Phase-shifted melodic fragments, repetitive cells, gradual transformation. Melody uses small intervals and repeating patterns. "film_tension" — Dark film scoring style. Minor 2nd and tritone intervals, dissonant suspensions, gradual crescendo. Melody builds tension across repetitions. "folk" — Strophic folk variation style. Pentatonic-leaning melody, simple rhythmic values, phrase repetition with slight variation. Celtic / English folk tradition.

Args: bass_pattern: Space-separated bass notes (e.g. "A2 E2 C2 G2"). Can use note names (A2, C3) or MIDI numbers (45, 52). bass_rhythm: Space-separated durations in beats for each bass note (e.g. "2 2 2 2" = 4 notes each lasting 2 beats = 8-beat cycle). repeats: Number of bass repetitions (2-32). melody_style: Melody character above the ground. unit_index: AU index. track_index: Note track index (bass goes here, melody on track_index+1). start_beat: Starting beat position. velocity: Base velocity 0-1.

Returns bass notes created, melody notes, cycle info, and style.

ParametersJSON Schema
NameRequiredDescriptionDefault
repeatsNo
velocityNo
start_beatNo
unit_indexNo
bass_rhythmNo2 2 2 2
track_indexNo
bass_patternNoA2 A2 E2 E2
melody_styleNobaroque

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It explains that the bass pattern repeats and the melody develops per cycle, and details melody_styles. However, it omits side effects (e.g., overwriting existing notes), error conditions, or required track state. For a creative tool, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured but somewhat verbose, especially the historical background and detailed melody_style descriptions. While informative, it could be more concise for an AI agent. However, it front-loads the purpose and uses clear sectioning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description covers the main aspects: what it creates, how to use parameters, and what is returned. It does not discuss edge cases or error handling, but it provides sufficient context for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates well. It explains each parameter in the 'Args:' section, including format for bass_pattern and bass_rhythm, range for repeats, and details for melody_style. It adds meaning beyond the schema titles and defaults, though some parameters like unit_index and track_index are only briefly mentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a ground bass — a repeating ostinato bass line with optional melody.' It specifies the verb-action (create), the resource (ground bass), and distinguishes it from passacaglia by explaining the difference. This allows an agent to understand what the tool does and how it differs from siblings like create_passacaglia.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use a ground bass, provides historical context, and contrasts with passacaglia. It also lists melody_styles with detailed descriptions, guiding the agent's choice. However, it does not explicitly state when not to use this tool or provide alternatives for similar tools like create_ostinato.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_hardstyle_arrangementB

Create a hardstyle arrangement — 150 BPM festival hard dance.

Hardstyle is a Dutch electronic dance genre characterized by:

  • Hard, distorted kick drum with a pitched tail (the signature sound)

  • Reverse bass (off-beat bass that "reverses" the kick pattern)

  • Screechy/sawtooth lead synth with wide unison

  • 150 BPM, 4/4 time

  • Aggressive, festival/headbanger energy

Creates 4 tracks:

  1. Drums (track_index): Hard kick on every beat, snare on 2&4, closed hats on offbeats, open hat occasionally

  2. Bass (track_index+1): Reverse bass pattern — bass on offbeats between kicks, creating the signature "boom-BM-boom-BM" feel

  3. Lead (track_index+2): Screechy sawtooth lead playing a minor melody with wide intervals and octave jumps

  4. Chords (track_index+3): Stab chords on beat 1 and 3, minor key

Default key: F minor (common hardstyle key).

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoF
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It describes what tracks are created (drums, bass, lead, chords) and their musical patterns, but does not disclose potential side effects such as whether it overwrites existing tracks, requires specific instruments, or modifies the project in other ways. It provides moderate transparency but leaves behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose ('Create a hardstyle arrangement — 150 BPM festival hard dance') and then provides concise yet detailed breakdowns of genre characteristics and track patterns. Every sentence provides useful context, though the structure could be slightly improved by separating parameter details from general description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters with no required fields and no parameter descriptions, the description is incomplete. It does not explain how parameters like velocity or key_root influence the arrangement, nor does it provide behavioral context such as whether the tool requires a pre-existing project or will create tracks from scratch. The presence of an output schema helps but does not compensate for the lack of parameter semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description only mentions track_index in the context of track creation but fails to explain how other parameters (bpm, bars, key_root, velocity, start_beat, unit_index) affect the output. This is a critical gap that severely limits an agent's ability to use the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a hardstyle arrangement at 150 BPM, and lists 4 specific tracks with their musical patterns. Among the many create_*_arrangement siblings, this description effectively distinguishes the tool by genre and BPM, making it easy for an agent to select the correct genre arrangement tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for hardstyle genre creation by describing the genre and track structure, but it does not provide explicit guidance on when to use this tool versus other arrangement tools, nor does it mention any prerequisites or exclusions (e.g., whether existing tracks are cleared or if specific samples are required).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_harmonic_arrangementA

Create all five harmonic layers from one progression string in one call.

Replaces 5 separate calls (chord_pads + arpeggiated_progression + bass_from_progression + melody_from_progression + counter_melody_from_progression) with a single call. All layers take the same "Am-F-C-G" progression and are placed on separate tracks: pads (track 2), arp (track 3), bass (track 1), melody (track 3 or 4), counter-melody (track 4 or 5).

By default arp and melody share track 3 (melody track). Set melody_pattern to "" to skip melody, arp_pattern to "" to skip arp, bass_pattern to "" to skip bass, pad_octave to -1 to skip pads, counter_melody_pattern to "" to skip counter-melody (default).

progression: Hyphen-separated chords (same format as the quartet tools). pad_octave: Octave for chord pads (default 3). arp_pattern: Arp pattern: up/down/updown/random/bass, or "" to skip. arp_octave: Octave for arp (default 4). arp_step: Arp step duration in beats (default 0.25 = 16th). bass_pattern: Bass pattern: root/root_fifth/walking/pedal/octave/root_octave. bass_octave: Octave for bass (default 2). melody_pattern: Melody pattern: chord_tones/sustained/syncopated/triadic/stepwise. melody_octave: Octave for melody (default 5). counter_melody_pattern: Counter-melody pattern: contrary/oblique/parallel_third/ parallel_sixth/call_response, or "" to skip (default ""). counter_melody_octave: Octave for counter-melody (default 4). bars_per_chord: Bars per chord (default 4). velocity: Base velocity for all layers (0-1).

Example:

Full synthwave harmonic arrangement in one call

create_harmonic_arrangement("Am-F-C-G", arp_pattern="up", bass_pattern="root", melody_pattern="chord_tones")

Jazz: walking bass + sustained pads, skip arp

create_harmonic_arrangement("Dm7-G7-Cmaj7-Am7", arp_pattern="", bass_pattern="walking", melody_pattern="sustained", bars_per_chord=2)

House: pedal sub-bass + pads, skip melody

create_harmonic_arrangement("Fm-Fm-Db-Ab", arp_pattern="bass", bass_pattern="pedal", bass_octave=1, melody_pattern="", pad_octave=3)

Full quintet with counter-melody

create_harmonic_arrangement("Am-F-C-G", arp_pattern="up", bass_pattern="root", melody_pattern="chord_tones", counter_melody_pattern="contrary")

ParametersJSON Schema
NameRequiredDescriptionDefault
arp_stepNo
velocityNo
arp_octaveNo
pad_octaveNo
start_beatNo
unit_indexNo
arp_patternNoup
bass_octaveNo
progressionNoAm-F-C-G
bass_patternNoroot
melody_octaveNo
bars_per_chordNo
melody_patternNochord_tones
counter_melody_octaveNo
counter_melody_patternNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that layers are placed on separate tracks (e.g., pads on track 2, bass on track 1) and details defaults and skipping. However, it does not mention preconditions (e.g., whether tracks must exist) or side effects (e.g., overwriting existing data), leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it opens with the core benefit, then lists layers, tracks, defaults, parameter definitions, and examples. While lengthy, it earns its length given the tool's complexity and 15 parameters. Minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (15 parameters, 5 layers) and the presence of an output schema, the description covers what the tool does, how to use each parameter, and includes practical examples. However, it omits preconditions (e.g., project state) and postconditions (e.g., track creation), slightly reducing completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain parameters. It does so comprehensively: for each parameter, it explains purpose, accepted values (e.g., arp patterns: up/down/updown/random/bass, or '' to skip), and defaults. Examples reinforce usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates five harmonic layers from one progression string in one call, with a specific verb ('create') and resource ('harmonic arrangement'). It explicitly distinguishes from siblings by noting it replaces five separate calls (chord_pads, arpeggiated_progression, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says it replaces 5 separate calls with a single call, implying when to use it. It provides examples for various use cases (synthwave, jazz, house, full quintet) and shows how to skip layers. However, it does not explicitly state when to prefer the individual tools, though the skip mechanism covers partial use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_harmonyA

Generate harmony parts from existing notes — thirds, fifths, sixths, octaves.

Reads notes from an existing region and creates harmonized copies at a fixed interval. Supports diatonic (scale-aware) and chromatic (fixed semitone) intervals. Output goes to a new or existing track.

unit_index: Source AU index. track_index: Source note track index. region_index: Source region index. interval: Harmony interval type:

  • "thirds" — diatonic third above/below (3rd scale degree)

  • "fifths" — diatonic fifth (5th scale degree)

  • "sixths" — diatonic sixth (6th scale degree)

  • "octave" — octave up/down (12 semitones)

  • "fifth_chromatic" — perfect fifth (7 semitones, fixed)

  • "fourth_chromatic" — perfect fourth (5 semitones, fixed)

  • "third_major" — major third (4 semitones, fixed)

  • "third_minor" — minor third (3 semitones, fixed) direction: "up" or "down" (harmony above or below the melody). new_unit_index: Target AU index (-1 = create new synth track for harmony). new_track_index: Target note track index on the target AU. velocity: Velocity for harmony notes (default 0.65, slightly quieter than melody).

Returns source notes read and harmony notes created.

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNothirds
velocityNo
directionNoup
unit_indexYes
track_indexNo
region_indexNo
new_unit_indexNo
new_track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains that it reads notes from an existing region, creates copies, and supports diatonic/chromatic intervals. It mentions default velocity and output to new/existing track. However, it does not disclose potential side effects (e.g., whether original notes are modified, destruction, or idempotency). With zero annotations, this is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief summary, followed by a clear list of parameters with explanations. It is front-loaded with the main purpose. While it is somewhat lengthy, every sentence contributes value. Minor redundancy could be trimmed (e.g., 'interval: Harmony interval type:' is slightly repetitive), but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 0% schema coverage, and an output schema, the description covers all parameters adequately and mentions return values ('Returns source notes read and harmony notes created'). It explains the process and the difference between diatonic and chromatic intervals. The output schema likely details the return structure, so the description is sufficient for an AI to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description extensively explains each parameter. For interval, it lists all valid values and their meanings (e.g., 'thirds — diatonic third above/below'). It explains velocity default (0.65, slightly quieter) and the purpose of new_unit_index (-1 creates new track). This adds significant meaning beyond the schema names and compensates fully for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Generate harmony parts from existing notes'. It lists specific intervals (thirds, fifths, sixths, octaves) and differentiates from similar tools like create_harmony_line by focusing on fixed-interval harmony from existing notes. The verb 'create' and resource 'harmony parts' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when harmonizing existing notes: 'Reads notes from an existing region and creates harmonized copies at a fixed interval.' It does not explicitly state when not to use or provide alternatives, but the context is clear. Among siblings like create_harmony_line, this tool is for fixed-interval harmony, which is clearly indicated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_harmony_lineA

Create a harmony line from an existing melody using diatonic intervals.

Reads notes from a source melody and creates a parallel harmony line at a specified diatonic interval. The harmony stays in key — each note is shifted by N scale steps (not semitones), producing consonant harmony automatically.

Harmony intervals (diatonic):

  • third: +2 scale steps — the most common harmony (Lennon-McCartney, Everly Brothers, country duets). Sweet and consonant.

  • sixth: +5 scale steps — wider, jazzier. Creates open, airy harmony.

  • fifth: +4 scale steps — power harmony, medieval/organum sound.

  • fourth: +3 scale steps — suspended, ambiguous. Gregorian/modal.

  • octave: +7 scale steps (or -7) — doubling, not true harmony but useful for layering.

Essential for: vocal harmonies, string pads behind melody, guitar harmonies, counter-melody foundation, thickening lead lines.

source_unit/track/region: Location of the source melody. target_unit/track/region: Where to write the harmony. -1 = create new track/region automatically. interval: third, sixth, fifth, fourth, octave. root_note + scale: The key for diatonic interval calculation. The harmony notes are guaranteed to be in this scale. direction: "above" or "below" — place harmony above or below the melody. velocity_scale: Multiply source velocities by this (default 0.8 = harmony slightly quieter than melody).

Returns the created harmony notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
scaleNomajor
intervalNothird
directionNobelow
root_noteNoC
source_unitNo
target_unitNo
source_trackNo
target_trackNo
source_regionNo
target_regionNo
velocity_scaleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the key behavior (reads melody, writes harmony, stays in key, can auto-create tracks) but does not mention potential side effects like overwriting existing targets or error conditions. It is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, mechanism, interval list with descriptions, use cases, parameter explanations. It is concise without unnecessary words, front-loads the core action, and uses markdown effectively for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers main behaviors (diatonic intervals, target auto-creation, velocity scaling) and includes musical context. It lacks explicit handling of edge cases (e.g., empty source, rests) but is sufficient for a tool with output schema and clear defaults. Sibling tools are differentiated well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description explains the role of key parameters (source/target locations, interval, root_note+scale, direction, velocity_scale) with meaningful context (e.g., interval musical descriptions, default auto-create). It adds significant value beyond the schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a harmony line from an existing melody using diatonic intervals', specifying the action, input, and method. It distinguishes from siblings by focusing on parallel diatonic harmony, unlike other harmony tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (e.g., vocal harmonies, string pads) and outlines the intervals, but does not explicitly state when not to use it or provide alternatives. It gives good context but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_hemiolaA

Create a hemiola — 3:2 rhythmic displacement creating cross-rhythm illusion.

A hemiola superimposes a 3-note grouping over a 2-note grouping (or vice versa) within the same time span, creating the illusion of a different meter. The classic 3-against-2 pattern is fundamental to West African, Afro-Cuban, jazz, and minimalist music. Brahms, Bernstein, and Glass used it extensively.

The pattern string defines which beats get primary vs secondary emphasis: "3:2" — 3 primary notes in the time of 2 secondary (classic hemiola) "2:3" — 2 primary notes in the time of 3 secondary (inverse hemiola)

Creates notes on a single track: primary group uses primary_pitch, secondary group uses secondary_pitch. Both span the same total duration.

pattern: "3:2" (3 against 2) or "2:3" (2 against 3). bars: Total length in bars (1-4). Each bar = 4 beats. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. primary_pitch: MIDI pitch for primary group (default 60 = C4). secondary_pitch: MIDI pitch for secondary group (default 64 = E4). primary_velocity: Velocity for primary notes 0-1. secondary_velocity: Velocity for secondary notes 0-1. duration: Note duration in beats.

Returns total notes created and hemiola ratio.

Example: create_hemiola(pattern="3:2", bars=2, primary_pitch=60, secondary_pitch=67)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
patternYes
durationNo
start_beatNo
unit_indexNo
track_indexNo
primary_pitchNo
secondary_pitchNo
primary_velocityNo
secondary_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explains that notes are created on a single track, both groups span the same total duration, and returns 'total notes created and hemiola ratio'. It does not disclose prerequisites, destructiveness, or undo capabilities, but the core behavior is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: it starts with a clear purpose, then gives musical background, pattern explanation, parameter list, return info, and an example. It could be slightly more concise, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, 1 required, no output schema in structured data), the description adequately covers all parameters, explains the output, and includes an example. It is mostly complete, though it could specify whether the track must already exist or if the tool creates it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions in input schema), so the description must compensate fully. It provides a comprehensive list of all 10 parameters with their meanings, default values, and range constraints (e.g., bars 1-4, velocity 0-1). This goes well beyond what the schema alone offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a hemiola, a 3:2 rhythmic displacement, and provides a detailed explanation of the concept. It distinguishes itself from sibling tools like create_polyrhythm by specifically naming the pattern types (3:2 and 2:3) and the musical context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the musical purpose and provides pattern options (3:2 and 2:3), giving clear guidance on when to use the tool. However, it does not explicitly tell when not to use it or compare with alternative tools like create_polyrhythm, which could have overlapping functionality.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_hocketA

Create a hocket — single melodic line split between voices/tracks.

Hocket (from Latin "hoquet" = hiccup) is a technique where a single melody is divided between two or more voices. Each voice plays only every other (or every Nth) note, creating an interlocking texture. Found in medieval polyphony (Notre Dame school), African mbira music, Balinese gamelan, and modern minimalist composition (Steve Reich).

melody: Comma-separated MIDI pitches forming the complete melodic line. voices: Number of voices to split between (2-4, default 2). split_mode: How notes are distributed: "alternate" — round-robin (note 0→voice 0, note 1→voice 1, ...) "pairs" — pairs of notes per voice (2 per voice, then switch) "phrase" — 4-note phrases per voice unit_index: AU index with note tracks (-1 = find AU with enough note tracks). track_index: Starting note track index (uses consecutive tracks for voices). start_beat: Position in beats where the hocket begins. note_duration: Duration of each note in beats (default 0.5 = eighth notes). velocity: Velocity of all notes (0-1, default 0.7).

Returns notes created, voice assignment, total duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
melodyNo60,62,64,65,67,65,64,62
voicesNo
velocityNo
split_modeNoalternate
start_beatNo
unit_indexNo
track_indexNo
note_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains parameters and return values but does not disclose side effects, idempotency, permission requirements, or whether it modifies existing data. The phrase 'returns notes created' implies creation without modification, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description starts with a clear one-line summary, followed by contextual information and a parameter list. The musical background paragraph is informative but slightly verbose for a technical tool. Overall, it is well-organized and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and an output schema mentioned, the description covers the main aspects but lacks clarity on project-specific terms like 'AU' and 'note tracks'. The return values are summarized but not detailed, which is acceptable since an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It provides explanations for all 8 parameters, including valid options for split_mode. However, some terms like 'AU index' and 'track index' are not fully elaborated, leaving minor ambiguity for an AI agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a hocket, a specific melodic splitting technique. It distinguishes from siblings like create_melody or create_counterpoint by naming the exact compositional technique and providing a definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the hocket technique but does not explicitly state when to use this tool versus alternatives like create_melody or create_counterpoint. No guidance on prerequisites or contexts where the tool is inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_house_arrangementA

Create a full house music arrangement — drums + bass + stabs across 3 tracks in one call.

House music arrangement with all elements locked together:

  • Track 0: Drums — four-on-the-floor kick, open hats on off-beats, clap on 2+4

  • Track 1: Bass — off-beat sustained bass between kicks

  • Track 2: Stabs — short minor chord stabs on beats 1 and 3, with occasional off-beat stabs

At 124 BPM (default), this creates the classic Chicago/Detroit house feel. The bass and drums lock — bass hits exactly between kicks, creating the "untz-untz" groove. Stabs provide harmonic movement on top.

bpm: Tempo (115-135, default 124 = classic house). bars: Arrangement length (4-32, default 8). root: Root note for bass and stabs. octave: MIDI octave for bass (2 = C2=36). unit_index: AU index with note tracks. drum_track / bass_track / stab_track: Track indices.

Returns notes created per track and total.

Example: create_house_arrangement(bpm=124, root="C", bars=8) create_house_arrangement(bpm=128, root="F#", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
stab_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It explains the musical output per track and defaults but does not disclose side effects such as whether it overwrites existing tracks, idempotency, or what happens if tracks are already occupied. Missing safety-related behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, detailed musical breakdown, parameter list, and examples. It is slightly verbose but effectively organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (10 params, no annotations, many siblings), the description covers the musical intent and basic usage. However, it lacks guidance on edge cases (e.g., missing tracks, invalid unit_index) and does not fully detail the output format or how it integrates with existing project state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It describes most parameters (bpm, bars, root, octave, unit_index, track indices) with brief context, but velocity and start_beat are missing from the description. The output schema is referenced but not detailed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full house music arrangement with specific tracks (drums, bass, stabs). It distinguishes from sibling arrangement tools by being genre-specific and describing the musical pattern in detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes examples showing typical usage but does not explicitly advise when to use this tool over alternative genre-specific arrangements. It lacks explicit when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_impactA

Create an impact — single hit transition element for drops and section changes.

Generates a single sustained note with type-specific pitch, duration, and velocity. Essential for EDM transitions: the "hit" that lands after a riser/build-up.

impact_type: Type of impact:

  • "sub_boom" — deep sub bass hit (C1, long decay, dark)

  • "impact_hit" — mid-range punch (C3, medium decay, aggressive)

  • "downlifter" — descending pitch from high to low (glissando fall)

  • "sub_drop" — lowest sub with long tail (B0, very long, cinematic)

  • "punch" — short bright hit (C5, short decay, snappy)

unit_index: AU index (-1 = find first AU with note tracks). track_index: Note track index. start_beat: Position in beats where the impact lands. pitch: Base MIDI pitch (default 36 = C2, overridden by type). length_beats: Duration in beats (default 4 = one bar). velocity: Hit velocity (0-1, default 0.9 = loud).

Returns notes created and impact parameters.

Example:

Sub boom on the downbeat

create_impact(start_beat=0, impact_type="sub_boom")

Downlifter after riser

create_impact(start_beat=4, impact_type="downlifter", length_beats=2)

ParametersJSON Schema
NameRequiredDescriptionDefault
pitchNo
velocityNo
start_beatNo
unit_indexNo
impact_typeNosub_boom
track_indexNo
length_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains that it generates a single sustained note with type-specific properties and returns notes created and parameters. Does not disclose side effects or destructive nature, but covers main behavior adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: summary line, detailed explanation, parameter list with inline descriptions, and examples. A bit lengthy but every part adds value; could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7 parameters, no schema descriptions, and no annotations, the description is highly complete. It covers purpose, all parameters with defaults and options, return value, and provides examples for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description thoroughly explains all 7 parameters: impact_type with list of values and characteristics, unit_index, track_index, start_beat, pitch (with default and override), length_beats, velocity. Includes examples with default usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it creates an impact—a single hit transition element. Distinguishes itself from siblings by specifying it's for drops and section changes, and describes the output as a sustained note with type-specific characteristics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit usage context: 'Essential for EDM transitions: the hit that lands after a riser/build-up.' Does not mention when not to use or provide direct alternatives, but the use case is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_instrument_trackA

Create a new instrument audio unit with a Tape device and an audio track.

This is required for audio playback — the Tape device reads audio regions and outputs sound. The instrument AU is connected to the output AU's bus.

name: Display name for the instrument (default "Tape"). Returns the unit_index and track_index for use with place_audio_region.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions creation of an instrument AU, Tape device, and audio track, and connection to output AU, but does not discuss side effects (e.g., overwrite, duplication), preconditions, or permissions. The agent lacks information on whether this operation is safe or reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each serving a distinct purpose: action, necessity, connection details, parameter and return info. No redundant or irrelevant content; well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter) and the existence of an output schema, the description covers the core purpose and return values (unit_index, track_index). However, it does not explain what happens if the name conflicts or whether the Tape device is mandatory, leaving minor gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter (name) with 0% description coverage. The description adds the default value 'Tape' and clarifies it is a display name, which compensates partially. However, it does not explain constraints like uniqueness or allowed length, limiting full semantic clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a new instrument audio unit with a Tape device and an audio track, specifying the verb (create) and resource. It distinguishes from siblings like create_audio_track (which lacks the instrument AU) by mentioning the Tape device and connection to output AU.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for audio playback ('required for audio playback'), but does not explicitly state when to use or not use this tool, nor does it compare to alternative creation tools (e.g., create_audio_track, create_synth_track). Usage context is implied but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_irish_tradA

Create an Irish traditional music accompaniment — bodhrán + feet for session tunes.

Irish traditional music (trad) is defined by its tune types, each with a characteristic meter and feel. The bodhrán (frame drum) and feet stomp provide the rhythmic foundation in a session. Unlike most percussion patterns, Irish accompaniment is minimal — the rhythm is carried by the melody's phrasing, and the bodhrán supports rather than drives.

tune types: "reel" — 4/4, straight 8th notes. The most common tune type. Bodhrán: downbeat + offbeat pattern. 4 beats per bar. 2 bars per phrase (AA pattern). Bright, driving. "jig" — 6/8, triplet feel. Groups of 3 eighth notes. Bodhrán: accent on beat 1 and 4 (the two downbeats of 6/8). 2 bars per phrase. Lilting, rolling feel. "hornpipe" — 4/4, dotted rhythm. 8ths are swung (long-short). Bodhrán: similar to reel but with swung feel. 2 bars per phrase. Bouncy, maritime feel. "slip_jig" — 9/8, triplet feel in 3 groups of 3. Rare, ethereal. Bodhrán: accent on 1, 4, 7. 2 bars per phrase. Dancing on air, Turlough O'Carolan style. "polka" — 2/4, fast and punchy. Common in Kerry/Sliabh Luachra. Bodhrán: strong 1 and 2. Simple, driving. 2 bars per phrase. Fast dance, march-like. "slide" — 12/8, similar to jig but faster and longer groups. Bodhrán: accent on 1, 4, 7, 10. 2 bars per phrase. Sliabh Luachra region. Fast, lilting.

Args: tune_type: Tune type (reel, jig, hornpipe, slip_jig, polka, slide). bars: Number of bars (4-32, even). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. bodhran_pitch: Bodhrán (frame drum) MIDI pitch (36 = C1). feet_pitch: Feet stomp MIDI pitch (40 = E1). hh_pitch: Hi-hat/brush MIDI pitch (42 = F#1).

Returns notes created, tune type info, meter, and pattern breakdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
hh_pitchNo
velocityNo
tune_typeNoreel
feet_pitchNo
start_beatNo
unit_indexNo
track_indexNo
bodhran_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description explains what the tool creates and the rhythmic patterns for each tune type, but does not disclose side effects, permission requirements, or behavior for invalid parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear introduction, a detailed breakdown of tune types, and a parameter list. While lengthy, the information is relevant and front-loaded. Could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description thoroughly covers tune types but lacks parameter-level details. The output schema is mentioned but not described in detail. Given 9 parameters and the complexity of Irish trad, more completeness would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the schema provides no descriptions. The tool description ends with a list of parameter names and defaults but does not explain each parameter's meaning beyond their names. This adds minimal value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates Irish traditional music accompaniment with bodhrán and feet, specifying the genre and instruments. It distinguishes itself from sibling tools like create_afrobeat_arrangement by being genre-specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed context on when to use the tool (for session tunes) and explains each tune type with meter and feel. However, it does not explicitly say when not to use it or compare with alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_isorhythmA

Create an isorhythm — repeating rhythm (talea) × repeating pitch series (color).

Isorhythm separates rhythm and pitch into two independent cycles. The talea (rhythmic pattern) and color (pitch series) repeat independently, creating constantly shifting relationships as they go in and out of phase. When talea and color have different lengths, the pattern doesn't fully repeat until the least common multiple of both lengths.

Found in medieval motets (Machaut), and heavily influenced 20th-century composers — Messiaen, Boulez, Stockhausen. Distinct from ostinato, which repeats rhythm and pitch together as one unit.

talea: Comma-separated note durations in beats (the repeating rhythm). e.g. "1,1,0.5,0.5,1" = quarter, quarter, eighth, eighth, quarter. color: Comma-separated MIDI pitches (the repeating pitch series). e.g. "60,62,64,65" = C,D,E,F cycling independently of rhythm. repeats: Number of full talea cycles (1-16, default 3). velocity: Velocity of all notes (0-1, default 0.7). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the isorhythm begins.

Returns notes created, talea/color lengths, phase cycle length, total duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
colorNo60,62,64,65,67,65,64,62
taleaNo1,1,0.5,0.5,1,0.5,0.5,1
repeatsNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains that talea and color cycles repeat independently, causing phasing, and that the full cycle length is the LCM of lengths. It also mentions return values (notes, lengths, duration). However, it does not mention potential side effects like overwriting existing notes or prerequisites (e.g., existence of a note track).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a definition, then historical context, then parameter details, then return values. It is slightly long but every paragraph adds value. Could be trimmed slightly, but no word is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (7 parameters, 0 required) and the presence of an output schema, the description provides comprehensive context: conceptual explanation, parameter formats, behavioral phasing, and return summary. It fully equips an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning to all parameters beyond the input schema. For talea and color, it explains the comma-separated format and gives examples. Repeats, velocity, unit_index, track_index, and start_beat are all described with context. This fully compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an isorhythm, defines it as a repeating rhythm (talea) combined with a repeating pitch series (color), and distinguishes it from ostinato. The verb 'create' and specific resource 'isorhythm' are unambiguous. Historical context and contrast to ostinato further clarify its unique purpose among many sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use an isorhythm (for medieval motets and 20th-century composers) and contrasts it with ostinato. However, it does not explicitly state when NOT to use it or list alternative tools for similar patterns. The guidance is clear but lacks explicit exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_jazz_arrangementA

Create a full jazz arrangement — swing drums + walking bass + comping piano + horn across 4 tracks.

Jazz with swing feel and ii-V-I harmony — fundamentally different from all other arrangements:

  • Track 0: Drums — swing ride pattern (spang-a-lang), brush snare ghost notes, comping on bass drum. The signature jazz ride cymbal pattern with swung 8th notes — the triplet feel that defines jazz.

  • Track 1: Bass — walking bass: quarter notes that walk through the chord changes using chord tones and approach notes. ii-V-I aware, creating smooth voice leading through the changes.

  • Track 2: Piano — comping: syncopated chord stabs using shell voicings (root + third + seventh) and rootless voicings. Frequent rests — comping is about space as much as notes.

  • Track 3: Horn — lead melody: a simple bluesy head over the changes, using blue notes (flatted thirds and fifths) and swing.

At 120 BPM (default), this creates a medium-up swing feel. The ii-V-I progression is the fundamental jazz chord change — every other genre uses different harmony. Swing 8ths (triplet feel) is the rhythmic signature that separates jazz from all straight-time genres.

bpm: Tempo (60-200, default 120 = medium swing). bars: Arrangement length (4-32, default 8). Jazz benefits from longer forms. root: Root note (F is a classic jazz key — great for horns). octave: MIDI octave for bass (2 = F2=41, standard jazz bass register). unit_index: AU index with note tracks. drum_track / bass_track / piano_track / horn_track: Track indices.

Returns notes created per track and total.

Example: create_jazz_arrangement(bpm=120, root="F", bars=8) create_jazz_arrangement(bpm=180, root="Bb", bars=12)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
horn_trackNo
start_beatNo
unit_indexNo
piano_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Detailed description of musical output per track (drum pattern, bass walking, piano comping, horn melody). Discloses return value (notes per track and total). No annotations provided, so description carries full burden; however, it does not address potential side effects like overwriting existing data or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with track breakdown and parameter list, but verbose with detailed musical descriptions that could be shortened. Front-loaded with main purpose, so overall adequate but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and low schema coverage, the description covers purpose, behavioral details per track, default settings, return value, and includes examples. Missing some parameter explanations (velocity, start_beat), but otherwise comprehensive for a complex arrangement tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides meaningful defaults and ranges for most parameters (bpm, bars, root, octave, track indices). Misses 'velocity' and 'start_beat', which weakens completeness, but still adds significant semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it creates a full jazz arrangement with specific instrumentation (swing drums, walking bass, comping piano, horn). Emphasizes unique jazz features (swing feel, ii-V-I harmony) to distinguish from sibling genre-specific arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use (for jazz with swing feel and ii-V-I harmony) and contrasts with other arrangements. Implicitly guides via unique characteristics, but lacks explicit 'when not to use' or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_konokolB

Create Indian Carnatic konokol (solkattu) — vocal percussion as MIDI.

Konokol (also spelled konnakkol) is the South Indian art of vocal percussion. Syllables represent rhythmic patterns: ta, ka, di, mi, thom, nam, ghu, dhi, khatam. Each syllable maps to a specific drum sound. This is the rhythmic foundation of all Carnatic music.

Styles (tala structures):

  • adi_tala: 8-beat cycle (most common). Structure: 4+2+2. Syllables: ta-ka-dhi-mi ta-ka-dhi-mi ta-ka-ta-ka. The foundational tala of Carnatic music.

  • roopaka_tala: 6-beat cycle (3/4). Structure: 3+3. Syllables: ta-ka-dhi ta-ka-dhi-mi. Used in lighter compositions, varnams.

  • khanda_chapu: 5-beat cycle. Structure: 2+3. Syllables: ta-ka ta-ka-ta. Asymmetric, flowing feel. Common in kritis.

  • mishra_chapu: 7-beat cycle. Structure: 3+2+2. Syllables: ta-ki-ta ta-ka ta-ka. Lyrical, song-like rhythm. Used in padams.

  • triputa_tala: 7-beat cycle (3+2+2 variant). Syllables: ta-ka-dhi-mi ta-ka ta. Alternative 7-beat structure.

  • jhampa_tala: 10-beat cycle. Structure: 4+2+4. Syllables: ta-ka-dhi-mi ta-ka ta-ka-dhi-mi. Used in javalis and tillanas.

GM percussion mapping (Indian fusion approach): 36 (kick) → thom, ghu (bass drum — low/open tones) 38 (snare) → nam, dhi (sharp, crisp) 42 (closed hat) → ta, ka (high, crisp) 43 (high floor tom) → mi (mid) 45 (low tom) → khatam (rolled)

Creates konokol notes on track_index. Includes syllable text in the result for reference.

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoadi_tala
cyclesNo
velocityNo
tempo_bpmNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It discloses that MIDI notes are created with GM percussion mapping and syllable text in the result. However, it does not specify whether notes overwrite or merge, track creation behavior, or limitations. Some gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (30+ lines) and includes extensive cultural context and tala details. While the first sentence clearly states the purpose, the following details could be more concise. The GM percussion mapping is useful, but some content may be extraneous for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters with no schema descriptions and no annotations, the description covers the concept and style options well but lacks explanation for most parameters and does not describe return value details (though output schema exists). It also does not clarify if notes are added to existing clips or overwrite. Completeness is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 7 parameters with 0% description coverage, so the description must provide meaning. It extensively explains the `style` parameter with 6 tala options and briefly mentions `track_index`. However, the other 5 parameters (cycles, velocity, tempo_bpm, start_beat, unit_index) receive no explanation, leaving significant gaps for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates Indian Carnatic konokol as MIDI, specifies the verb 'create', the resource 'konokol', and output format 'MIDI'. It distinguishes this tool from others by focusing on a specific rhythmic tradition, with extensive detail on tala structures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool creates konokol notes on a specified track and details the style options and GM mapping. However, it does not explicitly compare with alternatives like `mcp_opendaw_create_tala` or provide guidance on when to choose this over other rhythm creation tools. Usage context is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_korean_percussionA

Create a Korean traditional percussion ensemble — nongak (farmers' music).

Korean percussion (samul nori / nongak) uses four instruments representing weather elements:

  1. JANGGU — Hourglass drum with two heads: chwe (left, low, deep) and kyeongbang (right, high, sharp). The most versatile Korean drum. Plays complex interlocking patterns with both hands simultaneously.

  2. BUK — Barrel drum. Deep bass tone. Plays steady downbeats.

  3. KKWAENGGWARI — Small hand gong. High, piercing metallic. The lead instrument — player (sangsoe) calls patterns and signals changes.

  4. JING — Large gong. Deep, resonant, sustained. Plays sparse accents to mark phrase boundaries.

The four instruments represent: janggu = rain, buk = clouds, kkwaenggwari = thunder, jing = wind (lightning in some traditions).

styles: "nongak" — Farmers' music (rural tradition). Steady, driving. Janggu plays the basic nanajanggu pattern (alternating chwe/kyeong on 8th grid). Buk on downbeats. Kkwaenggwari on offbeats with accented calls. Jing on phrase starts. "samul_nori" — Modern stage version (1978, Kim Duk-soo). Faster, denser, more dramatic. Janggu plays 16th patterns with ghost notes. Kkwaenggwari has call-and-response. "binari" — Ritual/shaman opening piece. Slow, ceremonial. Long jing resonance. Sparse janggu. Kkwaenggwari calls. Builds from near silence. "utdari_pungnyu" — Court music style (upper register). Elegant, refined. Buk steady, janggu delicate 8ths, kkwaenggwari sparse. Jing on every 4 bars. "yeongnam_folk" — Yeongnam region folk style (Gyeongsang). Rough, energetic. Buk on 1+3, janggu syncopated, kkwaenggwari dense. Working-class feel.

Args: bars: Pattern length (4-32, even). style: Style name (nongak, samul_nori, binari, utdari_pungnyu, yeongnam_folk). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. janggu_chwe_pitch: Janggu left head (low) MIDI pitch (35 = B0). janggu_kyong_pitch: Janggu right head (high) MIDI pitch (42 = F#1). buk_pitch: Buk (barrel drum) MIDI pitch (36 = C1). kkwaenggwari_pitch: Kkwaenggwari (small gong) MIDI pitch (54 = G#1). jing_pitch: Jing (large gong) MIDI pitch (48 = C2).

Returns notes created, instrument breakdown, and style info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNonongak
velocityNo
buk_pitchNo
jing_pitchNo
start_beatNo
unit_indexNo
track_indexNo
janggu_chwe_pitchNo
janggu_kyong_pitchNo
kkwaenggwari_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It explains the instrument roles, stylistic patterns, and output (notes, breakdown, style info). It does not disclose potential destructive actions or permissions, but the mutation is well-scoped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with instrument descriptions, style definitions, and parameter list. Each section adds value, though minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With high parameter count, no annotations, and output schema present, the description covers instruments, styles, and parameter semantics. It could mention time signature assumptions or how bars relate to beat count, but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description lists all 11 parameters with detailed explanations (e.g., MIDI pitch mappings, instrument roles). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a Korean traditional percussion ensemble (nongak/samul nori). It distinguishes from sibling tools like create_taiko_ensemble by specifying Korean instruments and styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over alternatives. While the cultural context is clear, no guidance is given on prerequisites or scenarios where other percussion tools would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_liquid_dnb_arrangementA

Create a full liquid drum & bass arrangement across 4 tracks.

Liquid DnB is the smooth, melodic cousin of DnB. Instead of Reese bass and Amen breakbeat fury, liquid uses:

  • Track 0: Smooth breakbeat (gentler ghost notes, more flowing hats)

  • Track 1: Melodic sub-bass (jazzy movement, not just root stabs)

  • Track 2: Lush extended chords (maj7/min9, not plain triads)

  • Track 3: Soulful jazz-influenced lead melody

Think LTJ Bukem, Calibre, High Contrast, Hospital Records.

bpm: Tempo (160-185, default 174). bars: Arrangement length (4-32, default 8). root: Root note (default F = classic liquid key). octave: Bass octave (2 = sub-bass range). velocity: Base velocity (default 0.75 = smoother than DnB's 0.85).

Example: create_liquid_dnb_arrangement(bpm=174, root="F", bars=8) create_liquid_dnb_arrangement(bpm=170, root="Am", bars=16, velocity=0.7)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
pad_trackNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
melody_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description carries full burden. Discloses track roles and musical style, but does not mention whether existing content is overwritten, whether tracks are created, or other side effects. Partially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is appropriately sized, front-loaded with purpose and track overview. Genre background and examples are helpful but slightly verbose. Well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return value explanation is unnecessary. Description covers core functionality and main parameters, though misses some less-used parameters. Adequate for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0% but description explains 5 key parameters (bpm, bars, root, octave, velocity) with defaults and examples. Six parameters (pad_track, bass_track, etc.) are undocumented, relying solely on schema names. Incomplete coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Create a full liquid drum & bass arrangement across 4 tracks' with specific track roles. Distinguishes from sibling 'create_dnb_arrangement' by specifying liquid DnB characteristics and references to artists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Examples show typical usage. Implicitly contrasts with general DnB tool via description of liquid style, but lacks explicit when-not-to-use guidance or comparisons to specific siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_lofi_arrangementA

Create a full lofi hip-hop arrangement — boom-bap drums + jazzy chords + mellow bass + sleepy melody.

Lofi hip-hop (Nujabes / J Dilla / chillhop) — warm, dusty, mellow:

  • Track 0: Drums — boom-bap: kick on 1 and "and-a" of 2, snare on 2 and 4, laid-back 16th hi-hat with swing. No rush — behind the beat. Vinyl crackle character (lower velocity, humanized).

  • Track 1: Bass — mellow root notes with occasional octave/fifth walks. Long, sustained, warm. No aggression.

  • Track 2: Chords — jazzy 7th/9th voicings (maj7, min9, dom9) with soft attacks and gentle arpeggiation. The harmonic signature of lofi: extended chords, not triads.

  • Track 3: Melody — sparse, sleepy pentatonic phrases. Long notes, space between phrases. The "nodding off" quality.

At 78 BPM (default), this creates the classic chillhop pocket — slow, warm, behind-the-beat. ii-V-I jazz-influenced harmony (Dm7-G7-Cmaj7 in F major) gives that nostalgic, bittersweet quality.

bpm: Tempo (70-90, default 78 = chillhop sweet spot). bars: Arrangement length (4-16, default 8). root: Root note (F is a classic lofi key — warm, midrange). octave: MIDI octave for bass (3 = F3=53, warm lofi bass). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / melody_track: Track indices.

Returns notes created per track and total.

Example: create_lofi_arrangement(bpm=78, root="F", bars=8) create_lofi_arrangement(bpm=82, root="D", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
chord_trackNo
melody_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses the tool's behavior: it creates notes on specific tracks, describes the musical content for each track, and specifies return value (notes per track and total). No contradictions with any structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with bullet points, musical breakdown, and examples. Each part adds value, though it could be slightly more concise. Still efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, 0% schema coverage, no annotations, and an output schema, the description is highly complete: it explains the style, each track's role, parameter details, defaults, ranges, and examples. It covers all necessary context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description explains every parameter with defaults, ranges, and musical context (e.g., 'bpm: Tempo (70-90, default 78)', 'octave: MIDI octave for bass'). This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full lofi hip-hop arrangement' with specific musical details for each track, effectively distinguishing it from sibling tools that create other genres (e.g., create_blues_arrangement). The verb 'create' and resource 'arrangement' are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (for lofi hip-hop arrangements) and provides examples and parameter ranges. While it doesn't explicitly state when not to use it, the context of sibling tools covering other genres implies appropriate usage. Lacks explicit alternatives but still clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_l_system_melodyA

Create a melody using an L-system (Lindenmayer system) — a deterministic rewriting system.

L-systems generate self-similar, fractal patterns through recursive production rules. Each symbol in the expanded string maps to a scale step interval. The cumulative sum of intervals determines the melodic contour.

Unlike Markov chains (stochastic, memory-based) or random walk (zero-order), L-systems are fully deterministic — same axiom + rules + iterations always produce the same melody. This makes them ideal for:

  • Self-similar melodic structures (fractal music)

  • Deterministic generative composition

  • Algorithmic music based on mathematical systems

Presets: fibonacci — Fibonacci word (A->AB, B->A), golden ratio self-similarity cantor — Cantor set (A->ABA, B->BBB), gaps and self-similar structure dragon — Dragon curve (A->A+B, B->A-B), jagged contour koch — Koch snowflake (A->A+A-A-A+A), angular melody sierpinski — Sierpinski triangle (A->BA, B->BA), binary pattern

Custom: provide axiom, rules (JSON), and symbol_map (JSON) to define your own L-system.

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, phrygian, lydian, mixolydian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues). bars: Number of bars (1-32). octave: Starting MIDI octave (1-6). preset: Preset name (fibonacci, cantor, dragon, koch, sierpinski). axiom: Custom axiom string (overrides preset). rules: Custom rules as JSON {"A": "AB", "B": "A"}. symbol_map: Custom symbol-to-interval map as JSON {"A": 1, "B": -1}. iterations: Number of rule applications (1-8). Higher = more complex. duration: Note duration in beats (0.0625-4.0). velocity: Base velocity 0-1. rest_symbol: Symbol that produces a rest (skip note, advance position). unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, L-system string length, and fractal statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
axiomNo
rulesNo
scaleNominor
octaveNo
presetNofibonacci
durationNo
velocityNo
iterationsNo
start_beatNo
symbol_mapNo
unit_indexNo
rest_symbolNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that the tool is deterministic (same axiom+rules+iterations = same melody) and mentions the return value. However, it does not detail side effects (e.g., does it directly modify a track?), error conditions, or behavior for edge cases like invalid rules.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: opening sentence, explanation of L-systems, comparison to other methods, presets list, custom options, then parameter list. It is slightly lengthy but front-loaded with essential information. Every section earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 15 parameters and no output schema, the description covers the tool's purpose, how it works, and most parameter meanings. It mentions return value (notes, string length, statistics) but not exact structure. Overall, it is sufficiently complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It provides an 'Args' section explaining each parameter, including preset names, custom JSON formatting for rules and symbol_map, and typical defaults. Basic parameters like track_index are only glossed, but overall the description adds significant meaning beyond the naked schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a melody using an L-system' and explains the underlying concept. It distinguishes L-systems from Markov chains and random walk by highlighting determinism and self-similarity. Presets and custom options are detailed, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts L-systems with stochastic methods (Markov chains, random walk) and lists ideal use cases (self-similar, deterministic generative composition). It does not explicitly state when not to use it, but the differentiation from siblings is strong enough to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_markov_melodyA

Create a melody using a Markov chain over scale-degree intervals.

First-order (or higher) Markov chain: the next interval depends on the current (or previous N) interval(s) via a transition probability matrix. This produces melodies with stylistic memory — the interval patterns characteristic of a genre or composer emerge naturally.

Unlike random_walk (zero-order: each step independent of history), Markov chains capture interval-to-interval tendencies:

  • A small ascending interval tends to be followed by another small one

  • A large leap tends to be followed by a step back (regression to mean)

  • Specific interval sequences define melodic "style"

The transition matrix can be:

  • Default: built-in weights favoring smooth motion (steps > skips > leaps)

  • Custom: user-provided interval weights as JSON

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, phrygian, lydian, mixolydian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues). bars: Number of bars (1-32). octave: Starting MIDI octave (1-6). order: Markov chain order (1 or 2). Order 1 = depends on current interval. Order 2 = depends on last 2 intervals. interval_weights: JSON string of custom transition weights. If empty, uses built-in weights. Format for order 1: {"-3": {"-3": 0.1, "-2": 0.2, "-1": 0.3, "0": 0.1, "1": 0.2, "2": 0.1}, "-2": {...}, ...} Keys are interval sizes (-7 to +7 scale steps). duration: Note duration in beats (0.0625-4.0). velocity: Base velocity 0-1. seed: PRNG seed for reproducibility. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, transition statistics, and seed.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
seedNo
orderNo
scaleNominor
octaveNo
durationNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo
interval_weightsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It thoroughly explains the Markov chain behavior, order options, transition probabilities, and mention of returns (notes, statistics, seed). No hidden behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, conceptual explanation, contrast, and parameter list. While long, each section adds value and no content is redundant. Could be slightly more concise but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters and complexity, the description covers all behavioral aspects, parameter semantics, and expected outputs. The presence of an output schema further supports completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides detailed explanations for all 12 parameters in the Args section, including default values, formats (e.g., interval_weights JSON example), and allowed ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a melody using a Markov chain over scale-degree intervals.' It explains the concept of Markov chains and contrasts with random_walk, making the unique value proposition evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises when to use this tool (for stylistic memory) and explicitly contrasts with random_walk. It explains the transition matrix options (default vs custom) but does not list other alternatives or explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_melodic_polyrhythmA

Create a polyrhythm — N notes evenly spaced across M beats.

A polyrhythm places numerator notes evenly across denominator beats, creating cross-rhythms against the main pulse. 3:4 = triplet feel, 5:4 = quintuplet, 7:4 = septuplet, 3:2 = half-note triplets.

The notes ascend or descend through the specified scale, creating a melodic polyrhythm rather than just rhythmic hits. This is the foundation of jazz cross-rhythm, prog-rock metric modulation, African cross-pulse, and contemporary classical writing.

Args: unit_index: Audio unit index track_index: Note track index numerator: Number of notes to fit across denominator beats (2-9, default 3). This is the "against" number. denominator: Number of beats to span (2-8, default 4). This is the "base" pulse. bars: Number of times to repeat the polyrhythm cycle (1-8, default 1). pitches: Comma-separated MIDI pitches for custom note selection. If provided, overrides scale-direction generation. Notes cycle through this list. velocity: Base velocity (0-1, default 0.8) velocity_pattern: Velocity across the polyrhythm — "constant": same velocity "accent": accent first note of each cycle "fade": linear fade across all notes "wave": sine wave velocity pattern start_beat: Position in beats where polyrhythm starts (default 0.0) direction: Pitch direction when using scale generation — "up": ascending through scale "down": descending through scale "alternate": up then down per cycle scale: Scale for pitch generation ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues", "chromatic") root: Root note for scale (C, C#, D, ... B)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
scaleNomajor
pitchesNo60
velocityNo
directionNoup
numeratorNo
start_beatNo
unit_indexYes
denominatorNo
track_indexYes
velocity_patternNoconstant

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the tool creates notes that ascend or descend through a scale and provides parameter details like velocity patterns. However, it does not disclose side effects (e.g., whether it overwrites existing notes, if there are prerequisites for track_index, or what happens on error). It also doesn't mention the output schema, though one exists. The description is moderately transparent but could be more explicit about behavioral aspects beyond basic functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a lead sentence defining the purpose, a brief explanatory paragraph, and a clear parameter list. It is front-loaded with the core concept. While it includes some extra context (musical applications), every sentence adds value. It is not overly verbose given the complexity of the tool, but slightly longer than necessary. Score 4 for good structure and efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, no annotations, has an output schema), the description covers the tool's purpose and parameter details well. However, it omits information about the return value (despite an output schema existing), error conditions, prerequisites for using the tool (e.g., track must exist), and idempotency. The musical context is useful but not essential for correct invocation. The description is adequate but incomplete for a fully autonomous agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does so effectively. Each parameter (12 total) is described in a separate line, explaining its purpose, allowed values, defaults, and format (e.g., 'pitches: Comma-separated MIDI pitches' and 'direction: Pitch direction when using scale generation — up/down/alternate'). This adds significant meaning beyond the bare schema. Minor gaps: 'velocity_pattern' enum values are listed but not enumerated in the schema; some defaults are repeated from schema but still helpful. Overall, the param descriptions are thorough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a polyrhythm — N notes evenly spaced across M beats.' It distinguishes this tool from the sibling 'create_polyrhythm' by specifying it creates a 'melodic polyrhythm rather than just rhythmic hits.' The verb 'create' combined with the resource 'melodic polyrhythm' and the specific explanation of cross-rhythms against a main pulse makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context about when this tool is appropriate, mentioning jazz cross-rhythm, prog-rock metric modulation, etc. However, it does not explicitly tell the agent when to use this tool versus alternatives like the sibling 'create_polyrhythm' (which is a non-melodic version). No 'when not to use' guidance is given, so the agent must infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_melodyA

Create a melody from a scale and rhythmic pattern — one call instead of 10-30 create_note calls.

scale: Scale type (major, minor, harmonic_minor, melodic_minor, dorian, phrygian, lydian, mixolydian, locrian, pentatonic_major, pentatonic_minor, blues, chromatic). root: Root note name (C, C#, D, D#, E, F, F#, G, G#, A, A#, B or flats Db, Eb, Gb, Ab, Bb). pattern: Rhythmic pattern using scale degrees. Each step is one 16th note:

  • Numbers 1-7 (or 1-5 for pentatonic, 1-6 for blues) = scale degree (1 = root)

  • 0 = rest

  • '-' = sustain previous note (tie)

  • '+' = octave up for this note

  • Example: "1-2-3-5-4-3-2-1" = ascending then descending scale fragment

  • Example: "1 0 3 0 5 0 3 0" = arpeggio with rests unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the melody starts (0 = bar 1). octave: MIDI octave for the root (4 = C4=60, the middle C). velocity: Note velocity 0-1 (default 0.75).

Returns the total notes created and pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes
scaleYes
octaveNo
patternYes
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that the tool generates notes based on the given parameters, and it returns the total notes created and pitches used. It does not mention side effects like overwriting existing notes or authorization needs, but the behavior is adequately disclosed for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately lengthy but well-structured: a benefit statement followed by parameter explanations and pattern examples. Each sentence adds value, though it could be slightly more concise without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, no annotations, but an output schema exists), the description thoroughly covers all aspects: purpose, parameter details, pattern syntax, and return values. It is complete and leaves no major gaps for an agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description compensates fully. Every parameter (scale, root, pattern, octave, velocity, start_beat, unit_index, track_index) is explained in natural language, including default values and detailed pattern syntax with examples. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a melody from a scale and rhythmic pattern, using a single call instead of 10-30 create_note calls, which distinguishes it from the sibling tool mcp_opendaw_create_note. The verb 'Create' and resource 'melody' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using this tool instead of multiple create_note calls, providing a clear use case. However, it does not contrast with other melody-related sibling tools like create_melody_from_progression or create_counter_melody, so it lacks exclusions for alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_melody_from_progressionA

Create a lead melody from a chord progression string.

Completes the harmonic quartet: create_chord_pads (sustained harmony) + create_arpeggiated_progression (arp movement) + create_bass_from_progression (bass foundation) + THIS (lead melody). All four take the same "Am-F-C-G" string.

The melody hits chord tones on strong beats (1, 3) and uses passing tones or neighbor tones on weak beats (2, 4) for melodic interest.

pattern: Melodic pattern: "chord_tones" — root/third/fifth on beats 1+3, passing tone on 2+4 "sustained" — one chord tone per bar, held for full bar (ballad) "syncopated" — 8th notes, chord tones on downbeats, passing on ups "triadic" — arpeggiated 8ths through chord tones (folk, country) "stepwise" — scale steps between chord tones (pop, classical)

bars_per_chord: Bars per chord (default 4). octave: MIDI octave for melody (5 = C5=72, typical lead range). velocity: Note velocity (0-1, default 0.75). track_index: Track for melody (typically melody track = 3).

Example:

Pop lead from I-V-vi-IV

create_melody_from_progression("C-G-Am-F", pattern="chord_tones", octave=5, track_index=3)

Ballad sustained melody

create_melody_from_progression("Am-F-C-G", pattern="sustained", octave=5, bars_per_chord=4)

Country triadic fiddle

create_melody_from_progression("D-G-A-D", pattern="triadic", octave=5, velocity=0.8)

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
patternNochord_tones
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details the melody generation algorithm (chord/tonal pattern on strong beats, passing tones on weak) and explains each pattern's behavior. However, it doesn't disclose side effects like track creation/modification or return value format, missing some external aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, context, algorithm, parameter details, and examples. Every sentence adds value with no redundancy or fluff, achieving clarity and efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 8 parameters and no annotation, the description covers purpose, usage timing, algorithm, parameter semantics, and provides examples. It is self-contained and complete for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining every parameter's meaning, default values, and typical ranges (e.g., octave=5 for lead, pattern behaviors). Examples further clarify usage, adding high value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a lead melody from a chord progression string, and explicitly distinguishes it from sibling tools by naming the harmonic quartet (create_chord_pads, create_arpeggiated_progression, create_bass_from_progression, THIS).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: as part of the harmonic quartet with shared input format. It provides context but doesn't explicitly state when not to use it or name alternative tools for melody creation (e.g., create_melody), though the quartet framing implies a specific purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_metal_arrangementA

Create a full metal arrangement — double kick drums + palm-muted riffs + power chords + shred lead.

Heavy metal — riff-based, not chord-progression-based:

  • Track 0: Drums — double kick (16th notes on kick), snare on 2+4, crash on bar starts, ride during verses. Blast beat feel at high BPM. The double kick is the heartbeat of metal — relentless.

  • Track 1: Bass — root-following bass, palm-muted style. Follows the riff root notes in steady 8ths. Thick, driving, sits under the guitars like a foundation.

  • Track 2: Rhythm guitar — power chords (root+fifth) with palm-muted 8th note chugging. The classic metal riff approach: low E string pedal tone + power chord stabs. E minor phrygian dominant for that Middle Eastern/exotic metal feel.

  • Track 3: Lead guitar — minor pentatonic + natural minor scale shredding. Fast alternate-picking runs, sweep arpeggios, tapped harmonics simulated via high-register notes. The "shred" quality.

At 160 BPM (default), this is thrash/speed metal territory. At 120 BPM, it's traditional heavy metal (Iron Maiden). At 200+, it's extreme/black metal.

The riff: low E pedal tone + power chord on the off-beat. Phrygian dominant (E-F#-G-A-B-C-D) gives the exotic metal sound (think Metallica, Slayer, Meshuggah). Not I-IV-V — metal is riff-driven, not chord-driven.

bpm: Tempo (100-220, default 160 = thrash metal). bars: Arrangement length (must be multiple of 4, default 8). root: Root note (E is the most common metal key — lowest guitar string). octave: MIDI octave for bass (2 = E2=40, standard metal bass register). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_metal_arrangement(bpm=160, root="E", bars=8) create_metal_arrangement(bpm=120, root="D", bars=16) # traditional metal

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoE
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
chord_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details the musical behavior (what notes are created on each track, patterns, scales). It notes return value ('notes created per track and total'). However, it does not specify whether existing notes on those tracks are overwritten or if the operation is additive, nor does it mention potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bullet points for tracks, clear parameter explanations, and examples. It is slightly verbose but every sentence adds value. It is front-loaded with purpose and provides a mix of technical and musical guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, 0% schema coverage, no annotations), the description covers the arrangement structure, track roles, scale theory, tempo implications, and parameter constraints (e.g., bars must be multiple of 4). It provides examples. Missing is explicit documentation of error cases or idempotency, but the output schema likely covers return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains musical purpose for key parameters (bpm, bars, root, octave, track indices) and provides scale theory. However, parameters like velocity, start_beat, and unit_index are mentioned but not explained in musical context. The example usage partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full metal arrangement' and lists specific components (double kick drums, palm-muted riffs, power chords, shred lead). It distinguishes this tool from other genre-specific arrangement creators among siblings (e.g., create_rock_arrangement, create_blues_arrangement) by its focus on metal and detailed musical characteristics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong usage context by explaining how BPM ranges map to metal subgenres (thrash, traditional, extreme) and gives examples. However, it does not explicitly state when to use this tool versus other arrangement tools or provide 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_metric_modulationA

Create a metric modulation — tempo change that preserves a note-value equivalence.

The defining technique of Elliott Carter, Aaron Copland, John Adams, and progressive rock (Dream Theater, Tool). Unlike a simple tempo change, metric modulation establishes a precise relationship: a specific note value in the new tempo has the same duration as a different note value in the old tempo. The listener perceives a new pulse while the rhythmic fabric remains continuous.

Formula: new_bpm = old_bpm × (new_note_value / old_note_value)

Supported note values:

  • "whole", "half", "dotted_half", "quarter", "dotted_quarter"

  • "quarter_triplet", "eighth", "dotted_eighth", "eighth_triplet"

  • "sixteenth", "dotted_sixteenth", "thirty_second"

Alternatively, pass a ratio like "3:2" (new tempo = 3/2 of old) or "2:3" (new = 2/3 of old) to express the modulation as a simple proportion.

Examples: create_metric_modulation(32, "quarter", "dotted_eighth", old_bpm=120) → new_bpm = 120 × (3/16) / (1/4) = 90 BPM. A dotted eighth at 90 lasts the same as a quarter at 120. create_metric_modulation(16, ratio="3:2", old_bpm=100) → new_bpm = 150. Three notes in new tempo = two in old. create_metric_modulation(48, "eighth", "quarter", old_bpm=140) → new_bpm = 280. Quarter at new tempo = eighth at old (doubling).

Args: position_beats: Beat position where modulation occurs. old_note: Note value in the old tempo (default "quarter"). new_note: Note value in the new tempo that equals old_note's duration (default "dotted_eighth" — classic Carter modulation). old_bpm: Current BPM. If 0, reads from the project's tempo track. ratio: Direct ratio "N:M" — new_bpm = old_bpm × N/M. Overrides old_note/new_note if provided. add_time_signature: Optional new time signature as "N/D" (e.g. "3/4", "6/8"). If provided, also creates a time signature change event at the same position.

Returns old_bpm, new_bpm, ratio, equivalence, and events created.

ParametersJSON Schema
NameRequiredDescriptionDefault
ratioNo
old_bpmNo
new_noteNodotted_eighth
old_noteNoquarter
position_beatsYes
add_time_signatureNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers behavior: it creates tempo modulation events, returns old/new BPM, ratio, equivalence, and events. It includes the formula and note values. However, it does not disclose potential side effects, permissions needed, or whether it modifies existing tempo events. Still, it provides substantial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: starts with purpose, then formula, note values, ratio alternative, examples, and parameter list. It is front-loaded and every sentence provides useful information without repetition. It is detailed yet efficiently organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, 0% schema coverage, and an output schema, the description is exceptionally complete. It covers what the tool does, how to use it, all parameters with defaults, examples, and return values. It also contextualizes the tool within music theory and contrasts with simple tempo changes. No gaps are apparent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains all 6 parameters: position_beats, old_note, new_note, old_bpm, ratio, add_time_signature, including defaults, meanings, and examples. It also lists supported note values and describes the ratio option. This adds immense value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a metric modulation, a tempo change preserving note-value equivalence. It provides the formula, supported note values, and examples, distinguishing it from sibling tools like add_tempo_change or set_bpm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts metric modulation with simple tempo changes, implying when to use it. It explains the precise relationship and gives examples, but does not explicitly list when not to use or mention alternatives. The context is clear but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_midi_echoA

Create MIDI echo — repeat notes with decaying velocity and optional pitch shift.

Takes existing notes from a region and creates echoing repeats. Each repeat is delayed by delay_beats, quieter by velocity_decay factor, and optionally shifted in pitch. This is a creative effect, not a simple copy — think guitar delay throws, synth echo fills, vocal repeat stutters.

feedback_mode:

  • "linear" — each repeat is velocity_decay × previous (0.6 → 0.6, 0.36, 0.216)

  • "exponential" — faster decay, squared each time

  • "constant" — same velocity for all repeats (stutter feel)

  • "reverse" — each repeat gets louder (build-up feel)

pitch_shift: semitones added per repeat (0 = no shift, +12 = octave up each repeat, -5 = perfect fourth down each repeat). Creates cascading echoes.

dest_track: -1 = same track (thickening), N = separate track (layered echo). Using a separate track lets you process the echo independently.

repeats: 1-8 echo repeats. Each repeat copies ALL notes from the source. delay_beats: time between each repeat (0.25 = 16th, 0.5 = 8th, 1.0 = quarter).

unit_index: AU index. track_index: Source note track. region_index: Source region (-1 = first). repeats: Number of echo repeats (1-8). delay_beats: Delay between repeats in beats. velocity_decay: Velocity multiplier per repeat (0-1, 0.6 = 60% each time). pitch_shift: Semitones added per repeat (0 = none). dest_track: Destination track (-1 = same, N = separate track). feedback_mode: linear / exponential / constant / reverse.

Returns echo summary with per-repeat velocity and pitch info.

Example:

Guitar-style echo: 3 repeats, 8th note delay, decaying

create_midi_echo(0, 0, repeats=3, delay_beats=0.5, velocity_decay=0.5)

Cascading octave echoes on separate track

create_midi_echo(0, 0, repeats=4, delay_beats=0.25, pitch_shift=12, dest_track=2)

ParametersJSON Schema
NameRequiredDescriptionDefault
repeatsNo
dest_trackNo
unit_indexYes
delay_beatsNo
pitch_shiftNo
track_indexYes
region_indexNo
feedback_modeNolinear
velocity_decayNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It adequately describes the behavior: taking notes from a region, creating repeats with decaying velocity and optional pitch shift, feedback modes, and dest_track options. Missing details on error handling or prerequisites, but overall sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, parameter explanations, and examples. It is slightly verbose but every sentence adds value; front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex creative tool with 9 parameters and no annotations or output schema provided, the description is highly complete. It explains all parameters, provides examples, and mentions return type. The agent has enough information to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description thoroughly explains each parameter with purpose, default values, and possible values (e.g., feedback_mode options, pitch_shift range). It adds significant meaning beyond the schema's minimal titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create MIDI echo — repeat notes with decaying velocity and optional pitch shift.' It uses a specific verb ('create') and resource ('MIDI echo'), and distinguishes itself by describing it as a creative effect (not a simple copy), contrasting with siblings like copy tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use the tool (creative effect like guitar delay, synth echo) and explains parameter effects with examples, but does not explicitly compare to alternatives among the many sibling tools, lacking when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_modulated_songA

Build a multi-section song with key modulation between sections — one call.

Each section has its own chord progression, length (bars), and energy (velocity multiplier). The tool automatically modulates between keys by using different progressions per section — no manual start_beat calculation needed.

sections: Comma-separated section specs. Each section format: name:progression:bars:energy

  • name: section label (verse, chorus, bridge, outro, etc.)

  • progression: chord progression string (e.g. "Am-F-C-G")

  • bars: total bars for this section

  • energy: velocity multiplier (0.0-1.0, relative to base velocity)

Default creates a 24-bar song: verse (Am-F-C-G, 8 bars, 0.7) → chorus (C-G-Am-F, 8 bars, 1.0) → bridge (F-C-Dm-G, 4 bars, 0.6) → outro (Am-F-C-G, 4 bars, 0.5)

The chorus modulates to C major (relative major of A minor), the bridge modulates to F (up a fourth), and the outro returns to Am.

arp_pattern/bass_pattern/melody_pattern/counter_melody_pattern: Same as create_harmonic_arrangement. Applied to all sections. Use "" to skip any layer.

drum_genre: If set (e.g. "house", "dnb", "synthwave"), creates a genre drum arrangement for the full song length BEFORE harmonic layers. When drum_genre is set, pads and bass are automatically skipped in harmonic sections (genre arrangement provides them). Default "" = no drums (harmony only). Valid: dnb, liquid_dnb, house, trap, techno, dubstep, afrobeat, rock, jazz, pop, funk, reggae, synthwave, trance, disco.

bpm: Tempo for drum arrangement (None = genre default). Only used when drum_genre is set.

Example:

Default 4-section modulated song (harmony only)

create_modulated_song()

With house drums

create_modulated_song(drum_genre="house", bpm=124)

With synthwave drums + counter-melody

create_modulated_song(drum_genre="synthwave", counter_melody_pattern="contrary")

Simple verse-chorus with DnB drums

create_modulated_song("verse:Em-G-D-C:8:0.7,chorus:G-D-Em-C:8:1.0", drum_genre="dnb")

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
sectionsNoverse:Am-F-C-G:8:0.7,chorus:C-G-Am-F:8:1.0,bridge:F-C-Dm-G:4:0.6,outro:Am-F-C-G:4:0.5
velocityNo
drum_genreNo
unit_indexNo
arp_patternNoup
bass_patternNoroot
melody_patternNochord_tones
counter_melody_patternNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears the full burden of behavioral disclosure. It explains that the tool auto-modulates between keys, that drum_genre skips pads and bass in harmonic sections, and that default values produce a specific structure. It does not explicitly mention whether the tool overwrites existing tracks or if it is destructive, but the overall behavioral traits are well-covered for a generative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections for parameters, examples, and default behavior. It front-loads the primary purpose. While relatively long, every sentence adds value. Minor verbosity could be trimmed (e.g., repeating modulation examples), but overall it is efficient for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters (0 required) and an output schema, the description covers all relevant aspects: sections formatting, default values, modulation logic, drum genre behavior, pattern inheritance, and usage examples. The output schema exists, so return value details are unnecessary. The description is complete enough for an agent to use the tool correctly without confusion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 0%, so the description must compensate. It thoroughly explains the 'sections' parameter with a clear format and examples, details each pattern parameter (arp, bass, melody, counter_melody), and describes 'drum_genre' and 'bpm' with valid genre list and usage notes. The description adds significant meaning beyond the schema by providing default values, behavior context, and examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Build a multi-section song with key modulation between sections — one call.' It clearly indicates a specific verb (build), resource (multi-section song), and key feature (key modulation). The description distinguishes itself from sibling tools like 'create_harmonic_arrangement' by referencing pattern parameters and by offering a higher-level structure building capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (for multi-section songs with auto-modulation, avoiding manual start_beat calculation). It provides context by mentioning that arp_pattern/bass_pattern etc. are 'same as create_harmonic_arrangement,' helping the agent understand the relation. However, it does not explicitly state when NOT to use this tool or describe limitations that would point to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_montunoA

Create a montuno — a repeating Latin/jazz piano ostinato pattern.

A montuno is a 2-bar (or 4-bar) repeating piano figure central to son, salsa, Latin jazz, and mambo. It consists of syncopated chord stabs and single-note passages that lock with the clave, creating a driving, danceable groove.

Unlike arpeggiators (which cycle through chord tones mechanically) or ostinato patterns (which repeat a fixed melodic cell), a montuno combines:

  • Harmonic movement through a chord progression

  • Syncopated rhythm locked to the clave

  • Alternation between chord stabs and melodic passage notes

  • Call-and-response phrasing within each bar

Pattern types: 2-3 — Classic 2-3 clave montuno (2-side in bar 1, 3-side in bar 2) 3-2 — Reverse clave (3-side first, 2-side second) guajira — Cuban guajira montuno (gentler, dotted rhythm feel) charanga — Charanga-style (more melodic, flowing passages)

Rhythm: 8th — Eighth-note based (standard salsa) 16th — Sixteenth-note based (faster, busier) quarter — Quarter-note based (simpler, mambo style)

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, mixolydian, harmonic_minor). bars: Number of bars (2 or 4). Montunos are typically 2-bar cycles. octave: Starting MIDI octave (2-6). chord_prog: Comma-separated chord progression (e.g., "C,Am,Dm,G"). If empty, generates a I-vi-IV-V progression in the key. pattern: Pattern type (2-3, 3-2, guajira, charanga). rhythm: Rhythm subdivision (8th, 16th, quarter). velocity: Base velocity 0-1. accent_beats: Comma-separated beat numbers to accent (1-indexed). unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, chord progression, and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
scaleNomajor
octaveNo
rhythmNo8th
patternNo2-3
velocityNo
chord_progNo
start_beatNo
unit_indexNo
track_indexNo
accent_beatsNo1,3

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior fully. It explains what a montuno is, pattern types, rhythm options, and return value data. However, it does not mention side effects (e.g., whether it overwrites existing notes), performance impact, or error conditions. The disclosure is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with clear sections (definition, comparison, pattern types, rhythm, args). Each sentence adds value; however, some repetition could be trimmed. Overall, the structure aids readability without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, multiple pattern types, rhythm options) and the existence of an output schema, the description covers the key aspects: creation, parameter meanings, return value summary. It could mention default chords or typical use cases more, but is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 12 parameters with 0% description coverage. The description lists every parameter with its meaning, examples, defaults, and in some cases allowed values (pattern types, rhythm subdivisions). This adds substantial meaning beyond the schema and fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a montuno pattern, defines what a montuno is, and explicitly distinguishes it from arpeggiators and ostinato patterns. The verb 'create' and resource 'montuno' are specific, and the description differentiates from siblings by focusing on Latin/jazz piano ostinato patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for Latin/jazz piano patterns) and contrasts with arpeggiators and ostinatos, providing context. However, it does not explicitly state when not to use it or compare with specific sibling tools, though the contrast helps guide usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_mordentA

Create a mordent — main note → neighbor → back. A classical ornament.

The mordent is one of the four essential baroque ornaments (trill, mordent, turn, appoggiatura). It's a rapid single alternation: play the main note briefly, flick to a neighbor note, then return to the main note — all within the space of one note duration. Think Bach two-part inventions, Mozart sonatas.

An upper mordent flicks UP (main → upper neighbor → main). A lower mordent flicks DOWN (main → lower neighbor → main). The neighbor note is very short — just a flicker.

main_pitch: The primary MIDI note (default 60 = C4). direction: "upper" (main→higher→main) or "lower" (main→lower→main). interval: Semitones to the neighbor note (default 2 = whole step). Upper: 1 = half step (diatonic), 2 = whole step. Lower: -1, -2 mirror. duration_beats: Total length of the mordent in beats (0.25-4, default 0.5 = one 8th). velocity: Base velocity 0-1 (default 0.85). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the mordent begins.

Returns notes created, pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNo
velocityNo
directionNoupper
main_pitchNo
start_beatNo
unit_indexNo
track_indexNo
duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It thoroughly explains the musical behavior: rapid single alternation, flick to neighbor, return, duration within one note. It notes the return value but does not address potential side effects (e.g., overwriting existing notes) or authorization needs. Overall, it adds significant context beyond the mute annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with paragraphs and bullet-like parameter explanations, but it is longer than necessary. Some sentences (e.g., 'Think Bach two-part inventions, Mozart sonatas') add context but could be trimmed for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters, no annotations, and an output schema (not detailed), the description covers musical behavior and parameter semantics thoroughly. It mentions the return value. However, it lacks information about prerequisites (e.g., existence of a track) and does not leverage any output schema details. Overall, it is adequate but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so excellently, providing clear explanations for all 8 parameters: main_pitch, direction, interval, duration_beats, velocity, unit_index, track_index, start_beat. Each parameter is described with defaults and interpretation, adding meaning far beyond the schema's titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a mordent, defines it as a classical ornament, and distinguishes upper from lower mordents. It differentiates from siblings like create_appoggiatura, create_trill, and create_turn by specifying the ornament type and musical behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives stylistic context ('Bach two-part inventions, Mozart sonatas') but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or comparisons with related ornament tools, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_motif_developmentA

Develop a motif into a through-composed melodic line that evolves.

Takes a short motif (2-8 notes) and builds a continuous melodic line that develops through compositional stages: statement, sequential repetition (up/down), fragmentation (shorter segments), inversion, octave displacement, and cadence. This is the Beethoven 5th approach — a 4-note seed grows into an entire melodic arc.

Unlike create_variations (separate regions, each a full transformation), create_motif_development writes ONE continuous line that flows through stages without stopping. Unlike create_sequence (pure transposition), this tool mixes multiple development techniques in sequence.

motif: Comma-separated scale degrees (1-7) or MIDI pitches. Scale degrees: 1=root, 2=2nd, 3=3rd, etc. 0=rest. MIDI pitches: 60,62,64,65 etc (when use_midi=true implicit if >7). Example: "1,1,1,2" or "60,60,60,62" scale: Scale type (major, minor, harmonic_minor, dorian, etc.). root: Root note name (C, D#, Bb, etc.). octave: MIDI octave for root (4 = C4=60). steps: Comma-separated development stages: "statement" — play motif as-is "sequence_up" — transpose up by a 4th (5 semitones) "sequence_down" — transpose down by a 4th "fragment" — play first half of motif "fragment_end" — play second half of motif "invert" — invert around root pitch "octave_up" — shift up one octave "octave_down" — shift down one octave "expand" — double note durations "compress" — halve note durations "cadence" — resolve to root (scale degree 1, longer duration) step_duration: Duration of each note in beats (0.25 = 16th). velocity: Base velocity 0-1. unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the development starts.

Returns total notes, stage count, pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoA
motifYes
scaleNominor
stepsNostatement,sequence_up,sequence_down,fragment,invert,sequence_up,fragment,octave_up,cadence
octaveNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo
step_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains the process (stages, continuous line) and notes that it writes one continuous line. It could mention whether it modifies existing data or creates new, but the description is fairly transparent for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, then detailed explanations. It front-loads the purpose and uses bullet points for parameters. While slightly long, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, generative process) and the presence of an output schema, the description covers input, process, and output (returned metrics) completely. It leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains every parameter in detail, including motif formats (scale degrees or MIDI, with examples), step options, and defaults. This is exemplary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (develop), resource (motif), and output (through-composed melodic line). It explains the compositional stages and distinguishes from siblings like create_variations and create_sequence, which enhances purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (to evolve a short motif into a continuous line) and when not (if separate regions are needed, use create_variations; if pure transposition, use create_sequence). This helps the agent select correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_motif_variationsA

Extract a motif from existing notes and create a variation in a new region.

Closes the analysis→creation loop: extract_motifs finds repeating patterns, this tool takes a specific motif and transforms it using classical composition techniques. The motif is identified by start_note index and note_count within the source region.

Variation types:

  • sequence: repeat the motif shifted up/down by N scale steps or semitones. Creates melodic sequences — the backbone of classical and jazz improvisation.

  • inversion: flip the contour upside down. C→E→G (+4, +3) becomes C→A→F (-3, -2). The intervals are mirrored around the first note.

  • retrograde: play the motif backwards. Last note first, first note last. The rhythm and pitches are reversed in time.

  • augmentation: stretch all durations by a factor (2.0 = twice as slow). Creates grand, expansive statements from quick motifs.

  • diminution: compress all durations by a factor (2.0 = twice as fast). Creates urgency and energy from slow motifs.

  • fragmentation: take the first N notes of the motif and repeat them. Creates rhythmic ostinatos from melodic material.

Essential for: developing melodic material, building variations, creating thematic development, and extending motifs into new sections.

source_unit/track/region: Location of the source motif. start_note: Index of the first note of the motif within the source region (0-based, sorted by position). note_count: Number of notes in the motif (3-16). target_unit/track/region: Where to write the variation. -1 = create new track/region automatically. variation_type: sequence, inversion, retrograde, augmentation, diminution, fragmentation. sequence_shift: For sequence type — semitones to shift each repetition. augmentation_factor: For augmentation/diminution — duration multiplier. fragment_count: For fragmentation — how many notes to keep from the start.

Returns the created variation with note details.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_countNo
start_noteNo
source_unitNo
target_unitNo
source_trackNo
target_trackNo
source_regionNo
target_regionNo
fragment_countNo
sequence_shiftNo
variation_typeNosequence
augmentation_factorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description details each variation type, non-destructive creation in a new region, and return value. It omits error handling but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections for purpose, variation types, and parameters. It is slightly verbose but each part adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters) and existence of output schema, the description covers core functionality, use cases, and parameter details adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema coverage is 0%, the description fully explains all 12 parameters with clear meanings, including variation-specific ones like sequence_shift, augmentation_factor, and fragment_count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it extracts a motif and creates a variation in a new region. It uses specific verbs and distinguishes from sibling tools like extract_motifs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains it closes the analysis→creation loop and positions itself after extract_motifs. It also lists use cases but lacks explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_mute_automationA

Create timed mute/unmute automation events on an audio unit.

Essential for section dynamics: mute drums during breakdowns, unmute for drops, create structural silences. Each event is a (beat, mute_state) pair — mute at beat X, unmute at beat Y. Replaces multiple set_track_mute calls with one automation track that plays back predictably every time.

unit_index: AU index to automate mute on. events: JSON array of [beat, muted] pairs. beat = position in beats, muted = true (silence) or false (audible). Example: [[0, false], [16, true], [24, false]] = audible 0-16, muted 16-24, audible 24+

Returns events created, mute schedule, and track index.

Examples: create_mute_automation(unit_index=0, events='[[0,false],[16,true],[24,false]]') → Drums audible for 16 beats, muted for 8 (breakdown), back on at 24 create_mute_automation(unit_index=2, events='[[0,true],[8,false]]') → Bass silent for intro, kicks in at beat 8

ParametersJSON Schema
NameRequiredDescriptionDefault
eventsYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description fully shoulders behavioral disclosure. It explains the event format, return data (events created, mute schedule, track index), and notes that the automation track 'plays back predictably every time,' implying idempotent behavior. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact yet comprehensive: purpose, context, parameter descriptions, return summary, and two practical examples. Each sentence serves a distinct purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description still explains return values, which is helpful. It covers all essential aspects: what the tool does, when to use it, how to configure parameters (with examples), and what to expect back. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides essential detail: unit_index as 'AU index' and events as a JSON array of [beat, muted] pairs with a clear example. This surpasses the schema's minimal information, enabling correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource statement: 'Create timed mute/unmute automation events on an audio unit.' It immediately distinguishes itself from the sibling tool set_track_mute by framing this as a batch automation track approach, providing a specific scope and use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly situates usage in section dynamics ('mute drums during breakdowns, unmute for drops') and contrasts with multiple set_track_mute calls. It gives concrete when-to-use guidance but doesn't explicitly state when not to use it or list other alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_neurofunk_arrangementA

Create a full neurofunk DnB arrangement — 4 tracks: drums + sub-bass + Reese + stabs.

Neurofunk (Noisia, Spor, Phace, Ed Rush & Optical) is the technically advanced evolution of drum & bass — darker, more complex, with signature sound design elements:

  • 170-180 BPM, dark minor key (typically F or E minor)

  • Complex chopped breakbeats with extra ghost notes, kicks, and rolls

  • Reese bass: detuned saw layers with movement, the hallmark neurofunk sound

  • Sub-bass underneath the Reese for low-end weight

  • Dark minor chord stabs and sci-fi atmosphere

  • Aggressive velocity, tight quantization with occasional swing

Creates 4 tracks:

  1. Drums (drum_track): Complex amen break with extra kick placements, ghost notes, and snare rolls at phrase ends. 2-bar cycle.

  2. Sub-bass (bass_track): Deep sustained sub following root note, syncopated gaps where drums fill. Octave 1 for sub weight.

  3. Reese (reese_track): Detuned saw-style Reese bass with chromatic movement, pitch slides, and rhythmic stabs. The signature neuro sound.

  4. Stabs (stabs_track): Dark minor chord stabs (root + b3 + b5 + b7) on beats 1 and 3, with occasional off-beat sci-fi stabs.

bpm: Tempo (160-185, default 174). bars: Arrangement length (4-32, default 8). root: Root note (default F = classic neurofunk key). octave: MIDI octave for Reese/bass (2 = C2=36).

Returns notes created per track and total.

Example: create_neurofunk_arrangement(bpm=174, root="F", bars=8) create_neurofunk_arrangement(bpm=180, root="E", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
reese_trackNo
stabs_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must rely on itself. It explains the output structure (4 tracks with musical content) and notes that it returns notes per track and total. However, it does not disclose operational details such as whether it creates new tracks, overwrites existing ones, or requires specific permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose, including extensive genre background and track details that may be extraneous for a quick understanding. It is front-loaded with the main purpose but would benefit from a more structured format, such as bullet points for parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a good musical overview but lacks operational context (e.g., track creation behavior, conflict handling). With an output schema present, the return value mention is adequate, but the tool's interaction with existing project state is unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description covers only 4 of 11 parameters (bpm, bars, root, octave) with ranges and defaults. The remaining 7 parameters (e.g., velocity, track numbers) are not described, and the schema provides only titles and defaults. Given the low coverage, the description adds some value but is incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a full neurofunk DnB arrangement — 4 tracks: drums + sub-bass + Reese + stabs.' It also provides genre context and differentiates from siblings by focusing on neurofunk, a specific subgenre of drum and bass.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (for neurofunk DnB), including tempo range and key recommendations. However, it does not explicitly state when not to use it or compare it to sibling arrangement tools like create_dnb_arrangement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_noteA

Create a MIDI note on a note track.

pitch: MIDI note number (60 = C4, 69 = A4). start_beat: beat position. duration_beats: note length in beats. velocity: 0.0-1.0. unit_index: Audio unit index (-1 = search all AUs for note tracks). track_index: Note track index within the AU.

If no clip exists on the track yet, one is auto-created. Notes are added to the first clip on the track.

ParametersJSON Schema
NameRequiredDescriptionDefault
pitchYes
velocityYes
start_beatYes
unit_indexYes
track_indexYes
duration_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the auto-creation of clips and that notes are added to the first clip. However, it does not mention error conditions, what happens with multiple clips, or return value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose first, then parameter list with bullet-like clarity, followed by behavioral notes. Every sentence provides value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks information about the return value or output schema, which is listed as existing but not described. For a creation tool, this is a notable gap. Additionally, it does not cover edge cases like invalid parameter values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description explains each parameter with examples (e.g., pitch: 60 = C4) and ranges (velocity: 0.0-1.0). It adds significant meaning beyond the schema's type and name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Create a MIDI note on a note track,' clearly stating the action and resource. This differentiates it from sibling tools like 'create_notes_batch' (batch creation) and 'create_note_clip' (clip creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides parameter details and mentions automatic clip creation, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is implied but lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_note_clipA

Create a note clip in the session view (clip launcher).

Note clips are the session-view counterpart to note regions. They contain a NoteEventCollection and can be triggered independently in the clip launcher.

unit_index: Audio unit index (-1 = search all AUs for note tracks). track_index: Note track index within the AU. clip_index: Slot index in the clip launcher (0, 1, 2, ...). name: Display name for the clip. hue: Color hue 0-360 (-1 = auto from track type).

Returns clip UUID and index.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
nameYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It mentions return values but omits critical details like overwrite behavior for existing clip at the same slot, whether the track must pre-exist, error handling for invalid indices, and any side effects (e.g., triggering playback). This leaves significant gaps for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise, using two paragraphs: one for conceptual overview and one for parameter listing. It avoids unnecessary detail but could be more structured (e.g., bullet points). Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no annotations, the description covers basic parameter meanings and return value but lacks behavioral context (overwrite/error handling, prerequisites). Output schema exists but is not detailed here; the description mentions return value briefly, which is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description effectively explains all 5 parameters with ranges and meanings (e.g., unit_index=-1 searches all AUs, clip_index slot indices, hue auto color). However, it does not address ambiguity when unit_index=-1 and multiple AUs have note tracks, or the relationship between unit_index and track_index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a note clip in the session view (clip launcher), distinguishes it from note regions (arrangement view counterpart), and explains its purpose as containing NoteEventCollection for independent triggering. This differentiates it from sibling tools like create_note or create_audio_clip.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for session view clip launcher but lacks explicit guidance on when to use this tool versus alternatives like create_note_track or create_audio_clip. No when-not-to-use or prerequisite information is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_notes_batchA

Create multiple MIDI notes in a single call — batch creation for melodies, chords, arpeggios.

notes: JSON array of note objects, each with:

  • pitch (int): MIDI note number (60 = C4, 69 = A4)

  • start (float): beat position

  • duration (float): note length in beats

  • velocity (float, optional): 0.0-1.0, default 0.8

Example: '[{"pitch":60,"start":0,"duration":0.5},{"pitch":64,"start":0.5,"duration":0.5},{"pitch":67,"start":1,"duration":1}]'

All notes go into one region on the specified note track. If no region exists, one is created. Faster than calling create_note repeatedly — one round-trip, one editing.modify() block.

ParametersJSON Schema
NameRequiredDescriptionDefault
notesYes
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full transparency burden. It discloses that all notes go into one region, creates a region if needed, and uses a single editing block. However, it omits details on how 'unit_index' and 'track_index' parameters affect behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, uses bullet points for clarity, includes an example, and is concise with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers core functionality, usage guidance, and behavioral traits well. However, it omits explanations for two parameters, and doesn't mention error handling or limits on note count. Output schema exists, so return values are not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate but only details the 'notes' parameter (structure, optional fields, default velocity). It provides an example. The other two parameters ('unit_index', 'track_index') are not explained at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates multiple MIDI notes in a single call, explicitly for batch creation of melodies, chords, and arpeggios. It distinguishes itself from the sibling tool 'create_note' by highlighting efficiency gains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance by contrasting with repeated calls to 'create_note', emphasizing round-trip efficiency. However, it lacks explicit when-not-to-use or alternative sibling tools for specialized patterns.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_note_trackA

Create a new note/MIDI track on an audio unit.

unit_index: Audio unit index. Use -1 (default) for the primary audio unit, or specify an instrument AU index that contains a synth device (Vaporisateur, Nano, etc).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the parameter behavior but does not mention side effects, prerequisites, or whether the operation is destructive. Missing behavioral context for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second explains parameter. No wasted words, front-loaded. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, return values are covered. However, the description lacks details on prerequisites, error conditions, and what exactly 'create a new track' entails (e.g., does it always succeed?). Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning to the single parameter unit_index beyond the schema (which has 0% coverage), explaining the default -1 and how to use it for instrument AUs. This compensates for lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a new note/MIDI track on an audio unit, using specific verbs and resource. It distinguishes from sibling tools like create_instrument_track, create_audio_track, etc., by specifying 'note/MIDI track'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on the unit_index parameter (use -1 for primary, specify instrument AU index) but does not explicitly state when to use this tool vs. other track creation tools or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ostinatoA

Create an ostinato — a repeating melodic/rhythmic pattern as a foundation layer.

Ostinatos are short patterns (2-8 notes) that repeat throughout a section, providing a rhythmic/harmonic anchor. Common in minimalism, electronic, and film music.

scale: Scale type (major, minor, dorian, phrygian, etc. — 14 types from music_theory). root: Root note name (C, C#, D, ... B). pattern: Scale degrees as space-separated numbers (1-7, 0=rest): "1 5 3 5" — repeating i-v-iii-v pattern "1 3 5 6 5 3" — longer melodic cell repeats: Number of times to repeat the pattern (1-16). octave: Starting octave (1-7, default 4). velocity: Note velocity 0-1.

Returns total notes created and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes
scaleYes
octaveNo
patternYes
repeatsNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states the return value (total notes and pattern info) but does not disclose whether the operation is destructive, requires specific permissions, or has rate limits. Since it creates new content, it is likely nondestructive, but the lack of explicit behavioral details results in a score of 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a definition of the output, usage context, then a parameter list with examples. It is somewhat lengthy but each sentence adds value. It front-loads the purpose. Could be slightly more concise, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, 3 required, and an output schema, the description covers the musical concept and key parameters. It does not detail behavior like placement or conflict resolution, but defaults and the return value provide enough context for correct invocation. The description is complete enough for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It provides clear explanations for required parameters (root, scale, pattern) with examples (e.g., '1 5 3 5' for pattern). It also describes optional parameters like repeats, octave, and velocity. However, it does not explain start_beat, unit_index, or track_index, which are likely technical but have defaults. Overall, good parameter explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's purpose: creating an ostinato, a repeating melodic/rhythmic pattern. It explains what an ostinato is and its musical context. The tool name and description align perfectly, and the description distinguishes this from other create_* tools by specifying the nature of the output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use this tool: for short repeating patterns as a foundation layer, common in minimalism, electronic, and film music. This helps an agent decide. However, it does not explicitly mention alternative tools (e.g., create_ground_bass, create_passacaglia) or when not to use it, but the guidance is sufficient for most cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_pan_sweepA

Create a panning automation sweep — move signal from left to right (or vice versa) over time.

Classic stereo movement technique for intros, guitar solos, EDM builds, and section transitions. Creates panning automation events on the AU's panning parameter, sweeping from one position to another. Uses linear curve by default (panning is already psychoacoustic, exp not needed).

unit_index: AU index. start_beat: Start position in beats. duration_beats: Sweep length in beats (default 8 = 2 bars). start_pan: Starting pan position -1.0 (full left) to 1.0 (full right). Default -1. end_pan: Ending pan position -1.0 to 1.0. Default 1 (full sweep L→R). curve: "linear" (default — even stereo movement), "exp" (accelerating), "log" (decelerating). steps: Number of automation points (default 24 = smooth).

Returns events created, pan range, and preview.

Examples: create_pan_sweep(unit_index=0, duration_beats=16) → 16-beat full L→R pan sweep, linear create_pan_sweep(unit_index=2, start_pan=0.5, end_pan=-0.5, duration_beats=4) → Quick 4-beat R→L sweep from half-right to half-left

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNolinear
stepsNo
end_panNo
start_panNo
start_beatNo
unit_indexYes
duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that the tool creates automation events on the AU's panning parameter, defaults to linear curve, and clarifies psychoacoustic reasoning. Mentions shape options and steps. Lacks details on undoability or side effects, but sufficient for typical use.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Highly concise and well-structured: first line defines purpose, then usage context, parameter explanations, and examples. Every sentence adds value, with no redundancy. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (7 parameters), no annotations, and presence of output schema, the description covers all essential aspects: purpose, parameter semantics, return values (events created, pan range, preview), and examples. It is fully sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description thoroughly explains each parameter: unit_index, start_beat, duration_beats, start_pan, end_pan, curve, steps, including ranges, defaults, and examples. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Create' and the resource 'panning automation sweep', explains the effect of moving signal over time. It includes usage contexts (intros, guitar solos, EDM builds) and examples, distinguishing it from sibling tools like create_filter_sweep or create_volume_fade.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context: 'Classic stereo movement technique for intros, guitar solos, EDM builds, and section transitions.' However, it does not explicitly mention when not to use this tool or name alternatives, though the context implies its appropriateness.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_passacagliaA

Create a passacaglia — repeating bass ostinato with evolving harmonies above.

A foundational Baroque form (Bach BWV 582, Buxtehude) adapted to modern contexts (film scoring, metal, electronic). A short bass pattern (4-8 notes) repeats throughout while chords or arpeggiations evolve above it, creating cumulative tension. Distinct from ostinato (single repeating pattern), pedal_point (single sustained note), and bordun (drone chord).

bass_pattern: Space-separated MIDI pitches for the bass ostinato (e.g. "36 43 41 36" = C2 G2 F2 C2). Default is a classic descending bass. bass_rhythm: Space-separated durations in beats matching bass_pattern (e.g. "1 1 1 1" = quarter notes, "0.5 0.5 1 2" = syncopated). bass_repeats: How many times the bass pattern repeats (1-16, default 4). chord_pattern: Comma-separated chord names for the upper voices (e.g. "Cm,Ab,Eb,Bb"). Supports: maj, min, m7, maj7, dom7, sus2, sus4, dim, aug. If fewer chords than repeats, chords cycle. chord_octave: Octave for chord notes (1-8, default 4). variation_style: How upper harmonies are voiced — "block" (sustained chords), "arpeggiated" (broken chord pattern), "melodic" (stepwise counter-melody). beats_per_bar: Time signature beats (3/4=3, 4/4=4, 6/8=6, default 4). bass_velocity: Velocity of bass notes (0-1, default 0.75). chord_velocity: Velocity of chord/variation notes (0-1, default 0.55). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the passacaglia begins.

Returns notes created, bass pattern length, total bars, variation style.

ParametersJSON Schema
NameRequiredDescriptionDefault
start_beatNo
unit_indexNo
bass_rhythmNo1 1 1 1
track_indexNo
bass_patternNo36 43 41 36
bass_repeatsNo
chord_octaveNo
bass_velocityNo
beats_per_barNo
chord_patternNoCm,Ab,Eb,Bb
chord_velocityNo
variation_styleNoblock

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the internal behavior (repeating bass pattern, evolving harmonies, variation styles) and output (returns notes created, etc.). Lacks details on error handling or invalid input, but is thorough for a creative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with upfront purpose, historical context, differentiation, and detailed parameter list. A bit verbose but well-organized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers musical form, parameter details, return values, and usage context. No annotations exist, but the description fully compensates. Suitable for a 12-parameter tool with no required inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Provides extensive parameter descriptions with examples, defaults, and supported values (e.g., MIDI pitches, chord types, velocity ranges). Adds significant meaning beyond the schema titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool creates a passacaglia with a specific verb+resource structure. Differentiates from related forms like ostinato and pedal_point, providing historical and modern context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly distinguishes this tool from siblings (ostinato, pedal_point, bordun) with a direct comparison. Describes the musical context and appropriate usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_pedal_pointA

Create a pedal point — sustained bass tone under changing chords.

A foundational technique in film scoring (Hans Zimmer drones), organ preludes (Bach), and rock ballads. A single low note sustains (or retriggers) while chords change above it, creating harmonic tension and release. The pedal anchors the harmony while the chords create movement.

pedal_pitch: Sustained bass note (default 36 = C2, low and powerful). chord_pattern: Comma-separated chord names (e.g. "Cm,Ab,Eb,Bb"). Supports: maj, min, m7, maj7, dom7, sus2, sus4, dim, aug. bars_per_chord: Bars each chord lasts (1-8, default 1). beats_per_bar: Time signature beats (3/4=3, 4/4=4, 6/8=6, default 4). pedal_velocity: Velocity of pedal note (0-1, default 0.75). chord_velocity: Velocity of chord notes (0-1, default 0.6). chord_octave: Octave for chord notes (1-8, default 4 = C4 range). retrigger_pedal: If true, pedal re-triggers at each chord change. If false, one long sustained note for the entire duration. unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the pedal point begins.

Returns notes created, chord count, pedal duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
start_beatNo
unit_indexNo
pedal_pitchNo
track_indexNo
chord_octaveNo
beats_per_barNo
chord_patternNoCm,Ab,Eb,Bb
bars_per_chordNo
chord_velocityNo
pedal_velocityNo
retrigger_pedalNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the tool creates notes and returns a summary, but does not disclose whether it overwrites existing notes, requires specific track setup, or has performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a clear definition, musical context, then parameter details. It is somewhat verbose for the parameter section but remains readable and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers input parameters well but lacks details on output format (beyond a brief mention) and error handling. No output schema is provided, and behavioral gaps (e.g., overlapping notes) remain unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates thoroughly by explaining all 11 parameters with defaults, supported chord types, and behavioral options like retrigger_pedal. This adds significant meaning beyond the schema's bare titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a pedal point with a sustained bass tone under changing chords. It provides musical context but does not explicitly differentiate from sibling tools like create_ostinato or create_bassline, so sibling distinction is implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context (film scoring, organ preludes, rock ballads) implying when to use it, but lacks explicit guidance on when not to use or alternatives. No mention of prerequisites or compared tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_phase_shiftA

Create a phase-shifted copy of a region — Steve Reich phasing.

Copies the source phrase and places it on a parallel track (or cross-track) with a gradually accumulating time offset. Each bar, the copy shifts by shift_per_bar beats, creating the classic "slipping" phase pattern of minimalism.

Steve Reich's "It's Gonna Rain", "Piano Phase", and "Clapping Music" use this technique. Also the foundation of techno loop phasing, ambient drift, and IDM polyrhythmic evolution.

Unlike displace_rhythm (single fixed offset), phase_shift creates a SECOND copy that drifts further each bar — the two streams start in unison and gradually separate.

Args: unit_index: Audio unit index track_index: Note track index with source phrase region_index: Region index (-1 = first region) shift_per_bar: Time shift per bar in beats (0.03125-0.5, default 0.0625 = 1/16 note per bar). Smaller = slower drift, larger = faster separation. bars: Number of bars to generate (2-16, default 8). Each bar is one repeat of the source phrase with cumulative offset. direction: Phase drift direction — "forward": copy moves later each bar (lags behind) "backward": copy moves earlier each bar (anticipates) cross_track: If >= 0, place the phased copy on this track. If -1 (default), creates a new track on the same AU for the copy. Recommended: use cross_track for explicit control. velocity_scale: Velocity multiplier for the phased copy (0.1-1.0, default 0.85 — slightly softer to distinguish from the original).

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
directionNoforward
unit_indexYes
cross_trackNo
track_indexYes
region_indexNo
shift_per_barNo
velocity_scaleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes creation of a second copy, placement on parallel/cross-track, gradual drift per bar, direction, and parameter effects. Does not explicitly state side effects (e.g., track creation implications) or permission needs, but sufficiently transparent for a non-destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: starts with title sentence, then explanation of effect, historical context, sibling contrast, then detailed parameter list. Each sentence adds value. Slightly verbose but not wasteful; could be trimmed slightly but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (8 parameters, specific phasing technique), the description covers concept, parameters, and sibling differentiation well. Output schema exists, so return values not needed. Missing edge cases like error handling or restrictions, but overall adequate for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully explains all 8 parameters with ranges, defaults, examples, and recommended values. Adds meaning beyond the schema's titles and types, covering unit_index, track_index, region_index, shift_per_bar, bars, direction, cross_track, and velocity_scale.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a phase-shifted copy using Steve Reich phasing, with a specific verb 'Create' and resource 'phase-shifted copy of a region'. It explicitly distinguishes itself from the sibling 'displace_rhythm' by contrasting single fixed offset versus gradually drifting copy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use this tool (for gradual phase shifting) and explicitly contrasts with 'displace_rhythm' as an alternative. Includes recommendations for the cross_track parameter. However, no explicit 'when not to use' or list of scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_phonk_arrangementA

Create a full drift phonk arrangement — 3 tracks: drums + 808 + cowbell lead.

Drift phonk (Kordhell, MC Slvr, LXST CXNTURY) is the TikTok-era evolution of Memphis rap — dark, distorted, high-energy, with signature elements:

  • 120-140 BPM, usually minor key

  • Memphis-style drums: punchy kick on 1 and 3, snare/clap on 2 and 4, fast 16th hats with occasional rolls, lo-fi texture

  • 808 bass with slides (glide between notes, sustained resonance)

  • Cowbell melody — the iconic phonk sound, catchy repetitive riffs in minor pentatonic, often detuned/dark

  • Sidechain feel — bass ducks when kick hits

  • Distorted, lo-fi aesthetic

Creates 3 tracks:

  1. Drums (drum_track): Memphis-style — punchy kick, clap on 2&4, 16th hats with rolls at phrase ends, occasional perc hits.

  2. 808 bass (bass_track): Sliding 808 with sustained resonance. Follows root with chromatic slides, octave drops, and gaps where drums fill. The glide is simulated by short overlapping notes at pitch transitions.

  3. Cowbell lead (cowbell_track): Repetitive minor pentatonic riff in high octave, catchy and driving. 1-bar or 2-bar cycle.

bpm: Tempo (110-150, default 130). bars: Arrangement length (4-32, default 8). root: Root note (default F = common phonk key). octave: MIDI octave for 808 (2 = C2=36).

Example: create_phonk_arrangement(bpm=130, root="F", bars=8) create_phonk_arrangement(bpm=140, root="D#", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
cowbell_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral disclosure burden. It describes what the tool creates (3 tracks, their roles, and style influences) and provides parameter defaults, but does not address side effects (e.g., overwriting tracks), prerequisites, or error handling, which are important for agent decision-making.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for genre notes, track details, and parameters. It front-loads the purpose. Some detail (e.g., listing all genre characteristics) could be trimmed, but overall it is efficient and informative for its complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters and no annotations, the description is incomplete. It explains output (3 tracks) but leaves several parameters unexplained (velocity, track indices, start_beat, unit_index). The presence of an output schema reduces the need to describe return values, but the parameter gaps remain significant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains four parameters (bpm, bars, root, octave) with examples, but leaves six parameters (velocity, bass_track, drum_track, start_beat, unit_index, cowbell_track) undocumented. This partial coverage is insufficient for a tool with 10 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full drift phonk arrangement — 3 tracks: drums + 808 + cowbell lead,' specifying verb, resource, and genre. It distinguishes this tool from sibling arrangement tools by naming a specific genre (drift phonk) and its unique elements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (for creating a drift phonk arrangement) and lists genre characteristics, but does not explicitly state when not to use it or compare to alternatives. The sibling list includes many other arrangement tools, but the description makes the niche clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_pitch_stretched_clipA

Create a pitch-stretched audio clip in session view.

Pitch-stretched clips maintain pitch alignment with the project tempo. Uses AudioPitchStretchBox for play mode.

sample_id: ID from mcp_opendaw_load_audio. unit_index: Audio unit index. clip_index: Slot index in clip launcher. track_index: Audio track index within AU. bpm: Source BPM of the sample.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
sample_idYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden, but it only explains basic behavior (creates clip, uses specific play mode) and parameter meanings. It does not disclose side effects, prerequisites, error conditions, or overwrite behavior. The safety profile is not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a summary line, a brief explanation, and a parameter list. Every sentence adds value, and the structure is clean and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basics but lacks details on return value, prerequisites (e.g., track must exist), and potential side effects. The output schema exists but is not shown, so completeness is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by explaining each parameter's meaning (e.g., sample_id from load_audio, clip_index as slot index). This adds significant value beyond the schema's simple titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a pitch-stretched audio clip in session view, and distinguishes it from the sibling time-stretched version by emphasizing pitch alignment with tempo. The specific verb-resource combination and mention of AudioPitchStretchBox add clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for maintaining pitch, but does not explicitly state when to use this tool versus the time-stretched alternative (mcp_opendaw_create_time_stretched_clip). No when-not-to-use or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_pitch_stretched_regionA

Place a pitch-stretched audio region on a track.

Pitch-stretch preserves the original timing but allows pitch manipulation via warp markers. Use this when you want to tune audio to project key without changing its duration.

sample_id: The ID returned by mcp_opendaw_load_audio. unit_index: Audio unit index (default 0). start_beat: Beat position to place the region. track_index: Track index within the audio unit (default 0). bpm: Source BPM of the sample (for warp marker calculation).

Returns position and duration in PPQN.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
sample_idYes
start_beatYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that pitch-stretch preserves timing, uses warp markers, and returns position/duration. However, it does not mention side effects, prerequisites, or what happens if parameters are invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose, followed by a concise explanation, then a parameter list, and ends with return info. Every sentence contributes value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 required parameters and no nested objects, the description fully explains each parameter and the return type. The presence of an output schema (mentioned) further supports completeness. The description is adequate for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage (no parameter descriptions), but the tool description explains all 5 parameters, including their roles and defaults (e.g., 'sample_id: The ID returned by mcp_opendaw_load_audio', 'bpm: Source BPM of the sample (for warp marker calculation)'). This adds essential meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource ('Place a pitch-stretched audio region on a track') and distinguishes it from time-stretched alternatives by explaining that pitch-stretch preserves timing. This differentiates it from sibling tools like 'create_time_stretched_region'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use this when you want to tune audio to project key without changing its duration.' It does not explicitly state when not to use or list alternatives, but the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_playfield_sampleA

Add a drum pad to a Playfield drum machine.

midi_note: MIDI note number for this pad (36=C1, 38=D1, 42=F#1, etc). sample_name: Name for the sample slot. duration_seconds: Duration hint for the sample slot. unit_index: Audio unit index (-1 = auto-detect Playfield).

Returns the new pad index and MIDI note.

ParametersJSON Schema
NameRequiredDescriptionDefault
midi_noteYes
unit_indexYes
sample_nameYes
duration_secondsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description bears full burden. It describes the action (add) and mentions return values (new pad index and MIDI note). However, it lacks details on side effects, error states, or prerequisites (e.g., if a pad with the same MIDI note exists). Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences plus bulleted parameter descriptions. Every sentence provides value, no fluff. Front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has output schema (mentioned but not provided), and description notes return values. Covers purpose and all parameters. Lacks error handling or overwrite behavior, but for a simple creation tool this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must add meaning. It does so effectively: explains midi_note with examples (36=C1), sample_name, duration_seconds, and unit_index with auto-detect hint. Greatly enhances schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Add a drum pad to a Playfield drum machine.' This specific verb-resource combination distinguishes it from sibling tools like copy_playfield_sample, list_playfield_samples, and set_playfield_sample_enabled.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., copy or modify). Agent must infer from the verb 'Add' that it creates a new pad, but no when-not-to-use or contrasting conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_polyrhythmA

Create a polyrhythm — two rhythmic streams with different subdivision counts playing simultaneously.

A polyrhythm divides the same time span into two different numbers of equal parts. The classic 3:4 means 3 notes in the time of 4 — creating cross-rhythms used in jazz, electronic, African, and progressive music.

Creates notes on a single track: primary stream uses primary_pitch, secondary uses secondary_pitch. Both streams span the same total duration (bars × 4 beats).

primary_count: Number of primary subdivisions (2-16). E.g., 3 in a 3:4 polyrhythm. secondary_count: Number of secondary subdivisions (2-16). E.g., 4 in a 3:4 polyrhythm. bars: Total length in bars (1-8). unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. primary_pitch: MIDI pitch for primary stream (default 60 = C4). secondary_pitch: MIDI pitch for secondary stream (default 72 = C5, one octave up). primary_velocity: Velocity for primary notes 0-1. secondary_velocity: Velocity for secondary notes 0-1. duration: Note duration in beats.

Returns total notes created and polyrhythm ratio.

Common polyrhythms: 3:4 — classic cross-rhythm (jazz, electronic) 2:3 — hemiola (African, Latin) 3:5 — complex polyrhythm (progressive) 4:5 — dense polyrhythm (modern jazz) 7:8 — extreme polyrhythm (math rock)

Example: create_polyrhythm(primary_count=3, secondary_count=4, bars=2, primary_pitch=60, secondary_pitch=67)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
durationNo
start_beatNo
unit_indexNo
track_indexNo
primary_countYes
primary_pitchNo
secondary_countYes
secondary_pitchNo
primary_velocityNo
secondary_velocityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that notes are created on a single track with two pitches and returns total notes and ratio. However, it does not disclose whether existing notes are overwritten, potential side effects, or required setup, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a definition, concept, parameter list, common polyrhythms table, and an example. It is front-loaded with purpose, though slightly verbose; each sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameters well and notes that it returns total notes and ratio (output schema exists). It lacks details on interaction with existing notes or performance considerations, but is adequate for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite zero schema description coverage, the description provides detailed explanations for each parameter, including constraints (e.g., primary_count 2-16), defaults, and examples (e.g., primary_count=3 in a 3:4 polyrhythm). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a polyrhythm' with a specific verb and resource, and explains the concept of polyrhythm. It differentiates from siblings like create_hemiola and create_cross_rhythm by focusing on two simultaneous subdivisions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context and common polyrhythms (3:4, 2:3, etc.), implying usage for cross-rhythms. However, it does not explicitly state when not to use it or compare with similar tools such as create_metric_modulation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_pop_arrangementA

Create a full pop arrangement with verse-chorus-bridge song structure across 4 tracks.

Pop music with real song form — fundamentally different from all loop-based arrangements:

  • Track 0: Drums — verse (sparse: kick+hat) → chorus (full: kick+snare+hat+crash) → bridge (build: rising energy) → final chorus (maximum density)

  • Track 1: Bass — verse (root notes, sparse) → chorus (octave jumps, driving) → bridge (walking, building) → final chorus (full energy)

  • Track 2: Chords — I-V-vi-IV progression (the "four chords of pop"), played differently per section: verse (light arpeggios), chorus (full block chords), bridge (sus/resolution)

  • Track 3: Melody — catchy hook that varies per section: verse (sparse, low) → chorus (anthemic, high register) → bridge (tension, chromatic) → final chorus (hook + variation)

At 120 BPM (default), this creates a modern pop feel. The I-V-vi-IV progression is the most used chord sequence in pop music (I=0, V=7, vi=9, IV=5) — different from rock's I-IV-V and jazz's ii-V-I. Song structure (verse-chorus-bridge) is the key difference from all loop-based arrangements.

Sections (16 bars default):

  • Verse 1: bars 1-4 (sparse, intimate)

  • Chorus 1: bars 5-8 (full energy, hook)

  • Verse 2: bars 9-12 (sparse + variation)

  • Chorus 2: bars 13-16 (full energy, hook)

  • Bridge: bars 17-20 (tension, build)

  • Final Chorus: bars 21-24 (maximum, hook + variation)

bpm: Tempo (90-140, default 120 = modern pop). bars: Total length in bars (16-32, default 16 = standard pop song). root: Root note (C is the most common pop key). octave: MIDI octave for bass (2 = C2=36, standard bass register). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / melody_track: Track indices.

Returns notes created per track and total.

Example: create_pop_arrangement(bpm=120, root="C", bars=16) create_pop_arrangement(bpm=128, root="G", bars=24)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
chord_trackNo
melody_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It details per-track behavior per section (e.g., verse sparse, chorus full), BPM range, bar length, default values, and return type. However, it does not disclose whether it clears existing notes or modifies other project state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized with bullet points and section breakdowns. It front-loads the purpose and provides high-density information. Slightly verbose but earns its length with musical theory and examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 4-track arrangement with detailed patterns per section, the description is remarkably complete. It covers musical theory (I-V-vi-IV progression), section structure, BPM/bars defaults, and return format. Output schema exists, so return values are already defined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains bpm, bars, root, octave, and track indices inline. However, parameters like velocity, start_beat, and unit_index are not described, and schema already has defaults. Description partially compensates but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full pop arrangement with verse-chorus-bridge structure across 4 tracks (drums, bass, chords, melody). It distinguishes itself from loop-based arrangements and other genre-specific arrangement tools in the sibling list. The verb 'create' and resource 'pop arrangement' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is 'fundamentally different from all loop-based arrangements' implying use for pop song form, but it does not explicitly contrast with other arrangement tools (e.g., rock, jazz) or state when to use this vs alternatives. No guidance on prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_progression_from_keyA

Auto-generate a diatonic chord progression from a detected key — no manual chord typing.

Takes key + mode (from detect_key output) and generates a genre-appropriate diatonic progression using scale degrees. Eliminates the need to manually write [["Am","min"],["F","maj"]...] — just pass key="A", mode="minor".

key: Root note name (C, C#, D, D#, E, F, F#, G, G#, A, A#, B). mode: "major" or "minor" (natural minor scale). style: Progression style:

  • "pop" — I-V-vi-IV (major) / i-VI-III-VII (minor) — "four chords of pop"

  • "jazz" — ii-V-I (major) / ii-V-i (minor) — jazz turnaround

  • "rock" — I-IV-V (major) / i-iv-V (minor) — blues/rock

  • "synthwave" — i-VI-III-VII (minor) — synthwave/emotional

  • "folk" — I-IV-vi-V (major) / i-iv-VII-III (minor) — folk/americana

  • "lofi" — ii-V-i (minor) or I-vi-IV-V (major) — lofi/jazzy unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the progression starts (0 = bar 1). chord_duration: Length of each chord in beats (4 = one bar at 4/4).

Returns: notes_created, chords, voicings, progression (chord names), key, mode.

Pipeline: detect_key("track.wav") → {key: "A", mode: "minor"} → create_progression_from_key("A", "minor", "synthwave") → create_harmonic_arrangement("Am-F-C-G")

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYes
modeNomajor
styleNopop
start_beatNo
unit_indexNo
track_indexNo
chord_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description takes on full transparency duty. It describes the generated output (notes_created, chords, voicings, etc.) and explains the genre-appropriate nature of the progression. However, it does not mention potential side effects (e.g., overwriting existing notes) or dependencies beyond detect_key, leaving some transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, bullet-style parameter explanations, and a pipeline example. It is front-loaded with the core purpose and remains informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters and no annotations, the description provides comprehensive context: usage flow (detect_key → this tool → create_harmonic_arrangement), all parameter details, and return fields. It integrates well with sibling tools and covers the expected pipeline.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains every parameter in detail, including key, mode, style with examples, and positional parameters (unit_index, track_index, etc.). Since schema description coverage is 0%, the description fully compensates and adds meaning beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: auto-generate a diatonic chord progression from a detected key. It uses specific verbs ('auto-generate') and distinguishes from manual methods ('no manual chord typing'), effectively differentiating from sibling tools like create_chord_progression.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: it should be used after detect_key and eliminates manual chord typing. It implies when to use this tool over manual alternatives, but does not explicitly list conditions when not to use it or mention other alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_psytrance_arrangementA

Create a psytrance arrangement — 145 BPM hypnotic Goa/psychedelic.

Psytrance (psychedelic trance) is a subgenre of trance born in Goa, India (early 1990s) and developed in Israel, Europe. Key:

  • 145-150 BPM, 4/4 time, driving and hypnotic

  • Rolling bassline: 16th notes with a specific "k-b-k-b" pattern (kick on downbeat, bass on offbeat, creating a rolling feel)

  • Layered percussion: tight hats, snare rolls, shakers

  • Hypnotic lead: repeated motifs, evolving filter sweeps

  • FM synth sounds, alien textures, sci-fi atmosphere

  • Often in F minor or E minor

Creates 4 tracks:

  1. Drums (track_index): Kick on every beat, snare on 2&4, tight 16th hats, shaker pattern, snare roll at end of phrases

  2. Bass (track_index+1): Rolling 16th bassline — kick-aligned bass notes with offbeat syncopation, creating the psytrance "gallop" feel

  3. Lead (track_index+2): Hypnotic repeated motif with filter sweep simulation (velocity variations), octave jumps

  4. Atmosphere (track_index+3): Sparse sustained notes, sci-fi pad-like textures on bar starts

Default key: F minor.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
key_rootNoF
velocityNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details the 4 tracks created and their roles, but does not state if existing content is overwritten, required permissions, or response behavior. Decent but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured: purpose first, then genre explanation, then track details. Could be slightly more concise, but the information is relevant and organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (psytrance genre, 4 tracks), the description covers genre, structure, and track details comprehensively. Output schema exists, so return values are likely handled. Adequate for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It adds context for bpm, bars, key_root, and track_index, but ignores unit_index and start_beat. Partial compensation, not full parameter clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and resource 'psytrance arrangement', with specific genre details (BPM, key, track structure). It distinguishes from sibling tools like create_trance_arrangement by focusing on psytrance characteristics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for psytrance generation and details the output, but does not explicitly state when to use this tool versus alternatives (e.g., create_trance_arrangement). No exclusions or when-not guidance provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_random_walk_melodyA

Create a melody using a random walk through a scale — stochastic generation.

Each note is chosen by walking up or down the scale from the previous note. The walk is constrained by max_step (how many scale degrees can move per step) and direction_bias (probability of ascending vs descending).

This produces melodies that feel coherent (smooth stepwise motion) yet unpredictable — the hallmark of generative music. Brian Eno's generative systems, Xenakis's stochastic pieces, ambient textures, IDM melodies.

Unlike generate_melody (contour-guided weighted random), random walk produces stepwise motion where each note depends on the previous one — creating the melodic continuity that contour guidance doesn't guarantee.

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, phrygian, lydian, mixolydian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues). bars: Number of bars (1-32). At default duration=0.5, 4 bars = 32 notes. octave: Starting MIDI octave (1-6, default 4 = C4=60). max_step: Maximum scale steps per move (1-7, default 3). 1 = only adjacent scale tones (very smooth, stepwise). 2 = allow skips of up to a third. 3 = up to a fourth (mix of steps and skips). 5 = up to a sixth (dramatic leaps). 7 = full octave (free movement). direction_bias: -1.0 to +1.0 (default 0 = equal up/down). Negative = tend downward, positive = tend upward. 0.5 = 75% chance up, 25% down. duration: Note duration in beats (0.0625-4.0, default 0.5 = eighth). duration_variation: "none" (uniform), "slight" (+/-50%), "wide" (16th to half), "dotted" (mix of dotted and straight). rest_probability: 0-0.5 (default 0 = no rests). Inserts rests instead of notes at the given probability. velocity: Base velocity 0-1. velocity_variation: "none" (uniform), "slight" (+/-0.1), "dynamic" (+/-0.3), "human" (gaussian-ish, +/-0.15). boundary_behavior: "reflect" (bounce back at octave limits), "wrap" (wrap around), "clamp" (stay at boundary). seed: PRNG seed for reproducibility. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, walk statistics (range, average interval, direction ratio), and seed for reproducibility.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
seedNo
scaleNominor
octaveNo
durationNo
max_stepNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo
direction_biasNo
rest_probabilityNo
boundary_behaviorNoreflect
duration_variationNonone
velocity_variationNonone

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains stochastic generation, random walk mechanics, constraints (max_step, direction_bias), and output (notes, walk statistics, seed). However, it does not explicitly state whether the tool modifies existing notes or appends, nor does it mention potential side effects on the project state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with opening summary, algorithm explanation, sibling comparison, and parameter list. Somewhat verbose with artistic references (Brian Eno, Xenakis) but adds context. Front-loaded with key concept.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all 16 parameters, explains output schema (notes, walk statistics, seed). Complex tool with many parameters, and description provides sufficient detail. Minor gap: does not specify if notes are appended or replaced, and 'AU index' is not explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage (no parameter descriptions), but the description details every parameter with default values, ranges, and behavioral explanations (e.g., max_step: '1 = only adjacent scale tones (very smooth, stepwise)'). This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Create a melody using a random walk through a scale — stochastic generation.' It clearly differentiates from sibling tool generate_melody by explaining the algorithm and resulting characteristics (stepwise motion, each note depends on previous).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit contrast with generate_melody: 'Unlike generate_melody (contour-guided weighted random), random walk produces stepwise motion...creating melodic continuity that contour guidance doesn't guarantee.' Also gives example applications (Brian Eno, Xenakis, ambient, IDM) to indicate appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ratchetA

Create a ratchet — repeated notes with changing subdivision rate.

A ratchet (also called "accelerando repeat" or "Bach ratchet") is a series of repeated notes where the spacing between notes gradually decreases (accelerate) or increases (decelerate), creating a sense of acceleration or deceleration. Used extensively in Baroque music (Bach cadences), electronic build-ups, and drum fills.

Args: unit_index: Audio unit index track_index: Note track index pitch: MIDI pitch for all ratchet notes (0-127) start_beat: Start position in beats length_beats: Total length in beats subdivisions: Subdivision mode — "accelerate" = start slow, get faster (16th→32nd→64th) "decelerate" = start fast, get slower (64th→32nd→16th) "constant" = even subdivision (no change, like a roll) "exponential" = exponential acceleration max_subdivisions: Maximum notes per beat at the fastest point (4=16th, 8=32nd, 16=64th, 32=128th) velocity: Base velocity (0-1) velocity_decay: Velocity reduction per note (0=uniform, 0.02=gradual fade) pitch_drift: Semitones to drift per note (0=same pitch, 1=ascending chromatic, -1=descending, 12=ascending octaves) region_index: Target region (-1 = auto-create/append)

Returns: JSON with notes_created, pitch, subdivision_points, total_beats.

ParametersJSON Schema
NameRequiredDescriptionDefault
pitchNo
velocityNo
start_beatNo
unit_indexYes
pitch_driftNo
track_indexYes
length_beatsNo
region_indexNo
subdivisionsNoaccelerate
velocity_decayNo
max_subdivisionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It clearly explains the behavioral effect (repeated notes with changing rate), defines subdivision modes, and describes parameters like velocity_decay and pitch_drift. It lacks explicit pre-conditions (e.g., track existence) but is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise definition followed by a clear parameter breakdown. It is not overly verbose, but the musical context paragraph could be slightly trimmed. Still, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, no annotations), the description covers purpose, all parameters, and return value via output schema mention. It lacks error handling or prerequisites, but is generally complete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates with a detailed 'Args' section explaining every parameter's meaning, defaults, and allowed values (e.g., subdivisions modes, max_subdivisions mapping). This adds significant value beyond the schema's titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a ratchet, defines it as repeated notes with changing subdivision rate, and provides musical context. It distinguishes from sibling tools like create_trap_rolls or create_stutter by focusing on gradual acceleration/deceleration patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for accelerating or decelerating note sequences in Baroque, electronic, or drum fill contexts. However, it does not explicitly state when to use this tool over alternatives (e.g., create_stutter, create_buildup), nor does it provide when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_reggae_arrangementA

Create a full reggae arrangement — one-drop drums + melodic bass + skank guitar + organ across 4 tracks.

Roots reggae with the signature one-drop feel — fundamentally different from all other arrangements:

  • Track 0: Drums — one-drop pattern: kick AND snare TOGETHER on beat 3 (the "drop"), with hi-hat on all 8ths. No kick on beat 1 — the emptiness on 1 is the reggae feel. Organ bubble on 8th off-beats.

  • Track 1: Bass — THE lead instrument in reggae: melodic, repetitive, driving. Root-based with octave and fifth walks, full bar sustain. In reggae, bass carries the melody — not the guitar.

  • Track 2: Guitar — skank: staccato chops on the off-beats (the "and" of 1, the "and" of 2, etc.). The signature reggae guitar sound — short, percussive, on every off-beat. This is the rhythmic backbone, not the drums.

  • Track 3: Keys — organ bubble: Hammond-style sustained chords with a shuffle feel, filling the space between guitar skanks. Adds harmonic richness and the classic roots sound.

At 80 BPM (default), this creates the classic roots reggae pocket — slow, heavy, meditative. The one-drop (kick+snare together on 3) is the fundamental difference from all 10 other arrangements: rock puts kick on 1 & 3, funk puts kick on 1 with syncopation, reggae drops everything on 3 and leaves 1 empty. The bass is the lead instrument — unique among all genres.

bpm: Tempo (65-95, default 80 = classic roots reggae). bars: Arrangement length (4-16, default 8). root: Root note (A is a classic reggae key — Am). octave: MIDI octave for bass (2 = A2=45, standard reggae bass register). unit_index: AU index with note tracks. drum_track / bass_track / guitar_track / keys_track: Track indices.

Returns notes created per track and total.

Example: create_reggae_arrangement(bpm=80, root="A", bars=8) create_reggae_arrangement(bpm=72, root="D", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoA
octaveNo
velocityNo
bass_trackNo
drum_trackNo
keys_trackNo
start_beatNo
unit_indexNo
guitar_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses the tool creates notes across 4 tracks with specific patterns, default tempo, parameter ranges, and return value. It lacks explicit mention of side effects (e.g., overwriting existing tracks) but is substantially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with intro, track breakdown, context, parameter list, and examples. It is informative but slightly repetitive on one-drop explanation. Length is justified by genre complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and the tool's clear role among many arrangement siblings, the description covers purpose, parameters, behavior, and examples. It omits error handling and prerequisites but is otherwise thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains 7 of 11 parameters (bpm, bars, root, octave, track indices) while velocity, start_beat, unit_index remain undocumented. With 0% schema coverage, it compensates partially but not fully, as some parameters lack meaning beyond defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full reggae arrangement with specific track roles (one-drop drums, melodic bass, skank guitar, organ) and explicitly contrasts with other arrangements (rock, funk), distinguishing it from sibling tools like mcp_opendaw_create_funk_arrangement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description details when to use the tool: for roots reggae arrangements with one-drop feel. It provides explicit guidance on genre-specific differences and includes example calls (create_reggae_arrangement(bpm=80, root='A', bars=8)), effectively guiding selection among many arrangement siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_reggae_percussionA

Create Jamaican reggae percussion patterns across 6 styles.

Reggae drum patterns are the rhythmic backbone of Jamaican popular music. The one-drop is the most iconic — kick and snare together on beat 3, creating the characteristic "drop" that defines roots reggae.

Styles:

  • one_drop: Roots reggae (Bob Marley, Burning Spear). Kick+snare on beat 3 of each bar. Hi-hat 8th notes. The "drop" = beat 3 hits hard, beats 1/2/4 are empty or sparse. 65-80 BPM.

  • rockers: Late roots/early dancehall (Sly Dunbar, Robbie Shakespeare). Kick on 1 and 3, snare on 2 and 4. Steady four-on-the-floor feel but with reggae push. 75-90 BPM.

  • steppers: Dub/roots (Burning Spear "Marcus Garvey"). Four-on-the-floor kick on every beat, snare on 3. Driving, hypnotic. 70-85 BPM.

  • ska: Early Jamaican ska (Skatalites, Prince Buster). Fast, upbeat emphasis. Kick on 1+3, snare on 2+4, riding hi-hat with heavy syncopation. 120-180 BPM.

  • rocksteady: Transition era (Alton Ellis, Hopeton Lewis). Slower than ska, laid-back. Kick on 1+3, snare on 3, hi-hat 8ths with slight behind-the-beat feel. 70-85 BPM.

  • dancehall: Modern Jamaican (Shabba Ranks, Sean Paul). Programmed feel, kick on 1, 3-and, snare on 2, 4, with syncopated hi-hat. 90-120 BPM.

swing: 0.0-0.6, offsets off-beat hats (reggae rarely swings heavy, but ska can use 0.3-0.5).

Creates drum notes on track_index using GM percussion pitches: 36 (kick), 38 (snare), 42 (closed hat), 46 (open hat).

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNoone_drop
swingNo
velocityNo
tempo_bpmNo
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains that drum notes are created using specific GM percussion pitches (36, 38, 42, 46), details swing range (0.0-0.6), and describes each style's rhythmic feel. However, it does not address behavior with invalid inputs, overwriting, or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear lead sentence and bullet-style style definitions. However, it is somewhat lengthy (multiple paragraphs) and includes very detailed BPM ranges for each style that could be streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and no annotations, the description covers the main behavioral aspects: what it creates (drum notes with specific pitches), style choices, and swing. It does not detail output schema (though one exists) or error handling, but it is largely complete for a creative drum pattern generator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add meaning. It explains 'style' with 6 detailed subdescriptions, 'swing' with range and genre guidance, and mentions 'track_index' and GM pitches. However, parameters like 'bars', 'velocity', 'tempo_bpm', 'start_beat', and 'unit_index' are not individually explained beyond defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates reggae percussion patterns across 6 styles, using a specific verb ('create') and resource ('reggae percussion'). It distinguishes itself from siblings like 'create_breakbeat' and 'create_drum_pattern' by narrowing scope to Jamaican reggae.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed style characterizations that implicitly guide when to use each style (e.g., one_drop for roots reggae, ska for fast upbeat), but lacks explicit when-to-use or when-not-to-use comparisons with alternative tools. No direct mentions of alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_riffA

Create a genre-specific riff — catchy repeated melodic fragment.

A riff is a short, memorable, repeated musical phrase that defines a song's identity. Unlike a melody (which develops through a section) or an ostinato (which repeats a scale pattern), a riff is a self-contained hook with rhythmic character and pitch content that immediately identifies the song.

  • rock: Power chord-based riffs, palm-mute aesthetic, bluesy bends, syncopated rests. Deep Purple, Led Zeppelin, Black Sabbath.

  • funk: Sixteenth-note syncopation, ghost notes, staccato stabs, octave jumps, tight pocket. James Brown, Funkadelic, Tower of Power.

  • metal: Galloping rhythms, palm-muted low strings, tritone intervals, fast alternate picking. Iron Maiden, Metallica, Slayer.

  • blues: Shuffle feel, pentatonic bending, call-response phrases, turnaround aesthetic. B.B. King, Freddie King, Albert King.

  • hip_hop: Sample-chop aesthetic, short repeating loop, melodic minor pentatonic, sparse placement. Dr. Dre, RZA, J Dilla.

riff_type: rock | funk | metal | blues | hip_hop key_root: Root note scale_type: minor_pentatonic | major_pentatonic | blues | minor | phrygian bars: Riff length (1-4, default 2) octave: MIDI octave (3 = C3=48, good for guitar range) velocity: Base velocity 0-1 seed: PRNG seed for reproducibility

Example: create_riff(riff_type="rock", key_root="E", bars=2) create_riff(riff_type="funk", key_root="D", scale_type="minor_pentatonic", bars=1) create_riff(riff_type="metal", key_root="E", scale_type="phrygian", bars=2)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
seedNo
octaveNo
key_rootNoE
velocityNo
riff_typeNorock
scale_typeNominor_pentatonic
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not specify side effects like whether existing notes are overwritten or appended, nor does it clarify the role of parameters like track_index and unit_index in placement. The musical behavior is well-described, but operational transparency is lacking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line summary, definition, genre details, parameter list, and examples. It front-loads the purpose. However, the genre sections are somewhat verbose (e.g., artist lists), and some sentences could be condensed. Overall, it efficiently imparts necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values. It thoroughly covers musical intent and genre-specific behaviors, but it omits operational details like where the riff is placed (track, unit, beat) and fails to describe all parameters. For a 10-parameter tool, this leaves noticeable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% parameter descriptions, so the description must compensate. It explains 7 of 10 parameters (riff_type, key_root, scale_type, bars, octave, velocity, seed) with meaningful context (e.g., octave range for guitar). However, start_beat, unit_index, and track_index are not mentioned, leaving critical placement parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a genre-specific riff — catchy repeated melodic fragment.' It then defines a riff in contrast to melody and ostinato, distinguishing it from sibling tools like create_melody or create_ostinato. This precise differentiation and strong verb-resource pairing earn a top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides genre-specific guidance and examples (e.g., rock, funk, metal) and contrasts riff with melody/ostinato, which helps the agent decide when this tool is appropriate. However, it lacks explicit 'when to use' or 'when not to use' directives, such as prerequisites or alternatives, so it does not fully reach a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_riserA

Create a riser — ascending pitch sweep for build-up transitions.

Generates a sequence of notes with ascending pitch from start_pitch to end_pitch over the specified length. Velocity ramps up proportionally. Useful for:

  • Build-ups before a drop/chorus

  • Transition between sections

  • Tension creation

unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the riser begins. length_beats: Duration of the riser in beats (1-16). start_pitch: Starting MIDI pitch (default 36 = C2). end_pitch: Ending MIDI pitch (default 84 = C6). steps: Number of notes in the sweep (8-128, default 32 = sixteenths over 4 beats). curve: Pitch curve — "linear" (even), "exp" (slow start, fast end), "log" (fast start, slow end). velocity: Base velocity (0-1, ramped proportionally with pitch).

Returns notes created and pitch range.

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNoexp
stepsNo
velocityNo
end_pitchNo
start_beatNo
unit_indexNo
start_pitchNo
track_indexNo
length_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description discloses that it generates notes with ascending pitch and proportional velocity ramp, and returns created notes and pitch range. However, it does not specify potential side effects like overwriting existing notes or creating new tracks, which would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-liner purpose, detailed explanation, bulleted use cases, and parameter list. It is front-loaded and informative, though could be slightly more concise by omitting redundant phrases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 9 parameters, no required ones, and an output schema (not shown), the description covers purpose, usage, parameters, and return value. It lacks details on error handling or creation behavior (e.g., if it creates a new region), but is largely complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description carries full burden. It explains every parameter: unit_index, track_index, start_beat, length_beats, start_pitch, end_pitch, steps, curve, velocity. It includes defaults, valid ranges (e.g., steps 8-128, curve options), and how they affect the riser, greatly aiding correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a riser — ascending pitch sweep for build-up transitions' using a specific verb ('Create') and resource ('riser'). It distinguishes itself from siblings like 'create_buildup' and 'automation_sweep' by focusing on pitch sweeps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases: build-ups before a drop/chorus, transitions, and tension creation. While it does not mention exclusions or alternatives, the provided context is sufficient for an agent to decide when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_rnb_arrangementA

Create a full modern R&B arrangement — trap-influenced drums + deep sub bass + extended chords + vocal-style lead.

Contemporary R&B (The Weeknd / Frank Ocean / SZA / Brent Faiyaz) — dark, atmospheric, slow-burn:

  • Track 0: Drums — half-time R&B groove: kick on 1 with syncopated ghost, snare/clap on 3, triplet hi-hat rolls. Programmable feel — not live, but loose. Half-time at 68 BPM feels like 34 BPM.

  • Track 1: Bass — deep sub bass: long sustained root notes, occasional octave/fifth movement. More sustain than soul, less movement than funk. The low-end foundation — felt more than heard.

  • Track 2: Chords — dark extended voicings (min9, maj7, dom9, min7b5) on i-VI-III-VII minor-key progression. Rhodes/synth pad texture with long sustains. The Weeknd's signature dark harmony — minor key with lush 9ths.

  • Track 3: Lead — vocal-style melodic phrases: wide interval leaps, pentatonic minor with blue notes, long sustained notes with melismatic fills. Call-and-response phrasing — the "sung" quality without actual vocals.

At 68 BPM (default), this creates the contemporary R&B pocket — slow, atmospheric, dark. The i-VI-III-VII progression (same as synthwave but with extended chords and half the tempo) is the modern R&B harmonic language. Half-time drums + sub bass + dark 9ths = The Weeknd "After Hours" aesthetic.

bpm: Tempo (55-85, default 68 = modern R&B sweet spot). bars: Arrangement length (4-16, default 8). Must be multiple of 4. root: Root note (C minor = dark R&B key, common for The Weeknd). octave: MIDI octave for bass (2 = C2=36, sub bass register). unit_index: AU index with note tracks. drum_track / bass_track / chord_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_rnb_arrangement(bpm=68, root="C", bars=8) create_rnb_arrangement(bpm=75, root="Ab", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo
chord_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries full responsibility. It thoroughly explains behavioral traits: each track's content (drums, bass, chords, lead), musical theory (i-VI-III-VII progression, half-time feel), and return value ('notes created per track and total'). There is no contradiction with annotations as none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose sentence, track-by-track breakdown, parameter explanations, and examples. However, it is slightly verbose (e.g., repeating the tempo feel) and could be streamlined without losing clarity. Still, it earns a high score for effective organization.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (genre-specific arrangement with 11 parameters) and the presence of an output schema (indicating return structure), the description covers all necessary aspects: track content, musical theory, parameter guidance, and examples. It is fully sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds significant meaning: it explains the purpose of each parameter (e.g., 'bpm: Tempo (55-85, default 68 = modern R&B sweet spot)'), provides examples, and links parameters to musical context (e.g., 'root: Root note (C minor = dark R&B key)'). This far exceeds the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full modern R&B arrangement' with specific verbs ('Create') and resources ('arrangement'). It distinguishes from sibling tools by detailing the R&B style, including artists (The Weeknd, Frank Ocean) and harmonic/melodic characteristics, making it unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: BPM range (55-85, default 68), bar length must be multiple of 4, and example calls. It implicitly suggests use for R&B composition but does not explicitly exclude other genres or state when not to use. Alternatives (sibling tools) are not mentioned but the genre-specific content guides appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_rock_arrangementA

Create a full rock arrangement — rock beat drums + bass + power chords + riff across 4 tracks.

Classic rock with blues-based harmony and guitar-driven energy:

  • Track 0: Drums — rock beat: kick on 1 & 3, snare on 2 & 4, with crash on downbeats and fills at bar transitions. The backbone.

  • Track 1: Bass — root-fifth bassline locking with kick drum, with walks between chord changes. Blues-based, driving.

  • Track 2: Guitar — power chords (root+fifth) on chord changes, with palm-muted downstrokes between. The defining instrument.

  • Track 3: Keys — sustained chord pads backing the guitar, filling the midrange. Optional but adds depth.

At 120 BPM (default), this creates a mid-tempo rock feel. The I-IV-V blues-based harmony (A-E-D for key of A, or E-A-D for key of E) is the foundation of rock from Beatles to AC/DC. Power chords are the signature — root+fifth voicings, no third (ambiguous major/minor).

bpm: Tempo (90-160, default 120 = mid-tempo rock). bars: Arrangement length (4-16, default 8). root: Root note (E is the most common rock guitar key — open strings). octave: MIDI octave for bass (2 = E2=40, standard bass register). unit_index: AU index with note tracks. drum_track / bass_track / guitar_track / keys_track: Track indices.

Returns notes created per track and total.

Example: create_rock_arrangement(bpm=120, root="E", bars=8) create_rock_arrangement(bpm=140, root="A", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoE
octaveNo
velocityNo
bass_trackNo
drum_trackNo
keys_trackNo
start_beatNo
unit_indexNo
guitar_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the notes created per track, defaults, and musical details, but lacks clarity on side effects like whether tracks are appended or replaced, or if new tracks are created. This leaves some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, track breakdown, parameter list, and examples. It is informative but slightly verbose for the amount of detail, earning a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of creating a multi-track arrangement, the description covers track roles, defaults, and examples. However, it omits details on track existence requirements, error handling, and exact return structure beyond 'notes created per track and total'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates by explaining each parameter's purpose, allowed ranges, defaults, and musical context (e.g., bpm range 90-160, root note suggestions). Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full rock arrangement with specific instruments (drums, bass, guitar, keys) and distinguishes from sibling tools like create_blues_arrangement by explicitly mentioning rock genre and musical style.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (creating a rock arrangement) with BPM and root note suggestions, and examples. However, it does not explicitly say when not to use it or compare to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_rondoA

Create a rondo — recurring theme alternating with contrasting episodes.

A rondo is a structural form where a principal theme (A) alternates with contrasting episodes (B, C, D). The theme always returns, providing unity while episodes provide contrast and development.

Form types:

  • simple: ABA (3 sections). Miniature rondo, common in character pieces.

  • classical: ABACA (5 sections). Standard classical rondo (Mozart, Beethoven). A=tonic, B=dominant/relative, C=more distant.

  • seven_part: ABACABA (7 sections). Large rondo, Beethoven Op.51, Chopin Op.16. Extended with second return of B before final A.

  • pop_rock: ABABCB (6 sections). Pop/rock structure masquerading as rondo — verse-chorus-verse-chorus-bridge-chorus. A=verse, B=chorus, C=bridge.

  • jazz: ABAC (4 sections). Jazz standard form — theme, improvisation feel, theme, contrast. A=head, B=solo section, C=trading.

Key root: C, C#, Db, D, ... B. Scale: major, minor, dorian, phrygian, lydian, mixolydian, aeolian, locrian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues, whole_tone.

The A theme uses tonic scale degrees (0, 2, 4, 2, 0). B episode uses dominant/relative degrees (4, 6, 2, 6, 4) — brighter. C episode uses more distant degrees (5, 1, 3, 1, 5) — contrasting. Each section is bars_per_section bars long.

Creates sections sequentially on track_index (melody on track_index, bass on track_index+1).

ParametersJSON Schema
NameRequiredDescriptionDefault
key_rootNoC
velocityNo
form_typeNoclassical
tempo_bpmNo
scale_nameNomajor
start_beatNo
unit_indexNo
track_indexNo
bars_per_sectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description discloses significant behavioral details: sections are created sequentially on specific tracks, degree patterns for each section, and the number of bars per section. It does not mention destructiveness or undo, which is acceptable for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the purpose. It provides educational content but is somewhat verbose. Every sentence adds value, though some musical theory could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 9 parameters, lack of output schema, and no annotations, the description provides good context for the rondo structure but fails to explain all parameters. It does not describe the return value or side effects. Adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description explains some parameters (key_root, scale_name, form_type, bars_per_section, track_index) but does not cover velocity, tempo_bpm, start_beat, or unit_index. This leaves several parameters unexplained, requiring the agent to rely on naming conventions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a rondo' and provides a thorough explanation of what a rondo is, including form types, scale options, and structural details. It distinguishes this from many other create_* tools by focusing on the rondo form.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose is clear and the description implies when to use this tool (when a rondo form is desired). However, it lacks explicit guidance on when not to use it or alternatives. The form type options provide some context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_samba_patternA

Create a Brazilian samba percussion ensemble pattern — multi-instrument layered groove.

Samba is the heartbeat of Brazilian music — a multi-instrument percussion ensemble where each drum has its own pattern, and the layers interlock to create a dense, driving groove. Unlike songo (a single drum-kit pattern), samba is an ensemble: each instrument plays independently, and the combination creates the full sound. Batucada (the carnival samba style) can have 300+ percussionists, each on one drum.

The 5 core instruments:

  1. SURDO — The bass drum. Plays on beats 1 and 3 (the "floor"). Low, resonant, the heartbeat. Surdo marcado (marked) = steady, surdo virado (turned) = syncopated.

  2. CAIXA — The snare drum. Plays continuous 16th notes with a backbeat accent on beats 2 and 4. The "glue" of the ensemble, filling the middle register.

  3. TAMBORIM — Small handheld drum. Plays a syncopated 16th pattern with rim taps, the "conversation" layer. Often uses "virada" (turn) fills.

  4. CHOCALHO — Shaker. Plays continuous 16th notes, the "wash" that keeps the time steady. Always present, rarely varied.

  5. REPIQUE — Lead drum. Plays calls, fills, and syncopated accents that cue the ensemble. The "conductor" of the bateria.

styles: "batucada" — Carnival samba (Rio de Janeiro). Dense, fast, all 5 instruments. Surdo on 1+3, caixa 16ths, tamborim syncopated, chocalho 16ths, repique accents. "samba_enredo" — Samba school parade style. More structured, surdo patterns more varied, repique has call-and-response. "pagode" — Backyard samba (informal). Lighter, no repique, tamborim simpler. More swing, less density. "samba_funk" — Samba-funk fusion. Surdo pattern funkier, caixa with ghost notes, tamborim 16ths, chocalho offbeats.

bars: Pattern length (2-16, even for 2-bar cycle). velocity: Base velocity (0-1). surdo_pitch: Surdo (bass drum) MIDI pitch (36 = C1). caixa_pitch: Caixa (snare) MIDI pitch (38 = D1). tamborim_pitch: Tamborim MIDI pitch (42 = F#1). chocalho_pitch: Chocalho (shaker) MIDI pitch (46 = A#1). repique_pitch: Repique (lead drum) MIDI pitch (50 = D2).

Args: bars: Pattern length in bars (2-16, even). style: Samba style (batucada, samba_enredo, pagode, samba_funk). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. surdo_pitch: Surdo MIDI pitch. caixa_pitch: Caixa MIDI pitch. tamborim_pitch: Tamborim MIDI pitch. chocalho_pitch: Chocalho MIDI pitch. repique_pitch: Repique MIDI pitch.

Returns notes created, instrument breakdown, and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNobatucada
velocityNo
start_beatNo
unit_indexNo
caixa_pitchNo
surdo_pitchNo
track_indexNo
repique_pitchNo
chocalho_pitchNo
tamborim_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that the tool creates a multi-instrument pattern, describing each instrument's role and output. It states it returns notes and instrument breakdown. It does not disclose whether it overwrites existing notes or appends, but the creation aspect is clear. The description provides good insight into the tool's behavior without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly verbose, devoting large paragraphs to educational content about samba instruments and styles. While informative, this is not structured for efficient agent use. The 'Args' list is redundant with the input schema and adds no new information. Front-loading is present but the bulk of the text could be trimmed significantly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, multi-instrument output), the description lacks explanations for critical positional parameters (unit_index, track_index, start_beat). It vaguely describes output as 'notes created, instrument breakdown, and pattern info' without details. The educational content is thorough but does not cover operational aspects needed for correct invocation. The output schema exists but is not referenced to clarify return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It adds meaning for instrument pitches (e.g., surdo_pitch: 'Surdo (bass drum) MIDI pitch (36 = C1)') and style/bars/velocity. However, it fails to explain critical parameters like unit_index, track_index, and start_beat, which are essential for note placement. The 'Args' section merely repeats names without description. Overall, the description adds meaning for only a subset of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a Brazilian samba percussion ensemble pattern, distinguishing it from the sibling songo pattern and explicitly contrasting it as a multi-instrument layered groove. The verb 'create' plus resource 'samba pattern' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts samba with songo (single drum-kit pattern), guiding the agent to choose this tool over create_songo_pattern. It also details four distinct styles with characteristics, implying when each is appropriate. However, it does not explicitly state when not to use it or mention prerequisites like required tracks or instrument configurations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_scale_runA

Create a scale run — ascending or descending scale sequence for fills and transitions.

Generates a sequence of scale notes moving up or down across one or more octaves. Used for drum fills, melodic transitions, lead build-ups, and bass walks.

scale: Scale type (major, minor, dorian, phrygian, blues, etc. — 14 types from music_theory). root: Root note name (C, C#, D, ... B). direction: "up" (ascending) or "down" (descending). octaves: Number of octaves to span (1-4). 1 = 7-8 notes, 2 = 14-15 notes, etc. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. step_duration: Duration of each note in beats (0.125 = 8th triplet, 0.25 = 16th). velocity: Note velocity 0-1. octave: Starting octave (1-7, default 4).

Returns total notes created and scale info.

Example: create_scale_run(scale="minor", root="A", direction="up", octaves=2, step_duration=0.0625)

ParametersJSON Schema
NameRequiredDescriptionDefault
rootYes
scaleYes
octaveNo
octavesNo
velocityNo
directionNoup
start_beatNo
unit_indexNo
track_indexNo
step_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the generated output (sequence of scale notes across octaves) and mentions the return value (total notes created, scale info). No annotations exist, so the description carries the burden; it provides reasonable behavioral insight without covering every edge case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise yet informative: opening verb phrase, a short description, parameter list, and an example. No wasted words, well-organized with line breaks for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, output schema exists), the description covers purpose, usage, parameters, and return value. It is self-contained and provides enough information for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 10 parameters are explained with brief descriptions (e.g., scale type includes 14 types from music_theory, step_duration examples). Schema coverage is 0%, so the description fully compensates by adding meaning beyond the schema titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool creates ascending or descending scale sequences for fills and transitions. Distinguishes from sibling 'create_' tools by specifying it generates a scale run rather than other patterns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists use cases (drum fills, melodic transitions, lead build-ups, bass walks), providing context for when to use. Does not specify when not to use or offer alternatives, but the listed uses are specific enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_second_lineA

Create a New Orleans second line percussion ensemble — street parade groove.

The New Orleans second line beat is one of the foundational rhythms of American music — the root of funk, R&B, and rock drumming. Born from jazz funeral parades and brass band street processions, it combines African rhythmic sensibility with European march tradition.

Instruments:

  1. BASS DRUM — Deep boom. Plays the "street beat": downbeat + syncopated "and" of 2 and 4. The backbone that drives the parade forward.

  2. SNARE DRUM — Backbeat on 2 and 4 with ghost notes on the "e" and "a" of beats. Loose, funky, slightly behind the beat feel.

  3. HI-HAT — Charleston rhythm (beat 1, "and" of 2, beat 3, "and" of 4) or straight 8ths depending on style. The pulse-keeper.

  4. TOM-TOM — Fills at phrase ends, rhythmic calls in Indian style. Adds melodic colour to the percussion arrangement.

  5. CYMBAL — Crash accents on phrase starts. Sparse, ceremonial.

styles: "traditional" — Classic street parade (early 20th century). Steady Charleston hi-hat, backbeat snare, syncopated bass. The original second line groove. "brass_band" — Modern brass band style (Dirty Dozen, Rebirth). Denser, funkier. More ghost notes, tom rolls, 8th-note hi-hat. "mardi_gras_indian" — Mardi Gras Indian style (Wild Tchoupitoulas). Call-and- response between tom and snare. Ritualistic, tribal. Sparse bass, tom-driven. "jazz_funeral" — Dirge to celebration. Bar 1: slow, sparse (dirge on the way to the cemetery). Bar 2: upbeat, driving (celebration on the way back). Dramatic dynamic shift. "bounce" — New Orleans bounce (1980s+, DJ Jimi, Magnolia Shorty). "Triggerman" double-time bass drum, 16th-note hi-hat, backbeat snare. The foundation of NOLA hip-hop.

Args: bars: Pattern length (4-16, even). style: Style name. velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. bass_pitch: Bass drum MIDI pitch (36 = C1). snare_pitch: Snare drum MIDI pitch (38 = D1). hi_hat_pitch: Hi-hat MIDI pitch (42 = F#1). tom_pitch: Tom-tom MIDI pitch (45 = A1). cymbal_pitch: Crash cymbal MIDI pitch (49 = C#2).

Returns notes created, instrument breakdown, and style info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNotraditional
velocityNo
tom_pitchNo
bass_pitchNo
start_beatNo
unit_indexNo
snare_pitchNo
track_indexNo
cymbal_pitchNo
hi_hat_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description adds some context (instruments, styles, return info) but fails to disclose key behavioral traits such as side effects, required permissions, or whether existing notes are modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose with historical and educational content that, while informative, is not essential for an AI agent. The core purpose is front-loaded, but the lengthy instrument and style explanations could be more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers instruments, styles, and parameters thoroughly. With an output schema present, return values are explained. However, missing prerequisites (e.g., required track setup) and integration context reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description includes an 'Args' section with meaningful descriptions for all 11 parameters (e.g., 'bars: Pattern length (4-16, even)', 'style: Style name'). This compensates fully, adding value beyond type and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a 'New Orleans second line percussion ensemble' with specific instruments and styles. It distinguishes from sibling tools like mcp_opendaw_create_samba_pattern or create_boom_bap by focusing on a unique rhythmic tradition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implies usage for creating second line patterns, but lacks when-not guidance or comparisons to other creation tools in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_section_transitionA

Create a complete section transition in one call — combines multiple automation tools.

The most common arrangement technique: moving from one section to another (verse→chorus, breakdown→drop, intro→main). Each preset combines filter sweeps, volume fades, mute automation, and impacts into a single coordinated transition. Replaces 3-5 individual calls.

transition_type: One of: "drop" — Breakdown→drop: filter close on synths, drums muted, then filter open + unmute + impact "buildup" — Verse→chorus: filter open on lead, volume fade in on pads, snare roll implied "breakdown" — Main→breakdown: filter close on drums, volume fade out on bass, mute synths "intro" — Silence→intro: volume fade in on all, filter open on pads "outro" — Main→outro: volume fade out on all, filter close on lead start_beat: Transition start position in beats. duration_beats: Total transition length in beats (default 16 = 4 bars). unit_indices: Comma-separated AU indices. Convention: drums=0, bass=1, lead/synth=2, pads=3. Adjust to match your arrangement. Default "0,1,2,3".

Returns summary of all automation created across units.

Examples: create_section_transition("drop", start_beat=32, duration_beats=16) → 32-48: filter close on synth, drums muted at 32, filter open at 44, unmute+impact at 48 create_section_transition("intro", start_beat=0, duration_beats=8) → 0-8: volume fade in on all, filter open on pads

ParametersJSON Schema
NameRequiredDescriptionDefault
start_beatNo
unit_indicesNo0,1,2,3
duration_beatsNo
transition_typeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description details what each transition type does (filter sweeps, volume fades, mute automation, impacts). Mentions return value (summary of automation). Does not mention if it overwrites existing automation, which would be useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with header, parameter list, and examples. Every sentence adds value. Could be slightly more concise, but the detail is justified for a complex composite tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity, annotations missing, and output schema present, the description covers purpose, all parameters, examples, and return value. It lacks error conditions or prerequisites (e.g., must have sections), but overall quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully documents all parameters: transition_type with all options, start_beat, duration_beats, unit_indices with conventions. The description fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a complete section transition combining multiple automation tools. It distinguishes from sibling tools by noting it replaces 3-5 individual calls. Each transition type is described with specific effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it's for moving between sections (verse->chorus, etc.) and that it replaces multiple calls. Provides examples but does not explicitly state when not to use it. Context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_sendA

Create a parallel FX send bus from an audio unit.

Creates a NEW AudioBusBox (FX bus) with its own AudioUnitBox, then sends a copy of src_unit's signal to that FX bus via AuxSendBox. The dry signal continues to the main output unchanged — this is a parallel send, not a redirect.

After creating the send, add effects (Reverb, Delay) to the FX bus unit using add_effect(fx_unit_index, effect_type). The FX bus unit index is returned.

src_unit: Source audio unit index (the instrument sending signal). name: Name for the FX bus (e.g. "Reverb Bus", "Delay Bus"). send_level_db: Send level in dB (-∞ to +12). -6dB is a good starting point. routing: 'pre' (pre-fader) or 'post' (post-fader, default).

Returns send_index on src AU, and fx_unit_index (the new FX bus AU index for adding effects).

Workflow: create_instrument_track → create_send → add_effect(Reverb on fx_unit_index)

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
routingYes
src_unitYes
send_level_dbYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

In the absence of annotations, the description carries the full burden. It explains the creation of new internal objects (AudioBusBox, etc.) and the signal flow (dry signal unchanged). It states the return indices. However, it does not explicitly address error cases (e.g., invalid src_unit) or performance implications. Still, the behavioral coverage is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise opening sentence, followed by technical details, parameter breakdown, return info, and a workflow example. It is detailed without being verbose; every sentence contributes necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (creating multiple bus/unit objects) and the presence of an output schema, the description covers all essential aspects: what is created, parameter details, return values, and usage workflow. An agent can confidently invoke this tool based on the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate fully. It does so by explaining each parameter: src_unit (source unit index), name (FX bus name), send_level_db (range -∞ to +12 with suggested value), routing ('pre' or 'post' with default). This adds critical meaning absent from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a parallel FX send bus, distinguishes it from a redirect, and explains the internal components (AudioBusBox, AudioUnitBox, AuxSendBox). The purpose is specific and unambiguous. Among siblings, there is no other create_send tool, but it differentiates from general audio bus creation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit workflow guidance: create_instrument_track → create_send → add_effect. It explains when to use this tool (parallel send) and what not to do (redirect). Parameter constraints are given with examples (e.g., send_level_db -∞ to +12, -6dB suggested). This leaves no ambiguity for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_sequenceA

Create a melodic sequence — repeat a pattern at transposed pitch levels.

The most fundamental compositional technique in Western music: take a melodic fragment, repeat it at a different pitch (usually up/down a 4th or 5th). Think baroque sequences (Pachelbel), jazz ii-V-I chains, film score ascending quint sequences, or EDM build-ups with rising motifs.

pattern: Comma-separated MIDI pitches (e.g. "60,62,64,67"). transposition: Semitones to shift each repeat (default 5 = perfect 4th up). Common: 5 (4th), 7 (5th), 2 (major 2nd), -2 (down), -5 (4th down). repeats: Number of transposed repetitions (1-8, default 3). direction: "up" (transpose up), "down" (transpose down), "alternating" (up/down/up...). segment_beats: Duration of each pattern repetition in beats (0.5-16, default 2). velocity_decay: Velocity change per repeat (-0.3 to 0.3). Positive = louder, negative = quieter (fade-out). 0 = constant. unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the sequence begins. velocity: Base velocity 0-1 (default 0.8).

Returns notes created, repeat count, total transposition.

ParametersJSON Schema
NameRequiredDescriptionDefault
patternNo60,62,64,60
repeatsNo
velocityNo
directionNoup
start_beatNo
unit_indexNo
track_indexNo
segment_beatsNo
transpositionNo
velocity_decayNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the core behavior (creating repeated transposed notes) and mentions the return values. However, it does not disclose whether the operation is destructive (e.g., overwrites existing notes) or requires specific track types, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening statement followed by detailed parameter descriptions. It is somewhat lengthy but every sentence adds value. A few parameter descriptions could be slightly more terse without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 10 parameters and moderate complexity, the description covers each parameter thoroughly and explains the return value. It lacks explicit information about prerequisites or side effects, but is largely complete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds extensive meaning to each parameter: pattern format, transposition ranges and common values, direction options, velocity decay range, etc. This far exceeds the schema's minimal titles and defaults, providing crucial guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as creating a melodic sequence by repeating a pattern at transposed pitch levels. It uses specific verbs ('create', 'repeat', 'transpose') and resource ('melodic sequence'), and distinguishes this from sibling tools by focusing on a fundamental compositional technique with concrete examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use the tool, citing musical examples (Pachelbel, jazz ii-V-I, film scores, EDM build-ups) and common transposition values. However, it does not explicitly state when not to use it or mention alternative tools among siblings, but the context is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_soliA

Create a soli — ensemble unison passage with octave doublings.

A soli is a section where all instruments play the same melodic line in rhythmic unison, typically at different octaves. Common in jazz big band (Basie, Ellington, Herman), orchestral tutti passages, and rock/metal unison riffs. Unlike a fugue (polyphonic imitation) or canon (delayed entry), a soli is simultaneous and homorhythmic.

Melody pattern: space-separated scale degrees (0=root, 2=2nd, 4=3rd, -1=7th below, etc.). Negative = below root. Rhythm pattern: space-separated durations in beats. Key root: C, C#, Db, D, ... B. Scale: major, minor, dorian, phrygian, lydian, mixolydian, aeolian, locrian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues, whole_tone. Voices: 2-5 (e.g. 3 = root octave + 1 octave up + 2 octaves up). Octave spread: how many octaves between lowest and highest voice.

Creates voices on track_index, track_index+1, ... track_index+voices-1.

ParametersJSON Schema
NameRequiredDescriptionDefault
voicesNo
key_rootNoC
velocityNo
scale_nameNomajor
start_beatNo
unit_indexNo
track_indexNo
octave_spreadNo
melody_patternNo0 2 4 2 0 -1 0 3
rhythm_patternNo0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It explains that voices are created on consecutive tracks starting at track_index, and details the meaning of melody and rhythm patterns. It does not disclose whether tracks must already exist, what happens to existing data, or any side effects like track creation. This is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured. It front-loads the definition and usage context, then provides parameter details. Every section adds value, though the parameter list could be condensed into a table. Overall, it is efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters and an output schema, the description explains the input parameters and the effect on tracks well. It does not describe the return value (e.g., created note events), but the output schema likely covers that. It is mostly complete for an agent to understand how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain parameters. It clearly explains melody_pattern (scale degrees), rhythm_pattern (durations), key_root, scale_name, voices (2-5), and octave_spread. However, it does not explain velocity, start_beat, unit_index, or track_index. This covers 6 of 10 parameters, adding significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a soli — ensemble unison passage with octave doublings.' It defines the musical concept, distinguishes it from fugue and canon, and provides technical details about melody/rhythm patterns, scale degrees, and voicing. This leaves no ambiguity about the tool's purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when a soli is common (jazz big band, orchestral tutti, rock/metal riffs) and contrasts it with fugue and canon. However, it does not explicitly state when to avoid this tool or compare it to sibling tools like create_fugue or create_canon, nor does it specify prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_soloA

Create a genre-specific melodic solo over a chord progression.

Generates a complete solo line using vocabulary appropriate to the chosen style. Unlike generate_melody (contour-guided) or create_random_walk (stepwise), this tool uses genre-specific soloing techniques:

  • bebop: Chromatic approach tones, chord-tone targeting on strong beats, enclosure (upper+lower chromatic neighbor), bebop scale passing notes, ii-V-I arpeggio fluency. Charlie Parker, Dizzy Gillespie, Clifford Brown.

  • blues: Minor pentatonic + blue notes (b5, b3 bent), repetition of short motifs with variation, call-response phrasing, string-bending aesthetic via pitch slides. B.B. King, Eric Clapton, Stevie Ray Vaughan.

  • rock: Pentatonic positions, repeated riffs, wide interval jumps, rhythmic syncopation, climax-building through register shifts. Jimmy Page, Hendrix, Gilmour.

  • jazz_swing: Swing 8th notes, guide-tone lines, chord-tone on beat 1+3, arpeggio + approach patterns. Lester Young, Sonny Rollins.

  • fusion: Mixolydian/dorian modes, odd-meter phrasing, wide intervals, chromatic passing, rhythmic displacement. Metheny, Brecker, Holdsworth.

solo_type: bebop | blues | rock | jazz_swing | fusion key_root: Root note (C, C#, D, ... B) scale_type: major | minor | dorian | mixolydian | blues | pentatonic_minor bars: Solo length (4-32, default 8) octave: MIDI octave for solo (4 = C4=60) velocity: Base velocity 0-1 seed: PRNG seed for reproducibility

Returns notes created and solo characteristics.

Example: create_solo(solo_type="bebop", key_root="F", scale_type="major", bars=8) create_solo(solo_type="blues", key_root="A", scale_type="blues", bars=12) create_solo(solo_type="rock", key_root="E", scale_type="pentatonic_minor", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
seedNo
octaveNo
key_rootNoC
velocityNo
solo_typeNobebop
scale_typeNomajor
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It explains that the tool generates a complete solo line and returns notes and solo characteristics. However, it does not disclose potential side effects (e.g., does it overwrite existing notes on a track?), permissions needed, or constraints (e.g., track must have a chord progression). The behavioral detail is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a one-line summary, followed by a bulleted list of genre techniques, parameter list, and examples. It is relatively long but every sentence adds value, especially the detailed genre explanations. The structure aids quick scanning for relevant details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the large sibling toolset (including similar tools like generate_melody and create_random_walk), the description clearly differentiates this tool. It mentions an output schema and states it returns 'notes created and solo characteristics,' so return values are covered. The missing parameter details for start_beat, unit_index, and track_index are gaps, but overall the description is complete for the core use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (no descriptions in the input schema). The description covers 7 of 10 parameters (solo_type, key_root, scale_type, bars, octave, velocity, seed) with details on default values and examples. However, it omits start_beat, unit_index, and track_index, which are crucial for placement. The description adds significant meaning beyond the schema but misses some parameters, so it partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a 'genre-specific melodic solo over a chord progression.' It explicitly distinguishes itself from generate_melody and create_random_walk_melody, specifying that it uses genre-specific soloing techniques. The verb 'create' and resource 'solo' are specific, and the scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternatives: 'Unlike generate_melody (contour-guided) or create_random_walk (stepwise), this tool uses genre-specific soloing techniques.' It also lists valid values for solo_type, key_root, scale_type, etc., and provides examples, helping the agent understand the context and prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_solo_automationA

Mute all tracks except the solo track for a beat range, then restore.

Essential production technique: spotlight one element (bass solo, drum break, vocal spotlight) while everything else drops out. Without this you need N separate create_mute_automation calls with coordinated timing — this tool does it in one shot and guarantees all tracks return audible after.

Internally calls create_mute_automation for each non-solo track with events [[0, false], [start_beat, true], [end_beat, false]] — audible before solo, muted during, audible after.

solo_track: Track index that stays audible throughout (0-based). total_tracks: Total number of tracks to manage (e.g. 4 for a 4-track arrangement). start_beat: Beat position where solo begins (others mute). end_beat: Beat position where solo ends (others unmute). unit_indices: Optional comma-separated AU indices (e.g. "0,1,2,3"). If empty, uses 0..total_tracks-1.

Returns per-track mute schedule and confirmation.

Examples:

Drum break: drums solo for 4 beats (1 bar at 120 BPM)

create_solo_automation(solo_track=0, total_tracks=4, start_beat=8, end_beat=12)

Bass spotlight at bar 9

create_solo_automation(solo_track=1, total_tracks=4, start_beat=32, end_beat=40)

ParametersJSON Schema
NameRequiredDescriptionDefault
end_beatYes
solo_trackYes
start_beatYes
total_tracksYes
unit_indicesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses internal behavior: it describes the automation events generated ('[[0, false], [start_beat, true], [end_beat, false]]') and confirms that all tracks are restored. This provides comprehensive behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear breakdown: purpose, benefit, internal mechanism, parameter list, and examples. It is slightly lengthy but every sentence adds value; could be slightly more concise but remains effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, output schema exists) and no annotations, the description covers all aspects: purpose, usage context, internal logic, parameter semantics, return value, and practical examples. It is complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates by defining each parameter (solo_track, total_tracks, start_beat, end_beat, unit_indices) with clear explanations and examples, adding significant meaning beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Mute all tracks except the solo track for a beat range, then restore.' It uses a specific verb and resource combination, and explicitly differentiates itself from the sibling tool create_mute_automation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (e.g., 'Essential production technique: spotlight one element') and explicitly contrasts it with the alternative of multiple create_mute_automation calls, providing clear usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_sonata_formB

Create sonata form — exposition, development, recapitulation.

Sonata form is the structural foundation of classical symphonies, sonatas, string quartets, and concertos from Haydn through Mahler. Three main sections:

  1. EXPOSITION (bars 1-N): Two contrasting themes.

    • Theme 1 in the home key (tonic): stepwise, lyrical, conjunct

    • Transition: modulates from tonic to dominant (or relative major if minor key)

    • Theme 2 in the new key: more rhythmic, wider intervals

    • Closing group: cadential figures in the new key

  2. DEVELOPMENT (bars N+1 to N+M): Fragmentation and modulations.

    • Takes fragments from Theme 1 and Theme 2

    • Sequences through related keys (iii, vi, ii, IV)

    • Builds tension through rising sequences

    • Retransition: dominant pedal leading back to tonic

  3. RECAPITULATION (bars N+M+1 to end): Both themes in the tonic.

    • Theme 1 returns in tonic (as in exposition)

    • NO modulation — Theme 2 now in tonic (not dominant)

    • Closing group in tonic

    • Optional coda (4 bars): final cadential reinforcement

Melody track: track_index. Bass track: track_index + 1. The development section uses sequence-based modulation, the hallmark of classical development technique.

Scale options: major, minor, dorian, phrygian, lydian, mixolydian, aeolian, locrian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues, whole_tone.

ParametersJSON Schema
NameRequiredDescriptionDefault
key_rootNoC
velocityNo
recap_barsNo
scale_nameNomajor
start_beatNo
unit_indexNo
track_indexNo
exposition_barsNo
development_barsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It explains the structural output and track layout (melody track, bass track) but does not explicitly state that MIDI notes will be generated on the specified tracks or disclose side effects like overwriting existing data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with numbered sections but is verbose, including extensive musical theory that may not be necessary for tool selection. It is front-loaded with the purpose, but the length reduces conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no schema descriptions, no annotations), the description fails to cover key aspects like parameter defaults and behavior for parameters like start_beat, unit_index, and velocity. The output schema is missing, further reducing completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It lists scale_name options and implicitly explains track_index and track_index+1 for bass, but does not describe other parameters like key_root, velocity, exposition_bars, etc. Only partial parameter meaning is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a sonata form structure with three sections (exposition, development, recapitulation). It uses specific verbs and resources, distinguishing it from other 'create_*' tools by providing detailed classical music form content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the musical context of sonata form but does not explicitly state when to use this tool vs. other form tools (e.g., create_binary_form, create_ternary_form). Usage is implied but not compared or contrasted with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_songo_patternA

Create a songo drum pattern — the Cuban drum-kit fusion that revolutionized Latin music.

Songo emerged in the 1970s with Los Van Van (drummer Changuito). It fused son montuno, rumba, jazz, and rock drumming into a single drum-kit pattern — the first time Cuban percussion was adapted to a Western kit. Unlike clave (a timeline), tumbao (congas), or cascara (timbale shell), songo is a complete drum-kit groove: kick + snare + hi-hat + tom accents working together as one synchronized engine. It became the foundation of modern salsa, timba, and Latin jazz drumming.

The pattern is 2 bars in 4/4. Kick plays syncopated bombo notes, snare alternates between rim clicks and open hits, hi-hat plays a continuous 8th-note pattern with accents, and toms fill rhythmic gaps with tonal accents. The feel is loose but locked — every stroke relates to the 3-2 clave without explicitly playing it.

variations: "classic" — Original Los Van Van songo. Kick on 1, 2.5, 4, 6.5. Snare rim clicks on 3, 7. Open snare on 4.5. HH 8ths. "modern" — Timba-era songo (1990s+). Denser kick, ghost snare notes, tom fills on bar 2. More aggressive, busier. "fusion" — Jazz-influenced. Ride-like HH pattern, syncopated kick displacements, brush snare. Los Hermanos approach. "songo_funk" — Songo with funk inflection. Kick on 1, 1.75, 3.5, 4.75. Ghost snare 16ths. Backbeat on 2 and 4. Groove-oriented.

bars: Pattern length (2-16, must be even for 2-bar cycle). velocity: Base velocity (0-1). kick_pitch: MIDI pitch for kick drum (36 = C1). snare_pitch: MIDI pitch for snare (38 = D1). hh_pitch: MIDI pitch for hi-hat (42 = F#1). tom_pitch: MIDI pitch for tom accents (45 = A1).

Args: bars: Pattern length in bars (2-16, even). variation: Pattern variation (classic, modern, fusion, songo_funk). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. kick_pitch: Kick MIDI pitch. snare_pitch: Snare MIDI pitch. hh_pitch: Hi-hat MIDI pitch. tom_pitch: Tom MIDI pitch.

Returns notes created, stroke breakdown, and pattern info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
hh_pitchNo
velocityNo
tom_pitchNo
variationNoclassic
kick_pitchNo
start_beatNo
unit_indexNo
snare_pitchNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the pattern structure and variations, but does not disclose whether notes are added or overwritten, authentication needs, or side effects. Output is described as notes, stroke breakdown, and pattern info, but operational details like track setup are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is lengthy with a historical paragraph. While educational, it is somewhat verbose for an AI agent. However, it is well-structured with clear variation descriptions and front-loaded purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 variations, 10 parameters, output schema exists), the description covers musical context, variation details, and parameter basics. It mentions output content. Gaps: unit_index, track_index, and start_beat usage not fully explained. Overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 10 parameters with defaults but no descriptions. Description adds meaning for bars, variation, velocity, and pitches (e.g., '36 = C1'). However, unit_index, track_index, and start_beat are mentioned but not fully explained. Overall adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a songo drum pattern, a specific Cuban drum-kit fusion. It distinguishes songo from other patterns like clave, cascara, and tumbao, which are sibling tools. The purpose is specific and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for songo (Latin music, salsa, timba, Latin jazz) but lacks explicit guidance on when to use this tool versus alternatives like clave or tumbao. It implies usage through musical context but does not state when not to use or list competing tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_song_structureA

Create song structure markers for arrangement (intro/verse/chorus/bridge/outro).

Creates labeled markers at section boundaries, enabling agents to reason about song form. Reduces 5-10 marker calls to one structured call.

sections: JSON array of section objects: [{"name": "Intro", "bars": 4}, {"name": "Verse 1", "bars": 8}, ...]. If bars omitted, defaults to 8. Names are used as marker labels. unit_index: AU index (unused but kept for API consistency).

Returns created markers with positions and total duration.

Example: sections='[{"name":"Intro","bars":4},{"name":"Verse","bars":8},{"name":"Chorus","bars":8},{"name":"Outro","bars":4}]'

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionsYes
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It correctly states it creates labeled markers and reduces calls, but does not disclose potential side effects (e.g., overwriting existing markers at the same positions) or required permissions. The behavioral details are adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear first sentence stating purpose. It uses structured paragraphs and includes an example. However, the example could be integrated more cleanly, and the description is slightly verbose with 'enabling agents to reason about song form' which is somewhat redundant. Overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema (context signal), the description only needs to note return values, which it does ('Returns created markers with positions and total duration'). It covers both parameters adequately. Missing edge cases or error handling, but given the tool's simplicity, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates well. It explains the 'sections' parameter format (JSON array with name and bars), default bar value (8), and notes names become labels. It also clarifies 'unit_index' as unused but kept for API consistency, which adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'song structure markers for arrangement (intro/verse/chorus/bridge/outro)'. It distinguishes from siblings like mcp_opendaw_add_marker (single marker) and mcp_opendaw_analyze_song_structure (analysis), making the purpose specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating 'Reduces 5-10 marker calls to one structured call', guiding agents to use this instead of calling add_marker multiple times. However, it lacks explicit conditions for when not to use it (e.g., for single markers). The sibling mcp_opendaw_add_marker exists, creating a clear contrast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_song_with_variationsA

Build a complete song with real musical variations between sections — one call.

Unlike create_genre_sections (which repeats the same loop at different velocities), this creates a song where each section has actual musical variation: drum density changes, bass octave shifts, melody transforms, and track exclusion. All 14 genres supported.

sections: Comma-separated section specs. Each spec is: name:bars:velocity:preset

  • name: Section label (e.g. "verse1", "chorus", "bridge")

  • bars: Length in bars (4-32)

  • velocity: Base velocity 0-1

  • preset: One of:

    • "full" — all tracks, normal density

    • "drums_only" — drums only, others silenced

    • "drums_bass" — drums + bass, no harmony/melody

    • "full_busy" — all tracks, busy drums (density 1.5)

    • "breakdown" — sparse drums (0.3), no bass, inverted melody

    • "melody_transpose5" — full, melody transposed +5 semitones

    • "melody_transposeN" — full, melody transposed N semitones

    • "melody_invert" — full, melody inverted around middle C

    • "melody_reverse" — full, melody retrograde

    • "melody_octave_up" — full, melody up one octave

    • "bass_octave_up" — full, bass up one octave

    • "bass_sub" — full, bass down two octaves (sub bass)

    • "fade" — drums + bass, sparse, low velocity (outro)

    • "drop" — all tracks, busy drums, octave-up bass (climax)

Default: "intro:4:0.5:drums_only,verse1:8:0.8:full,chorus:8:1.0:full_busy, verse2:8:0.8:melody_transpose5,bridge:4:0.6:breakdown,outro:4:0.4:fade" = 36-bar song with 6 varied sections.

apply_mix: If True, calls apply_genre_mix after all sections. apply_humanize: If True, calls apply_genre_humanization after mix. apply_master: If True, calls add_mastering_chain after humanize.

Returns sections created, transforms per section, total notes, and pipeline status.

Example:

36-bar DnB song with 6 varied sections

create_song_with_variations("dnb")

48-bar house epic with custom sections

create_song_with_variations("house", sections="intro:8:0.4:drums_only,build:8:0.7:drums_bass,drop:8:1.0:drop, breakdown:8:0.5:breakdown,drop2:8:1.0:full_busy,outro:8:0.3:fade")

24-bar minimal techno

create_song_with_variations("techno", sections="intro:4:0.5:drums_only,main:8:0.8:full,drop:4:1.0:full_busy,outro:8:0.4:fade", apply_mix=True, apply_humanize=True, apply_master=True)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
rootNo
genreYes
sectionsNointro:4:0.5:drums_only,verse1:8:0.8:full,chorus:8:1.0:full_busy,verse2:8:0.8:melody_transpose5,bridge:4:0.6:breakdown,outro:4:0.4:fade
apply_mixNo
bass_trackNo
drum_trackNo
unit_indexNo
apply_masterNo
melody_trackNo
harmony_trackNo
apply_humanizeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although no annotations are provided, the description details the section format, available presets, optional pipeline steps (mix, humanize, master), and return values. It does not mention potential side effects on existing project state or clarify track usage, but covers the main behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, an exhaustive list of section presets, a compact explanation of flags, a return value summary, and multiple practical examples. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters, no annotations, and no visible output schema, the description covers the core functionality but omits details for several parameters and does not clarify what tracks are referenced or how the tool integrates with the existing project. The default section string is helpful, but track indices remain unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description compensates by thoroughly explaining the 'sections' parameter, the 'genre' (via examples and support statement), and the three boolean flags. However, parameters like bpm, root, bass_track, drum_track, melody_track, harmony_track, and unit_index are only briefly mentioned in examples or not described, leaving gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Build a complete song with real musical variations between sections — one call' and distinguishes from 'create_genre_sections' which repeats loops. Specifies that 14 genres are supported. The verb 'create' and resource 'song with variations' are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly contrasts with 'create_genre_sections' to guide when to use this tool. Provides default sections and examples for different genres, but does not explicitly state when not to use this tool or list alternatives beyond the one sibling mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_soul_arrangementA

Create a full soul arrangement — gospel drums + melodic bass + Rhodes chords + horn stabs across 4 tracks.

Motown / Stax / Atlantic soul — Otis Redding, Aretha Franklin, Marvin Gaye style:

  • Track 0: Drums — gospel-influenced: steady kick with ghost notes, backbeat snare, ride cymbal with triplet feel. Soul groove is laid-back but deep — the pocket is behind the beat.

  • Track 1: Bass — melodic walking bass: root → fifth → octave → walk to next chord tone. Not just root pumping — soul bass sings.

  • Track 2: Keys — Rhodes/Wurlitzer chord stabs on I-IV-vi-V gospel changes. Warm, gospel-tinged voicings (maj7, min9). The harmonic foundation — church-meets-R&B.

  • Track 3: Horns — Motown horn section: stabs on chord changes, melodic fills at phrase ends. Tight, arranged, call-and-response with vocals.

At 72 BPM (default), this creates the classic slow soul groove — deep pocket, gospel changes, warm Rhodes. The I-IV-vi-V progression is the gospel quartet influence that separates soul from funk (which vamps on one chord) and from pop (which uses I-V-vi-IV). Soul is about feel and melody, not rhythm complexity.

bpm: Tempo (65-90, default 72 = classic slow soul). bars: Arrangement length (4-16, default 8). Must be multiple of 4 for chord changes. root: Root note (C is a warm soul key). octave: MIDI octave for bass (2 = C2=36, standard soul bass register). unit_index: AU index with note tracks. drum_track / bass_track / keys_track / horns_track: Track indices.

Returns notes created per track and total.

Example: create_soul_arrangement(bpm=72, root="C", bars=8) create_soul_arrangement(bpm=80, root="F", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
keys_trackNo
start_beatNo
unit_indexNo
horns_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It explains what each track does and the default tempo, but does not disclose side effects like overwriting existing notes, whether tracks must be empty, or error conditions. The return format is briefly mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose, then details tracks, style, parameters, and examples. It is somewhat verbose with educational asides (e.g., comparing soul to funk), but overall well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, 0% schema coverage, and a complex output, the description thoroughly covers musical context, track roles, parameter constraints, and provides examples. It gives enough information for an AI agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description compensates by explaining most parameters (bpm range, bars multiple of 4, root, octave, track indices) with musical context. However, it omits 'velocity' and 'start_beat', which are in the schema but unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a full soul arrangement with specific instruments (gospel drums, melodic bass, Rhodes chords, horn stabs) across 4 tracks. It distinguishes from sibling arrangement tools by explicitly referencing the soul genre and artists like Otis Redding and Aretha Franklin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides stylistic context for when to use this tool (slow soul groove at 72 BPM, I-IV-vi-V progression) and compares it to funk and pop to differentiate. However, it does not explicitly state when not to use it or mention alternative tools among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_stabA

Create rhythmic stabs — short chord jabs that define house, disco, funk.

Generates short chord hits on a rhythmic grid. Each 'x' in the rhythm pattern triggers a stab (a short chord with fast decay). Perfect for:

  • House/disco off-beat stabs

  • Funk syncopated chord punches

  • Garage/shuffle stabs

  • Filling gaps between melody notes

chords: JSON array of chord specs, cycled through. Each chord is [root_name, chord_type]. Root names: C, C#, D, D#, E, F, F#, G, G#, A, A#, B (or flats) Chord types: maj, min, dom7, maj7, min7, sus2, sus4, add9, dim, aug Example: '[["C","min7"],["F","min7"]]' cycles between Cm7 and Fm7. Single chord: '[["F","dom7"]]' — same stab repeated. rhythm: Grid pattern using 'x' (stab), '-' (rest), '.' (ghost/light stab). 16th-note grid for one bar (16 chars) or 8th-note grid (8 chars). Examples: "x-x-x-x-" (off-beat 8th stabs), "x---x---" (backbeat), "..x-..x-" (ghost stabs), "xxxx-xxx" (funky busy pattern) unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the pattern starts. octave: Octave for chord voicing (3-6, default 4 = C4 root). velocity: Base velocity for stabs (0-1, ghost stabs use 0.5x). length_beats: Total length of the stab pattern in beats (default 4 = one bar). stab_duration: Duration of each stab in beats (0.0625-1.0, default 0.5 = eighth note).

Returns notes created, chord voicings, and rhythm hits.

ParametersJSON Schema
NameRequiredDescriptionDefault
chordsYes
octaveNo
rhythmNox-x-
velocityNo
start_beatNo
unit_indexNo
track_indexNo
length_beatsNo
stab_durationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains rhythmic grid, ghost stabs, chord cycling, and return values (notes, voicings, hits). No disclosure of destructiveness but behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with purpose and organized with parameter explanations. It is slightly verbose but every sentence adds value. Could be tightened without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and output schema exists, description covers all parameters, usage examples, return values, and genres. It fully compensates for missing schema descriptions and provides complete context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description provides all meaning. It explains each parameter: chords format (JSON array), rhythm pattern (x, -, .), defaults, and examples. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates rhythmic stabs (short chord jabs) and specifies genres like house, disco, funk. It distinguishes from siblings by focusing on stab patterns, not arpeggios or basslines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists perfect use cases (off-beat stabs, syncopated punches, etc.) but does not explicitly mention when not to use or compare to alternatives. This is clear context but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_stutterA

Create a stutter edit — rapid rhythmic repetitions with evolving rate and dynamics.

The classic stutter edit (BT, Imogen Heap, Deadmau5, Skrillex): take a note and repeat it with changing rhythmic density. Unlike create_chop (equal segments) or create_trill (alternating two notes), stutter edit evolves over time — accelerating, decelerating, or shifting accents. Essential for:

  • Build-up transitions before drops

  • Glitch fills at end of phrases

  • Vocal-chop style rhythmic patterns

  • Energy ramps in EDM/hip-hop

pitches: Comma-separated MIDI pitches (1-8, default "60"). Cycles through if repeat_count > len. rate: Base rhythmic subdivision — "16th" (0.25 beats), "32nd" (0.125), "64th" (0.0625), "triplet" (0.167), "triplet32" (0.083). pattern: How rate evolves — "constant" (same spacing throughout), "accelerate" (notes get closer — classic stutter build), "decelerate" (notes spread out — reverse stutter), "ping_pong" (alternate fast/slow), "random" (jittered spacing, seeded). repeat_count: Total repetitions (4-64, default 16). accent_pattern: Velocity accent structure — "none" (all equal), "downbeat" (every 4th accented), "1_and" (1st + 3rd accented), "1_e_and_a" (1st strongest, 3rd medium), "every_other" (alternating accent). velocity_ramp: Dynamic envelope — "constant", "fade_in", "fade_out", "fade_in_out", "build" (exponential increase). gate: Portion of each step with sound (0.3-1.0, default 0.85). Lower = more gaps = choppy. pitch_jitter: Random pitch variation in semitones (0-12, default 0). 0 = exact repeat. unit_index: AU index with note track (-1 = auto-find). track_index: Note track index. start_beat: Position in beats. velocity: Base velocity (0-1). seed: Random seed.

Returns notes created, pattern, rate, total length.

ParametersJSON Schema
NameRequiredDescriptionDefault
gateNo
rateNo16th
seedNo
patternNoaccelerate
pitchesNo60
velocityNo
start_beatNo
unit_indexNo
track_indexNo
pitch_jitterNo
repeat_countNo
velocity_rampNobuild
accent_patternNodownbeat

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes output (returns notes created, pattern, rate, total length) and parameters that affect behavior. Does not explicitly state whether existing notes are overwritten or appended, but likely adds new notes. Could mention if it modifies existing data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with an introductory sentence, sibling contrast, usage list, and clear parameter explanations. It is front-loaded with the main idea. Some parameter explanations could be slightly more compact, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (13 parameters, no schema descriptions, no annotations), the description covers purpose, differentiation, parameter details, and return values. It does not explicitly mention prerequisites or error conditions, but for a creation tool with many defaults and auto-find capabilities, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates thoroughly by explaining each parameter's meaning, valid values, defaults, and musical effect. For example, 'rate' values are listed with beat durations, 'pattern' types are described, 'accent_pattern' and 'velocity_ramp' are explained. This provides full meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Create a stutter edit — rapid rhythmic repetitions with evolving rate and dynamics'. Distinguishes from siblings like create_chop and create_trill by highlighting unique evolving characteristic. Provides specific verb+resource and context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly contrasts with create_chop and create_trill, and lists essential use cases (build-up transitions, glitch fills, vocal-chop patterns, energy ramps). Gives clear context when and why to use this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_synth_trackA

Create a new instrument audio unit with a synthesizer device and a note track.

Unlike create_instrument_track (which creates a Tape device for audio playback), this creates a MIDI synthesizer that responds to notes from create_note.

synth_type: 'vaporisateur' (subtractive synth, default), 'nano' (simple synth), 'soundfont' (SF2 player, needs sample), 'apparat' (FM synth). name: Display name for the instrument.

Returns unit_index and track_index for use with create_note.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
synth_typeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states what is created (synth + note track) but does not disclose potential side effects, authorization needs, or error conditions. Adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but could be more structured. It uses clear sentences and a list for synth types, but the comparison paragraph is slightly verbose. Overall good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, and the description correctly mentions the return values (unit_index, track_index) and their purpose. It also provides enough context about what the tool does relative to sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description provides all meaning. It explains the 'name' parameter as the display name and describes each synth_type option in detail, even though the schema lacks enums.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a synthesizer device and note track, and explicitly distinguishes it from create_instrument_track (which creates a Tape device). The different synth types are enumerated, making purpose very clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with create_instrument_track, telling the agent when to use this tool vs an alternative. It also explains the synth_type options and notes that the output indices are for use with create_note, guiding subsequent usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_synthwave_arrangementA

Create a full synthwave arrangement — retro drums + arpeggiated bass + dreamy pads + nostalgic lead across 4 tracks.

80s-inspired synthwave with the signature nostalgic feel — fundamentally different from other electronic genres:

  • Track 0: Drums — retro four-on-floor: kick on every quarter (softer than house), snare on beats 2 & 4, closed hats on all 8ths. The classic 80s drum machine feel — driving but not aggressive, nostalgic not punchy.

  • Track 1: Bass — ARPEGGIATED 16th notes: the engine of synthwave. Root → octave → fifth → octave pattern, driving and relentless. Not sustained like reggae, not sub-drone like techno — arpeggiated movement.

  • Track 2: Pads — sustained minor chords, full bar length. Dreamy, long release, filling the harmonic space. The nostalgic wash underneath.

  • Track 3: Lead — simple nostalgic melody following chord changes, with echo-like call-and-response. Memorable phrases that breathe.

Uses the classic synthwave progression i-VI-III-VII (Am-F-C-G in A minor) — the four chords that define the genre. Different from pop's I-V-vi-IV (same chords, different order and tonal centre — synthwave is minor-key, pop is major).

At 110 BPM (default), this creates the classic synthwave groove — mid-tempo, nostalgic, driving. The arpeggiated bass is the fundamental difference from all 11 other arrangements: house has off-beat stabs, techno has sub drones, synthwave has relentless 16th-note arpeggios.

bpm: Tempo (90-130, default 110 = classic synthwave). bars: Arrangement length (4-16, default 8). Must be multiple of 4 for chord cycle. root: Root note (A is the classic synthwave key — Am). octave: MIDI octave for bass (2 = A2=45, standard synthwave bass register). unit_index: AU index with note tracks. drum_track / bass_track / pad_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_synthwave_arrangement(bpm=110, root="A", bars=8) create_synthwave_arrangement(bpm=100, root="D", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoA
octaveNo
velocityNo
pad_trackNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the burden. It provides extensive detail on each track's role, the chord progression (i-VI-III-VII), tempo range (90-130 BPM, default 110), key (A minor), and the driving 16th-note arpeggio pattern. It does not disclose potential performance impacts or error handling, but the level of detail is high.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured with bullet points for each track and a clear parameter summary. It front-loads the purpose, then details each track's role, chord progression, and tempo. Every sentence adds value, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, no annotations, with output schema), the description is highly complete. It explains the genre, arrangement structure, chord progression, parameter constraints, and provides examples. It does not cover error conditions or return format (output schema exists), but overall very thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains bpm (range 90-130), bars (4-16, multiple of 4), root (default A), octave (default 2), and the track indices (drum_track, bass_track, etc.) including defaults. Some parameters like velocity and start_beat are only mentioned in passing, but most are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full synthwave arrangement' and details the four tracks with specific characteristics (retro drums, arpeggiated bass, dreamy pads, nostalgic lead). It distinguishes from sibling genre arrangement tools by explicitly contrasting synthwave's arpeggiated bass with house off-beat stabs and techno sub-drones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (when creating a synthwave-style arrangement) and contrasts it with other electronic genres (house, techno, reggae) by highlighting the unique arpeggiated bass. It does not explicitly state when not to use it, but the comparisons serve as implicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_taiko_ensembleA

Create a Japanese taiko ensemble — kumi-daiko group drumming with dramatic dynamics.

Taiko (literally "fat drum") is Japanese percussion with a history spanning over a millennium. Modern kumi-daiko (group taiko) was created in the 1950s by Daihachi Oguchi, combining multiple drum types into an ensemble. The defining characteristic is dramatic dynamic contrast — from near silence to thunderous power — and the use of silence (ma) as a structural element.

The four core instruments:

  1. ODAIKO — The largest drum. Deep, resonant, thunderous. Plays sparse, powerful hits that mark structural points. The "earthquake" of the ensemble. Very low pitch.

  2. CHU-DAIKO — Medium drum. The workhorse — plays the main rhythmic patterns. Mid-range pitch, full-bodied tone. Most of the notes.

  3. SHIME-DAIKO — Small, high-pitched drum. Plays fast, tight patterns and timekeeping. The "metronome" of the ensemble. High, snappy.

  4. ATARIGANE — Hand gong (metal). Plays accents and calls. Bright, metallic, piercing. Used for dramatic punctuation.

Stroke vocabulary (kakegoe): DON — Loud center hit (chu-daiko, odaiko) KA — Rim hit (shime-daiko) DOKO — Double hit (don-ko) TSU — Soft, muted stroke SU — Silence / rest (ma)

styles: "miyake" — Miyake-style: steady chu-daiko pulse with dramatic odaiko accents. Low stance, powerful, sustained. 4/4 with syncopated odaiko on 2.5 and 4. Shime plays continuous 8th notes. Atarigane calls on bar starts. "yatai" — Yatai-bayashi: festival style. Faster, more joyous. Shime plays 16th notes, chu-daiko alternates don/doko, odaiko on downbeats. Atarigane on offbeats. "edo" — Edo-bayashi: Edo period festival. Steady, march-like. Chu-daiko on 1 and 3, shime on all 8ths, odaiko sparse (only on phrase ends). Atarigane sparse. "hachijo" — Hachijo-style: soloistic, dramatic. Long odaiko rolls with chu-daiko accents. Ma (silence) between phrases. Sparse but powerful. Slow tempo feel. "omega" — Modern taiko (Kodo-style). Dense, aggressive, contemporary. All four instruments at high density. Odaiko on every beat, chu-daiko 16ths, shime 32nd rolls, atarigane accents. Maximum energy.

Args: bars: Pattern length in bars (4-32, even). style: Style name (miyake, yatai, edo, hachijo, omega). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. odaiko_pitch: Odaiko (large drum) MIDI pitch (35 = B0). chu_daiko_pitch: Chu-daiko (medium drum) MIDI pitch (38 = D1). shime_pitch: Shime-daiko (small drum) MIDI pitch (42 = F#1). atarigane_pitch: Atarigane (gong) MIDI pitch (50 = D2).

Returns notes created, instrument breakdown, and style info.

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
styleNomiyake
velocityNo
start_beatNo
unit_indexNo
shime_pitchNo
track_indexNo
odaiko_pitchNo
atarigane_pitchNo
chu_daiko_pitchNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explains that the tool generates MIDI notes for four instruments with defined pitches and styles, and returns a breakdown. It lacks details on whether it overwrites or appends to existing notes, but covers key behavioral aspects of the generative process.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and includes historical context that may not be essential for tool usage. While well-structured with instrument, stroke, and style sections, it could be more concise by trimming extraneous cultural background.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, no annotations, no schema descriptions), the description provides substantial context on instruments and styles but lacks clarity on how the generation interacts with existing content (e.g., overwrite vs. append) and the exact role of some parameters like unit_index.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It richly describes styles and pitches (e.g., '35 = B0'), but fails to explain positional parameters like unit_index, track_index, and start_beat. Partial compensation—some parameters are well-documented, others are merely listed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a Japanese taiko ensemble (kumi-daiko) with specific instruments and styles. The purpose is unambiguous and distinct from sibling tools like create_djembe_ensemble or create_korean_percussion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive cultural and technical context but lacks explicit guidance on when to use this tool versus alternatives. No 'when to use' or 'when not to use' statements, leaving the agent to infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_talaA

Create an Indian classical tala — cyclic rhythmic structure with vibhag sections and tali/khali markings.

A tala is a cyclic rhythmic framework in Indian classical music. Unlike Western meter (which groups beats into uniform bars), a tala divides its cycle into vibhags (sections) of unequal length, each marked by tali (clap) or khali (wave). The theka — a sequence of named tabla strokes (bols) — defines the characteristic pattern of each tala.

The cycle (avartan) repeats, with the sam (first beat) being the strongest point. Tali beats are played with emphasis; khali beats are played softly (the "empty" section). This dynamic contrast gives Indian rhythm its distinctive breathing quality.

Talas: teental — 16 beats, 4+4+4+4 vibhags. The most common tala. Tali at beats 1, 5, 13; khali at beat 9. Dha-Dhin-Dhin-Dha pattern. ektal — 12 beats, 2+2+2+2+2+2 vibhags. Used in classical vocal and sitar. Tali at 1, 5, 9, 11; khali at 3, 7. jhaptal — 10 beats, 2+3+2+3 vibhags. Asymmetric grouping. Tali at 1, 3, 8; khali at 6. rupak — 7 beats, 3+2+2 vibhags. Unusual — starts with khali (no clap on sam). Tali at 4, 6; khali at 1. dadra — 6 beats, 3+3 vibhags. Light classical, semi-classical. Tali at 1; khali at 4. kehartwa — 8 beats, 4+4 vibhags. Tali at 1; khali at 5.

Laya (tempo): vilambit — slow, 2-beat note duration (sustained strokes) madhya — medium, 1-beat note duration drut — fast, 0.5-beat note duration

Each bol maps to a MIDI pitch representing the tabla stroke character: Dha/Dhin (bayan+dayan) -> lower register (36-38) Ti/Na/Tin/Ta (dayan) -> higher register (46-52)

Args: tala_name: Tala name (teental, ektal, jhaptal, rupak, dadra, kehartwa). cycles: Number of avartan cycles (1-16). laya: Tempo (vilambit, madhya, drut). velocity: Base velocity 0-1. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, vibhag structure, tali/khali positions, and bols sequence.

ParametersJSON Schema
NameRequiredDescriptionDefault
layaNomadhya
cyclesNo
velocityNo
tala_nameNoteental
start_beatNo
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden of behavioral disclosure. It explains the output (notes, vibhag structure, tali/khali positions, bols) and the mapping of bols to MIDI pitches. However, it does not disclose potential side effects like overwriting existing notes or whether the tool is destructive, but given it's a creation tool, the transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but well-organized with sections for context, tala examples, laya, bol mapping, and parameters. Every sentence provides value, though the educational content could be slightly trimmed without losing clarity. It is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of Indian classical tala and the tool's 7 parameters, the description is highly complete. It explains the cyclic structure, specific tala patterns, tempo options, and bol-to-MIDI mapping. The output schema exists, so the description correctly focuses on input semantics and behavioral context without needing to detail return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It provides a clear 'Args' section with detailed explanations for each parameter, including defaults, ranges, and examples. It also explains domain-specific concepts like tala names and laya types, adding significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an Indian classical tala, defining it as a cyclic rhythmic structure with vibhag sections and tali/khali markings. It distinguishes from Western meter and provides specific examples of talas, making the purpose unambiguous and differentiating it from sibling tools like create_polyrhythm or create_euclidean_rhythm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive context on when to use this tool, including the structure of various talas, the concept of theka, and laya tempos. However, it does not explicitly state when not to use it or compare it to alternative tools, such as other rhythm creation tools, leaving some ambiguity for an AI agent deciding between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_techno_arrangementA

Create a full techno arrangement — drums + sub-bass drone + percussive stabs across 3 tracks.

Berlin/Detroit techno with hypnotic, minimalist elements locked together:

  • Track 0: Drums — relentless four-on-floor with industrial hats and claps, the engine

  • Track 1: Bass — sustained sub-bass drone with root shifts per phrase, not rhythmic but continuous — the hypnotic foundation that drives the groove underground

  • Track 2: Stabs — percussive atonal stabs on off-beats, the signature Detroit sound

At 130 BPM (default), this creates the classic warehouse techno feel. The sub-bass drone is the key difference from house — instead of off-beat bass notes, it's a continuous low-end that shifts root notes across phrases, creating tension and release.

bpm: Tempo (125-145, default 130 = classic techno). bars: Arrangement length (8-32, default 8). Techno needs longer forms. root: Root note (C is the classic techno key for sub-bass). octave: MIDI octave for sub-bass (2 = C2=36, low but audible). unit_index: AU index with note tracks. drum_track / bass_track / stab_track: Track indices.

Returns notes created per track and total.

Example: create_techno_arrangement(bpm=130, root="C", bars=8) create_techno_arrangement(bpm=138, root="A", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoC
octaveNo
velocityNo
bass_trackNo
drum_trackNo
stab_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It describes what is created (notes on three tracks) and mentions the return value. However, it doesn't clarify whether existing notes are cleared, prerequisites like track existence, or potential side effects, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with purpose, then track details, then parameter list, and examples. It is verbose but each sentence adds value, and examples aid understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers genre and track roles well, and mentions return values. However, it lacks details on prerequisites (e.g., track requirements), side effects, and two parameters are unexplained. With output schema present, return value explanation is not required but still helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds significant value by explaining 8 of 10 parameters (bpm, bars, root, octave, unit_index, track indices) with ranges, defaults, and context. It omits velocity and start_beat, which are minor gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a full techno arrangement' and specifies the three tracks (drums, sub-bass drone, stabs), distinguishing it from siblings like create_house_arrangement by emphasizing techno-specific elements and the difference from house.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use this tool (for techno) and contrasts with house music, offering implicit guidance. However, it doesn't explicitly list alternatives or when not to use it, which is acceptable given many sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_tempo_rampA

Create a smooth tempo ramp (ritardando or accelerando) across a beat range.

Adds a series of tempo change events with linear interpolation, creating a gradual BPM transition. This is the musical foundation for ritardando (slowing down) and accelerando (speeding up) — essential for expressive transitions, endings, and dramatic section changes.

Uses the same ValueEventBox mechanism as add_tempo_change, but creates multiple events along the beat range for a smooth curve.

start_beat: Beginning of the ramp in beats. end_beat: End of the ramp in beats. start_bpm: Starting BPM (60-240). end_bpm: Target BPM (60-240). curve: "linear" (smooth, default), "exp" (ease-in, gradual start), "log" (ease-out, fast start then settle). steps: Number of tempo events to create (default 16 = smooth ramp). Fewer steps = more stepped/quantized feel.

Returns events created, ramp config, and BPM preview at key points.

Examples: create_tempo_ramp(start_beat=60, end_beat=64, start_bpm=120, end_bpm=90) -> Ritardando: 120->90 BPM over 4 beats (ending slowdown) create_tempo_ramp(start_beat=0, end_beat=8, start_bpm=100, end_bpm=140, curve="exp") -> Accelerando: 100->140 BPM over 8 beats, exp curve (gradual start) create_tempo_ramp(start_beat=32, end_beat=48, start_bpm=140, end_bpm=140) -> No-op ramp (same BPM) — useful as placeholder or for testing

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNolinear
stepsNo
end_bpmYes
end_beatYes
start_bpmYes
start_beatYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the mechanism (linear interpolation, multiple ValueEventBox events), return value (events created, config, BPM preview), and defaults (steps=16). It lacks details on side effects or permissions but is sufficiently transparent for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, mechanism, parameter list, return info, examples. Each sentence adds value without redundancy. It's comprehensive yet concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, 4 required, output schema exists), the description covers purpose, all parameters with details, return value, and examples. It provides enough information for an AI agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains all 6 parameters: start_beat, end_beat, start_bpm, end_bpm, curve (with options and default), steps (with effect of fewer steps). Three examples demonstrate usage. This fully compensates for the lack of parameter descriptions in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a smooth tempo ramp (ritardando or accelerando) across a beat range.' It specifies the verb (create), resource (tempo ramp), and musical context. It distinguishes from sibling tool add_tempo_change by noting it creates multiple events for a smooth curve.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context for use: 'essential for expressive transitions, endings, and dramatic section changes.' It compares to add_tempo_change (single event vs multiple). While it doesn't explicitly state when not to use, the guidance is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_ternary_formB

Create ternary form — ABA with contrasting middle section.

Ternary form (ABA) is one of the most fundamental structures in Western music. The outer A sections are related (often identical, or A' with ornamentation), while the middle B section provides contrast. Used in:

  • Minuet & Trio (Haydn, Mozart): A=minuet, B=trio, A=minuet da capo

  • Da capo aria (Baroque opera): A=main aria, B=contrasting middle emotion, A=ornamented return

  • Chopin Nocturnes: A=lyrical theme, B=agitated middle, A=ornamented

  • Pop/jazz ballads: A=head, B=bridge/solo, A=head out

B section contrast types:

  • trio: Subdominant key (IV), smoother rhythm, thinner texture. Classical minuet & trio.

  • dominant: Dominant key (V), more active rhythm, builds tension. Beethoven scherzo style.

  • relative: Relative minor/major, darker/lighter character. Schubert impromptu middle sections.

  • episode: Same key, completely different melodic material. Chopin nocturne B sections.

  • development: Fragmentation of A material, modulating. Late classical/romantic expansion.

A' (return): If a_prime_ornamented=True, adds passing tones, trill-like ornaments, and slight rhythmic variation to the A material. Da capo aria / Chopin nocturne practice.

Melody on track_index, bass on track_index+1.

ParametersJSON Schema
NameRequiredDescriptionDefault
a_barsNo
b_barsNo
key_rootNoC
velocityNo
b_contrastNotrio
scale_nameNomajor
start_beatNo
unit_indexNo
track_indexNo
a_prime_ornamentedNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses structure (ABA), contrast types, and ornamentation behavior. It also notes that melody goes on track_index and bass on track_index+1. However, it does not mention side effects, overwriting behavior, or scope of changes (e.g., does it clear existing notes?). With no annotations, more detail is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose but becomes lengthy with historical and educational detail. While informative, it could be more concise for an AI agent, as the extensive examples and explanations may distract from the key operational guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters), the description covers musical theory well but lacks practical details like placement (start_beat, unit_index) and velocity. It assumes an output schema exists but does not clarify return values. Gaps remain for a complete operational understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains concepts like A and B bars, contrast types, and ornamentation, which map to some parameters. However, parameters like velocity, start_beat, and unit_index are not mentioned. With 0% schema coverage, the description partially compensates but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence clearly states the tool creates ternary form (ABA) with contrasting middle section. The verb 'create' plus resource 'ternary form' is specific, and the educational context distinguishes it from other form-creating siblings like binary or sonata form.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what ternary form is and provides genre examples, but it does not explicitly state when to use this tool versus alternatives (e.g., binary form, sonata form, rondo). No guidance on when not to use it or comparison with other form tools is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_time_stretched_clipB

Create a time-stretched audio clip in session view.

sample_id: ID from mcp_opendaw_load_audio. unit_index: Audio unit index. clip_index: Slot index in clip launcher. track_index: Audio track index within AU. bpm: Source BPM of the sample. playback_rate: Playback rate (1.0 = normal, 0.5 = half speed, 2.0 = double). transient_mode: "Pingpong", "Monoton", "Cycles", or "Plode".

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
sample_idYes
clip_indexYes
unit_indexYes
track_indexYes
playback_rateYes
transient_modeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only says 'Create a time-stretched audio clip' without disclosing side effects, permissions, or interactions with existing clips.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a short paragraph followed by bullet points for parameters, but could be better structured with a separate purpose line.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameters but lacks overall behavioral context (e.g., prerequisites like loaded audio, what happens on success). Output schema exists, so return values are not needed, but more creation context would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description adds meaning for most parameters (e.g., sample_id source, playback_rate values, transient_mode options), though some like clip_index and track_index remain somewhat vague.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'time-stretched audio clip' in 'session view', distinguishing it from sibling tools like create_pitch_stretched_clip and create_time_stretched_region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides parameter explanations but no guidance on when to use this tool versus alternatives, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_time_stretched_regionA

Place a time-stretched audio region on a track.

Unlike place_audio_region (which uses TimeBase.Seconds), this creates a musically-timed region with warp markers. Audio plays back at a different speed while staying in sync with the project tempo.

sample_id: The ID returned by mcp_opendaw_load_audio. unit_index: Audio unit index (default 0). start_beat: Beat position to place the region. track_index: Track index within the audio unit (default 0). playback_rate: Rate multiplier (1.0 = original, 0.5 = half-speed, 2.0 = double). transient_mode: "once", "repeat", or "pingpong" (default). bpm: Source BPM of the sample (for warp marker calculation).

Returns position, duration in PPQN, and playback rate.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes
sample_idYes
start_beatYes
unit_indexYes
track_indexYes
playback_rateYes
transient_modeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must bear the full burden. It explains that audio plays at a different speed while syncing to project tempo and mentions warp markers. It lacks details on potential side effects or permissions, but for a creation tool, the core behavior is well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action and a key differentiator, followed by a compact parameter list. Every sentence adds value without redundancy. It is efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 params, no annotations), the description is thorough. It explains the concept, differentiates from a sibling, lists all params with defaults, and summarizes the return values. The presence of an output schema complements the brief return description, making it complete for an agent to use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must explain all parameters. It does so comprehensively: sample_id links to load_audio, unit_index defaults, start_beat is positional, playback_rate with examples, transient_mode with valid values, and bpm for warp calculation. Each parameter's purpose is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource: 'Place a time-stretched audio region on a track.' It explicitly contrasts with the sibling tool place_audio_region, highlighting the musical timing and warp markers, which effectively distinguishes it from similar tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance by contrasting with place_audio_region, stating that this tool uses musical timing (beats) instead of seconds. This helps the agent decide when to use this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_track_regionA

Create a region on any track (note or value) using the generic createTrackRegion API.

Automatically detects track type and creates the appropriate region:

  • Note track → NoteRegionBox with NoteEventCollection

  • Value track → ValueRegionBox with ValueEventCollection Returns Option.None (error) for audio tracks — use place_audio_region instead.

unit_index: Audio unit index (-1 = search all AUs). track_index: Track index within the AU. start_beat: Beat position for the region. duration_beats: Duration in beats. name: Display name (empty = auto: "Notes" or "Automation"). hue: Color 0-360 (-1 = auto from track type).

Returns region UUID, type, and position.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
nameYes
start_beatYes
unit_indexYes
track_indexYes
duration_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses auto-detection of track type and returns error for audio tracks, but lacks details on side effects, permission requirements, or idempotency. A 3 is appropriate for moderate disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections and bullet points. Every sentence adds value; no fluff. Efficiently communicates essential information in a compact form.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core behaviors, parameter meanings, and return fields. Output schema exists, so return details are less critical. Could mention edge cases like invalid track index or overlapping regions, but overall adequate for agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must explain all parameters. It does so comprehensively: unit_index with default value note, track_index, start_beat, duration_beats, name with auto-labeling, and hue with color range and auto setting. Adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool creates a region on any track (note or value), automatically detects track type, and distinguishes itself from place_audio_region for audio tracks. The description is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool (note and value tracks) and when to use an alternative (place_audio_region for audio tracks). Provides clear guidance on auto-detection and error handling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_trance_arrangementA

Create a full trance arrangement — driving drums + rolling bass + supersaw arp + pluck lead across 4 tracks.

Uplifting trance with the signature euphoric energy — fundamentally different from other electronic genres:

  • Track 0: Drums — driving four-on-floor: kick on every quarter (hard, consistent), clap on 2 & 4, open hat on off-beats (0.5, 1.5, 2.5, 3.5). The relentless pulse of trance — harder than synthwave, faster than house. Optional snare rush buildup on last bar of each 4-bar phrase.

  • Track 1: Bass — rolling off-beat pattern: 8th notes on the "and" of every beat (0.5, 1.5, 2.5, 3.5), NOT on the quarter. Creates the "rolling" feel that drives trance forward. Root → octave alternation per bar. Different from house (off-beat stabs) — trance bass is sustained 8ths.

  • Track 2: Supersaw arp — layered chord stabs on quarter notes: root position triad (root + third + fifth) played as 16th-note arpeggio pattern per beat. The euphoric wall of sound. i-VI-III-VII progression.

  • Track 3: Pluck lead — staccato synth plucks: short melodic phrases following chord changes, mostly off-beat with occasional downbeats. The "-answer" to the supersaw's "call". Echo-like spacing.

Uses the classic trance progression i-VI-III-VII (Am-F-C-G transposed) — same as synthwave but faster and euphoric, not nostalgic. The energy is in the supersaw arp (wall of sound) and rolling bass (relentless 8ths).

At 138 BPM (default), this creates classic uplifting trance — fast, driving, euphoric. The rolling off-beat bass is the fundamental difference from all 12 other arrangements: house has off-beat stabs (short), techno has sub drones (sustained), synthwave has 16th arpeggios (melodic), trance has rolling 8ths (driving, off-beat, sustained).

bpm: Tempo (128-145, default 138 = classic uplifting trance). bars: Arrangement length (8-16, default 8). Must be multiple of 4. root: Root note (F is a classic trance key — Fm). octave: MIDI octave for bass (2 = F2=41, standard trance bass register). unit_index: AU index with note tracks. drum_track / bass_track / arp_track / lead_track: Track indices.

Returns notes created per track and total.

Example: create_trance_arrangement(bpm=138, root="F", bars=8) create_trance_arrangement(bpm=140, root="C", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF
octaveNo
velocityNo
arp_trackNo
bass_trackNo
drum_trackNo
lead_trackNo
start_beatNo
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses per-track patterns, default values, and output summary (notes per track and total). However, it does not clarify whether existing track content is overwritten or appended, missing a key behavioral aspect. Overall, very detailed but leaves some edge cases unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-structured: purpose first, then track-by-track details, genre contrasts, parameter list, examples. Some redundancy in contrasting with other genres, but each sentence adds value. Could be slightly tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and output schema present, the description covers genre-specific context thoroughly, differentiates from siblings, and provides examples. Missing parameter explanations for velocity/start_beat/unit_index and no mention of existing track handling. Complete for the core use case but not fully exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must explain parameters. It explains 8 of 11 parameters (bpm, bars, root, octave, drum_track, bass_track, arp_track, lead_track) with meaningful context (e.g., 'root: Root note (F is a classic trance key — Fm)'). Missing descriptions for velocity, start_beat, and unit_index. Good overall coverage but not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a full trance arrangement with specific track roles (drums, bass, supersaw arp, pluck lead). It explicitly differentiates trance from sibling genres (house, techno, synthwave) by contrasting musical characteristics like bass pattern and energy, making the purpose distinct among many genre-specific arrangement tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when to use (uplifting trance) and specifies parameters (bpm 128-145, bars multiple of 4, root note F). Implicitly contrasts with other genre tools. Does not explicitly state when not to use, but sibling differentiation is strong enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_trap_arrangementB

Create a full trap arrangement — drums + 808 bass + bell melody across 3 tracks in one call.

Trap arrangement with all elements locked together:

  • Track 0: Drums — trap hi-hat rolls with triplet bursts, syncopated kick, snare on 3

  • Track 1: Bass — 808 sub-bass slides: long sustained notes with pitch slides, characteristic trap bass that glides between root notes

  • Track 2: Melody — bell/glockenspiel plucks in minor key, sparse and atmospheric

At 140 BPM (default), this creates the modern trap sound. The 808 bass slides are the signature — long glides between root notes that create the dark, menacing low-end. The bell melody floats above with sparse minor-key phrases.

bpm: Tempo (130-160, default 140 = modern trap). bars: Arrangement length (4-32, default 8). root: Root note (F# minor is the most common trap key). octave: MIDI octave for 808 bass (1 = C1=24, sub-bass territory). unit_index: AU index with note tracks. drum_track / bass_track / melody_track: Track indices.

Returns notes created per track and total.

Example: create_trap_arrangement(bpm=140, root="F#", bars=8) create_trap_arrangement(bpm=150, root="A", bars=16)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
barsNo
rootNoF#
octaveNo
velocityNo
bass_trackNo
drum_trackNo
start_beatNo
unit_indexNo
melody_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description adds musical context but fails to state whether existing track content is overwritten, if tracks must pre-exist, or other side effects. 'Locked together' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: purpose, track breakdown, parameter list, examples. Some musical elaboration could be trimmed for brevity, but generally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks critical preconditions (e.g., track existence), behavior on existing notes, and interaction with project state. Output description is brief but covered by output schema presence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description explains 7 of 10 parameters (bpm, bars, root, octave, unit_index, track indices) with defaults and ranges. Missing velocity and start_beat, but adds musical context for some params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a full trap arrangement with drums, 808 bass, and bell melody across 3 tracks. It distinguishes this from siblings like create_afrobeat_arrangement by specifying genre and components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives (e.g., other create_*_arrangement tools). The examples show usage but lack context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_trap_rollsA

Create trap hi-hat roll patterns — the evolving density technique that defines modern trap.

Trap rolls are hi-hat patterns that start sparse and build density through triplet bursts, 32nd-note runs, and "skrrt" stutter patterns. The hats evolve within each bar — from steady 8ths to 16ths to triplet rolls — creating the cascading, restless energy of modern trap. Kicks syncopate underneath, snares/claps anchor on beat 3.

roll_type: "modern" — Modern trap: steady 16ths with triplet rolls on bar transitions. Hats evolve 8th→16th→triplet within each 2-bar phrase. Kick on 1, "and of 2", and 3.5. Snare on 3. Travis Scott "Sicko Mode", Drake "God's Plan". The default trap sound of 2018-2025. "migos" — Migos style: rapid triplet bursts on every "and" of beats 1-2, sparse on 3-4, then fill into next bar. Kick on 1 and 3. Snare on 2 and 4. Offset/Migos "Bad and Boujee" triplet flow. "bubble" — Atlantan "bubble" hats: continuous 16ths with periodic doubles (two 32nd hits) creating a bouncing feel. Kick on 1 and 3.5. Snare on 3. Young Thug / Future "Mask Off" style. "skrrt" — Skrrt pattern: stuttering hat bursts that mimic the sound of screeching tires. Short rapid groups (3-4 hits) with gaps. Kick on 1, 2.66, 3. Snare on 3. Playboi Carti / 21 Savage. "evolving" — Evolving density: starts with just 8th hats in bar 1, adds 16ths in bar 2, triplet rolls in bar 3, full 32nd cascade in bar 4. Builds tension across 4 bars. Metro Boomin production style.

bars: Pattern length (2-16, 2 = one phrase cycle, 4 recommended for evolving). kick_pitch: MIDI pitch for kick (36 = C1). snare_pitch: MIDI pitch for snare/clap (38 = D1). hat_pitch: MIDI pitch for hi-hats (42 = F#1). velocity: Base velocity 0-1. Hats -0.15, ghost hats -0.3.

Returns notes created, roll type, and stroke breakdown.

Example: create_trap_rolls(roll_type="modern", track_index=0) create_trap_rolls(roll_type="evolving", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
hat_pitchNo
roll_typeNomodern
kick_pitchNo
start_beatNo
unit_indexNo
snare_pitchNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that it creates MIDI notes for kick, snare, and hi-hat with specific patterns, and mentions return value. However, it does not disclose potential side effects like overwriting existing notes, error handling, or behavior with invalid track_index.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a clear introduction, detailed roll_type breakdown, and parameter list. It is somewhat verbose but informative. Minor redundancy could be trimmed, but overall it is structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no required) and lack of annotations, the description is fairly complete. It explains musical context, roll types, parameter defaults, and return values. It lacks coverage of a few parameters and edge cases, but is still substantial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It elaborates on roll_type with five subtypes and their musical contexts, and covers bars, kick_pitch, snare_pitch, hat_pitch, velocity with defaults. However, it does not explain start_beat, unit_index, or track_index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates trap hi-hat roll patterns, a specific resource, with a verb 'create'. It distinguishes from siblings by focusing on a genre-specific pattern, and includes detailed musical context and examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides extensive guidance on when to use each roll_type with musical examples and references. However, it does not explicitly state when not to use it or directly compare to alternatives like create_boom_bap, though the context is sufficient given sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_trillA

Create a trill — rapid alternation between two notes.

A fundamental ornament used across classical (baroque trills, mordents), jazz (shake), metal (tremolo picking), and electronic (LFO-like patterns). Two notes alternate at the specified rate for the given duration. Upper note can be accented (baroque style) or both equally loud.

lower_pitch: Lower MIDI note of the trill (default 60 = C4). upper_pitch: Upper MIDI note, typically 1-2 semitones above (default 62 = D4). rate: Trill speed — "32nd", "16th", "8th", "32t" (triplet 32nd), "16t" (triplet 16th). duration_beats: Total length of the trill in beats (0.5-32, default 4 = 1 bar at 4/4). accent_upper: If true, upper note is louder (baroque style). If false, equal velocity. start_with_upper: If true, trill starts on upper note (some baroque conventions). velocity: Base velocity 0-1 (default 0.85). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the trill begins.

Returns notes created, rate, note count.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateNo16th
velocityNo
start_beatNo
unit_indexNo
lower_pitchNo
track_indexNo
upper_pitchNo
accent_upperNo
duration_beatsNo
start_with_upperNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It describes note creation, alternation rate, accent options, and return value, but does not mention side effects (e.g., overwriting existing notes) or prerequisites (e.g., required track setup).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise with a front-loaded purpose, but the parameter list at the end duplicates schema info. Some sentences on genre context are helpful but could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, no annotations, no schema descriptions, and an output schema present, the description covers the concept and most parameter functions. However, it lacks detailed parameter semantics and behavioral transparency, leaving gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It lists parameters and defaults but adds little explanation beyond the schema. For example, 'rate' values are listed without explanation of triplet interpretations, and no examples or constraints are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a trill, defines it as rapid alternation between two notes, and provides genre-specific context (classical, jazz, metal, electronic). This distinguishes it from sibling ornament tools like create_mordent or create_turn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (for trills across multiple genres) but does not explicitly state when not to use it or compare with alternatives. The genre mentions help guide appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_tumbaoA

Create an Afro-Cuban tumbao (conga) pattern — the rhythmic foundation of salsa.

The tumbao is played on congas and interacts with the clave to create the Afro-Cuban groove. The pattern features open tones (resonant, sustained), closed tones (muffled, short), and slaps (sharp, percussive). The open tone on the "and of 4" is the signature — it anticipates the downbeat.

tumbao_type: "salsa" — Standard salsa tumbao. 2-bar pattern: Bar 1: tone on &2, open on &4 Bar 2: tone on &2, open on 4 (downbeat) "salsa_slap" — Salsa with slap on beat 2 of bar 2 "rumba" — Rumba tumbao (guaguancó). Simpler, more open tones. "bolero" — Bolero tumbao. Slower feel, fewer strokes.

bars: Pattern length (2 = one tumbao cycle, repeat for longer). low_pitch: MIDI pitch for closed tones (low conga). open_pitch: MIDI pitch for open tones (mid conga). slap_pitch: MIDI pitch for slaps (high conga). velocity: Base velocity 0-1. Open tones +0.1, slaps +0.15.

Returns notes created, tumbao type, and stroke breakdown.

Example: create_tumbao(tumbao_type="salsa", track_index=0) create_tumbao(tumbao_type="salsa_slap", track_index=1, bars=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
velocityNo
low_pitchNo
open_pitchNo
slap_pitchNo
start_beatNo
unit_indexNo
track_indexNo
tumbao_typeNosalsa

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description fully carries the burden. It discloses that the tool creates notes, uses MIDI pitches, and returns a breakdown of notes, type, and strokes. It explains the pattern's structure (open tones, slaps, etc.) and how parameters affect sound. However, it does not mention whether existing notes on the target track are cleared or if there are side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and includes structured parameter explanations and examples. It is somewhat verbose in explaining the musical pattern, but this adds contextual value. Overall, it is well-organized and each section earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no required params, no enums) and absence of annotations, the description provides substantial context about the tool's behavior and output. However, the missing parameter explanations for track_index and unit_index leave gaps. The output schema is mentioned but not detailed, though the description states return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It covers tumbao_type, bars, low_pitch, open_pitch, slap_pitch, and velocity with contextual meaning. However, it omits explanations for track_index, unit_index, and start_beat, which are critical for placement. This is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an Afro-Cuban tumbao (conga) pattern, a specific rhythmic foundation. It distinguishes from siblings by focusing on a particular conga pattern with subtypes like salsa, rumba, etc. The verb 'create' and resource 'tumbao' are precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tumbao types and their musical contexts (salsa, rumba, bolero) but does not explicitly state when to use this tool versus alternatives like create_clave or create_cascara. Usage is implied through musical terminology, but no direct comparison or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_tuplet_groupA

Create a tuplet group — irrational rhythm subdivision within a time span.

A tuplet divides a time span into N equal parts instead of the normal subdivision. Triplets (3 in 2), quintuplets (5 in 4), septuplets (7 in 4) create rhythmic tension by violating the expected duple meter.

Unlike polyrhythm (multiple voices with different periods) or additive rhythm (unequal groupings), tuplets subdivide a single time span into an irrational number of equal parts — creating a "squeezed" or "stretched" feel within one voice.

Common tuplets: 3 in 2 — triplet (most common, jazz swing, Irish jigs) 5 in 4 — quintuplet (Chopin, Ligeti, modern jazz) 7 in 4 — septuplet (Ferneyhough, new complexity) 11 in 4 — undecuplet (extreme irrational meter) 2 in 3 — duplet (2 notes in triplet space, compound meter)

Args: root: Root note name (C, C#, D, ...). scale: Scale name (major, minor, dorian, etc.). tuplet_number: Number of notes to fit in the span (2-16). 3=triplet, 5=quintuplet, 7=septuplet, etc. span_beats: Time span in beats that the tuplet occupies (0.25-8.0). 1.0 = quarter note span, 2.0 = half note span. base_division: The normal subdivision the tuplet replaces (1-8). 2 = duplet (normal), so triplet = 3 in 2. 4 = sixteenths, so quintuplet = 5 in 4. repeats: Number of times the tuplet repeats (1-16). octave: Starting MIDI octave (1-6). pitch_mode: Pitch assignment mode (scale_asc, scale_desc, chord, repeated, alternating). rest_positions: Comma-separated tuplet positions that are rests (0-indexed). E.g., "2,4" = positions 2 and 4 are rests. velocity: Base velocity 0-1. accent_first: If True, first note of each tuplet gets accent. unit_index: AU index. track_index: Note track index. start_beat: Starting beat position.

Returns notes created, tuplet ratio, and timing info.

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
octaveNo
repeatsNo
velocityNo
pitch_modeNoscale_asc
span_beatsNo
start_beatNo
unit_indexNo
track_indexNo
accent_firstNo
base_divisionNo
tuplet_numberNo
rest_positionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description explains the concept and parameters, and mentions return values (notes, ratio, timing). However, it does not explicitly state that the tool adds notes to a track or disclose side effects, permissions, or constraints, which would be needed for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and concept, followed by a structured Args list. It is slightly verbose but each sentence serves a purpose. Could be trimmed slightly but well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the concept, parameter details, common tuplets, and return value. It is complete enough for a creation tool with an output schema. Minor gaps include error conditions and explicit mention of additive behavior to existing tracks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides detailed explanations for key parameters (tuplet_number, span_beats, base_division, rest_positions, etc.) with examples and ranges. Some generic parameters like root, scale, and velocity are not elaborated, but overall adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a tuplet group — irrational rhythm subdivision within a time span.' It uses a specific verb and resource, and contrasts with polyrhythm and additive rhythm, distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts tuplets with polyrhythm and additive rhythm, and lists common tuplets with usage contexts (jazz swing, Chopin, etc.). It provides clear context but lacks explicit when-not-to-use or alternatives beyond the contrasts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_turnA

Create a turn — circular ornament: main → neighbor → main → other neighbor → main.

The turn (gruppetto) is one of the four essential baroque ornaments (trill, mordent, turn, appoggiatura). It circles around the main note in a four-note flourish. An upper turn goes up first (main → upper → main → lower → main), a lower turn goes down first (main → lower → main → upper → main).

Think Mozart piano concertos, Beethoven sonatas, Bach partitas. The turn adds elegance and circular motion to a sustained note.

main_pitch: The primary MIDI note (default 60 = C4). direction: "upper" (main→up→main→down→main) or "lower" (main→down→main→up→main). interval: Semitones to neighbors (default 2 = whole step). 1 = half step (diatonic). duration_beats: Total length in beats (0.5-4, default 1.0 = quarter note). velocity: Base velocity 0-1 (default 0.85). unit_index: AU index with note track (-1 = find first AU with note tracks). track_index: Note track index within the AU. start_beat: Position in beats where the turn begins.

Returns notes created, pitches used.

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNo
velocityNo
directionNoupper
main_pitchNo
start_beatNo
unit_indexNo
track_indexNo
duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. However, it only describes the musical concept and parameter effects, omitting behavioral traits such as whether it overwrites existing notes, requires any specific state, or has side effects. The return is mentioned but not detailed. This is insufficient for an agent to understand the tool's operational impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with an introductory definition, musical examples, and a clear parameter list. Each sentence adds value, though the musical examples ('Think Mozart piano concertos...') are slightly verbose. Overall, it is front-loaded with the core concept and well-structured, but could be trimmed without losing essence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that schema descriptions are 0% and an output schema exists (so return details are covered), the description adequately explains the turn ornament and all parameters. However, it does not address error conditions or invalid inputs (e.g., invalid unit_index) which limits completeness for an agent making robust calls. Still, it covers the core creation context well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, yet the description explains every parameter in detail: main_pitch (default 60=C4), direction (upper/lower), interval (semitones, default 2), duration_beats (range and default), velocity (0-1 default), unit_index, track_index, start_beat. This adds significant meaning beyond the plain schema properties, fully compensating for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines 'turn' as a musical ornament with a specific pattern (main→neighbor→main→other neighbor→main) and distinguishes between upper and lower turns. It uses specific verbs ('create a turn') and explicitly names the resource (turn). Even without explicit sibling differentiation, the detailed explanation makes the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives like create_mordent or create_trill. It explains what a turn is but offers no exclusions or criteria for selection. This lack of usage context makes it harder for an agent to decide between similar ornament tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_two_hand_pianoA

Create a two-hand piano arrangement — left hand accompaniment + right hand melody.

The fundamental piano pattern: left hand plays accompaniment (Alberti bass, arpeggios, block chords, or bass+chord), right hand plays melody or chord tones. Unlike create_chord_progression (block chords only) or create_melody (single line), this combines both hands into one coherent arrangement.

chords: JSON array of chord specs, same format as create_chord_progression. Example: '[["C","maj7"],["A","min7"],["D","min7"],["G","dom7"]]' left_hand: Accompaniment pattern for left hand: "block" — full chord sustained for chord_duration "arpeggio_up" — ascending arpeggio (root-third-fifth-octave) "arpeggio_down" — descending arpeggio "arpeggio_updown" — ascending then descending "alberti" — classic Alberti bass (root-third-fifth-third) "bass_chord" — bass note on beat 1, chord for remaining beats right_hand: Right hand pattern: "chord_tones" — top note of each chord as sustained melody "arpeggio" — arpeggiated chord in right hand (higher octave) "melody" — custom melody from melody_pitches parameter melody_pitches: Comma-separated MIDI pitches for right hand melody (only used when right_hand="melody"). Spans entire progression evenly. bass_octave: MIDI octave for bass notes (2 = C2=36). chord_octave: MIDI octave for left hand chords (3 = C3=48). melody_octave: MIDI octave for right hand (5 = C5=72). chord_duration: Length of each chord in beats (4 = one bar at 4/4). arpeggio_rate: Duration of each arpeggio note in beats (0.5 = eighth notes). unit_index: AU index with a note track. track_index: Note track index within the AU. start_beat: Where the arrangement starts (0 = bar 1). velocity: Base velocity 0-1 (left hand slightly quieter).

Returns notes created, left/right hand voicings, and chord count.

ParametersJSON Schema
NameRequiredDescriptionDefault
chordsYes
velocityNo
left_handNoarpeggio_up
right_handNochord_tones
start_beatNo
unit_indexNo
bass_octaveNo
track_indexNo
chord_octaveNo
arpeggio_rateNo
melody_octaveNo
chord_durationNo
melody_pitchesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It details left/right hand patterns, octave settings, velocity base (left hand slightly quieter), and return values (notes, voicings, chord count). It doesn't mention side effects like prerequisite track existence, but covers most behavioral traits for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: summary, sibling differentiation, then parameter details. It is lengthy but every sentence adds value. Some parameter groupings could be tighter, but overall it's effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (13 parameters, no annotations, output schema exists), the description covers purpose, parameter details, and return values. It is complete enough for an agent to invoke correctly, explaining how each parameter affects the arrangement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides thorough explanations for all 13 parameters, including examples (e.g., chords format, left_hand patterns, arpeggio types) and default values. This exceeds what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a two-hand piano arrangement — left hand accompaniment + right hand melody.' It distinguishes itself from siblings like create_chord_progression and create_melody by explicitly noting that this tool combines both hands into one coherent arrangement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool versus alternatives by contrasting with create_chord_progression (block chords only) and create_melody (single line). It does not explicitly state when not to use it, but the differentiation is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_value_clipA

Create a value clip (automation clip) on an automation track in session view.

Uses ProjectApi.createValueClip — creates a ValueClipBox with an empty ValueEventCollectionBox on the specified automation (Value-type) track.

unit_index: Audio unit index. track_index: Automation track index (-1 = first automation track on the unit). name: Clip label. clip_index: Clip slot index (0-based).

Returns clip creation details.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a ValueClipBox with an empty ValueEventCollectionBox and references ProjectApi.createValueClip, which gives some insight into the internal operation. However, it does not disclose side effects, state changes, or whether the operation is reversible. The description is moderately transparent but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear purpose statement, followed by a brief note on the underlying API and a parameter list. Every sentence adds value; there is no extraneous information. It is moderately sized and well-structured for an AI agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (though not shown), the description does not need to detail return values beyond 'Returns clip creation details.' It covers the essential scope (creation on automation track) and parameter roles. However, it lacks information on prerequisites (e.g., track must exist) and potential errors (e.g., invalid clip_index). The context is adequate but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains each parameter beyond the input schema: unit_index as 'Audio unit index', track_index as 'Automation track index (-1 = first automation track on the unit)', name as 'Clip label', and clip_index as 'Clip slot index (0-based)'. Since the schema has 0% coverage (no descriptions), the description effectively compensates and provides meaningful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a value clip (automation clip) on an automation track in session view.' It specifies the action (create), resource (value clip on automation track), and context (session view). Among many 'create_*' siblings, this tool is distinctly targeted at automation tracks, leaving no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like mcp_opendaw_create_automation_event or mcp_opendaw_add_automation. It does not specify prerequisites or contraindications, leaving the agent to infer usage context from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_variationsA

Create thematic variations from an existing note region.

Reads notes from a source region and generates N variations, each written to a new region on the target track. Each variation applies a transformation: transpose, invert, reverse, augment, diminish, fragment, or octave_shift. This is the fundamental compositional technique of theme-and-variations (Bach Goldberg, Beethoven Diabelli, Brahms, jazz reharmonization).

source_unit: AU index of the source notes. source_track: Note track index within the source AU. source_region: Region index to read from (0 = first region). variations: Comma-separated variation specs. Each spec is: "transpose:N" — transpose by N semitones (e.g. transpose:5, transpose:-7) "invert" — invert around middle C (axis=60) "invert:N" — invert around pitch N "reverse" — reverse note order (keep positions relative) "augment:N" — multiply durations by N (e.g. augment:2 = double) "diminish:N" — divide durations by N (e.g. diminish:2 = halve) "fragment" — keep only notes on beats (quantize to beat boundaries) "octave_up" — shift up one octave (+12) "octave_down" — shift down one octave (-12) Example: "transpose:5,invert,reverse,augment:2,octave_down" target_unit: AU index for variations (-1 = same as source). target_track: Track index for variations (-1 = same as source). start_beat: Starting beat for first variation. spacing_beats: Gap between variations in beats (0 = each starts after previous ends).

Returns notes per variation, total notes, variation count.

ParametersJSON Schema
NameRequiredDescriptionDefault
start_beatNo
variationsNotranspose:5,transpose:-3,invert,reverse,augment:2
source_unitYes
target_unitNo
source_trackYes
target_trackNo
source_regionNo
spacing_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description clearly states the behavior: reads source region, generates N variations, writes new regions to target track. It explains transformation formats and defaults. With no annotations, it carries the transparency burden well but omits error handling and prerequisites (e.g., source region existence).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line summary, process overview, parameter list with examples, and output note. It uses clear line breaks and bullet points. Length is justified by complexity; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, multiple transformations) and presence of output schema, the description covers core usage, parameters, and return values. It lacks explicit error handling or prerequisite checks but is sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description is the sole source for parameter semantics. It thoroughly explains all 8 parameters: source_unit, source_track, source_region, variations (with format and examples), target_unit, target_track, start_beat, spacing_beats. Defaults and examples are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb+resource: 'Create thematic variations from an existing note region.' It details the process and lists specific transformations (transpose, invert, reverse, etc.), distinguishing it from siblings like create_motif_variations and create_arrangement_variation by focusing on note-level theme-and-variations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating thematic variations from a note region with classical compositional context. It provides examples and parameter details. However, it lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools, such as create_motif_variations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_voice_exchangeA

Create a voice exchange — imitative counterpoint where motifs pass between voices.

A voice exchange is a contrapuntal technique where melodic material is passed between two or more voices. Voice A states a motif, Voice B responds with the same motif (transposed, inverted, or retrograded), creating a dialogic texture. This is the foundation of fugue, canon, and Renaissance polyphony.

Unlike clone_track (exact copy) or copy_notes_to_track (direct clone), voice exchange transforms the material as it passes between voices:

  • Imitation: same motif at a different pitch level

  • Inversion: motif inverted (intervals flipped)

  • Retrograde: motif reversed in time

  • Retrograde-inversion: both reversed and inverted

  • Augmentation: motif stretched in time

  • Diminution: motif compressed in time

With swap=True, the source notes are also moved to the target register, creating a true voice exchange where the voices cross.

Args: unit_index: AU index. source_track: Source note track index (contains the original motif). source_region: Source region index (0 = first region). target_track: Target note track index (where the response goes). target_region: Target region index (0 = first region). exchange_mode: Transformation mode (imitation, inversion, retrograde, retrograde_inversion, augmentation, diminution). interval: Pitch interval for imitation (semitones). Default 7 = perfect fifth. transpose: Additional semitone transpose on top of interval. time_offset: Time offset in beats before the response starts. Default 2.0 = response begins 2 beats after source starts. duration_factor: Duration multiplier (1.0 = same, 2.0 = augmentation, 0.5 = diminution). Overrides augmentation/diminution modes. velocity_factor: Velocity multiplier for the response voice. swap: If True, also swap source notes to target register (true exchange).

Returns notes created, transformation mode, and exchange statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault
swapNo
intervalNo
transposeNo
unit_indexYes
time_offsetNo
source_trackNo
target_trackNo
exchange_modeNoimitation
source_regionNo
target_regionNo
duration_factorNo
velocity_factorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It details that the tool transforms motifs via imitation, inversion, retrograde, etc., and explains the swap parameter's effect. It also mentions the return value (notes created, mode, statistics). Minor missing detail on potential side effects, but overall transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with purpose, but slightly lengthy due to the enumeration of transformation modes and parameter list. While every sentence adds value, minor redundancy exists (e.g., repeating 'motif passes between voices'). Still above average.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all aspects needed: it explains the technique, lists transformation modes, details all parameters, and mentions return values. With an output schema existing, the return description is sufficient. The tool is complex but the description is thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully, which it does. It explains all 12 parameters with clear semantics, default values, and even interaction notes (e.g., duration_factor overrides modes). This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a voice exchange, a specific contrapuntal technique. It uses precise verb and resource ('Create a voice exchange') and explicitly distinguishes from sibling tools like clone_track and copy_notes_to_track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with clone_track and copy_notes_to_track, stating that this tool transforms material rather than copying exactly. It provides clear context for when to use (imitative counterpoint) and when not to use (exact copies), and outlines the transformation modes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_voice_led_progressionA

Create chord pads with smooth voice leading — minimal movement between chords.

Unlike create_chord_pads (which voices every chord in root position causing large jumps), this tool re-voices each chord so individual voices move as little as possible. Common tones stay stationary, other voices resolve by nearest semitone step. The result: strings/pads that glide instead of jump.

progression: Hyphen-separated chords (same format as create_chord_pads). "Am-F-C-G" = i-VI-III-VII in A minor. "C-Am-F-G" = I-vi-IV-V in C major. "Dm7-G7-Cmaj7-Am7" = ii-V-I-vi in C (jazz).

bars_per_chord: Bars per chord (default 4). octave: Center octave for voicing range (3 = C3-C4 register, typical pads). velocity: Note velocity (0-1, default 0.65). unit_index: AU index with note tracks. track_index: Track for chord pads (typically 2 = harmony). start_beat: Where the progression starts. note_duration: Sustain length in beats (default 3.8 = near-full bar). voice_range: Max semitone span from center pitch for each voice (default 12 = one octave either side of center). Prevents voices from drifting too high or low. 7 = tighter, 18 = wider range.

Returns chord voicings, voice movements, and total notes.

Voice leading algorithm:

  1. First chord: root-position voicing centered on octave.

  2. For each subsequent chord: a. Find all pitch-class rotations/inversions of the chord. b. For each candidate voicing, compute total voice movement (sum of semitone distances from previous voicing, by voice index). c. Pick the voicing with minimal total movement. d. Constraint: each voice stays within ±voice_range of center.

  3. Common tones naturally stay (distance 0 = optimal).

ParametersJSON Schema
NameRequiredDescriptionDefault
octaveNo
velocityNo
start_beatNo
unit_indexNo
progressionNoAm-F-C-G
track_indexNo
voice_rangeNo
note_durationNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral transparency. It details the voice-leading algorithm step-by-step, explains constraints like voice_range, and describes the return value (chord voicings, voice movements, total notes). However, it does not explicitly mention side effects (e.g., overwriting existing notes) or any prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, comparison, parameter list, and algorithm explanation. It is somewhat verbose, but every section adds value, especially the algorithm details. Almost no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's behavior thoroughly, including the algorithm and parameter explanations. With 9 parameters and no required ones, it provides sufficient context. It does not discuss error handling or edge cases, and the output schema is present (so return format not needed). Slightly incomplete but good overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must explain parameters. It does so for all major parameters: progression (with examples), bars_per_chord, octave, velocity, note_duration, voice_range. Unit_index and track_index are mentioned but not deeply explained (though they are common). Overall, the description adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: creating chord pads with smooth voice leading. It uses the specific verb 'create' and resource 'chord pads with smooth voice leading'. It distinguishes itself from the sibling tool 'create_chord_pads' by explicitly contrasting its behavior (minimal movement) with root-position voicing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly compares to 'create_chord_pads', stating when to use this tool (when smooth voice leading is desired) and when to use the alternative (root-position chords). It does not provide explicit 'when not to use' guidance, but the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_volume_fadeA

Create a volume fade automation on an audio unit — fade in or fade out.

The most common mix technique for intros, outros, breakdowns, and section transitions. Creates volume automation events on the AU's volume parameter, ramping from one dB level to another. Uses exponential curve by default (natural for amplitude perception).

unit_index: AU index. direction: "out" (fade out, volume decreases) or "in" (fade in, volume increases). start_beat: Start position in beats. duration_beats: Fade length in beats (default 4 = 1 bar). start_volume_db: Starting volume in dB (default: 0 for out, -60 for in). end_volume_db: Ending volume in dB (default: -60 for out, 0 for in). curve: "exp" (exponential, default — natural for amplitude), "linear", "log". steps: Number of automation points (default 24 = smooth).

Returns events created, fade config, and dB range.

Examples: create_volume_fade(unit_index=0, direction="out", duration_beats=8) → 8-beat fade out from 0 dB to -60 dB, exp curve create_volume_fade(unit_index=2, direction="in", duration_beats=4, end_volume_db=-3) → 4-beat fade in from -60 dB to -3 dB

ParametersJSON Schema
NameRequiredDescriptionDefault
curveNoexp
stepsNo
directionNoout
start_beatNo
unit_indexYes
end_volume_dbNo
duration_beatsNo
start_volume_dbNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool creates automation events on the AU volume parameter, ramps between dB levels, uses an exponential curve by default, and returns events created, fade config, and dB range. It does not mention side effects like overwriting existing automation, but the core behavioral traits are well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear opening sentence, a brief usage context, a parameter list with defaults, a note on return value, and two concrete examples. Every sentence adds value, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, no annotations, and the presence of an output schema (indicated but not shown), the description is remarkably complete. It explains the tool's purpose, all parameters with defaults, the curve types, the return structure, and provides examples. No obvious gaps for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully by listing all 8 parameters with explanations, defaults, and examples (e.g., unit_index, direction, start_beat, duration_beats, start_volume_db, end_volume_db, curve, steps). This provides complete semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a volume fade automation on an audio unit — fade in or fade out.' It uses a specific verb ('create') and resource ('volume fade automation'), and the context ('common mix technique') helps distinguish it from other automation tools. The tool name itself is also specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes usage context: 'The most common mix technique for intros, outros, breakdowns, and section transitions.' This guides when to use it, but it does not explicitly state when not to use it or compare it with alternatives like add_automation or create_automation_event. Given the clear context, it is still helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_walking_bassA

Create a walking bass line over a chord progression.

A walking bass plays four quarter notes per bar, connecting chords through chord tones, passing tones, and approach notes. The bass 'walks' from one chord to the next using scale-wise motion and arpeggios. Essential for jazz, blues, and swing.

chords: JSON array of [root, chord_type] pairs. Example: [["C","maj7"],["A","min7"],["D","min7"],["G","dom7"]] unit_index: AU index. track_index: Note track index. start_beat: Starting beat position. octave: Bass octave (1-3, default 2 = C2=36). velocity: Note velocity 0-1. bars_per_chord: Bars to spend on each chord (1-4). 1 = 4 notes per chord, 2 = 8 notes.

Returns total notes created and bass walk summary.

The walking bass algorithm: Beat 1: chord root (strong) Beat 2: chord tone (3rd, 5th, or 7th) Beat 3: passing tone (scale step between current and next chord) Beat 4: approach note (half-step or scale-step into next chord root)

Example: create_walking_bass(chords='[["C","maj7"],["A","min7"],["D","min7"],["G","dom7"]]', octave=2)

ParametersJSON Schema
NameRequiredDescriptionDefault
chordsYes
octaveNo
velocityNo
start_beatNo
unit_indexNo
track_indexNo
bars_per_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully explains the walking bass algorithm (beat roles: root, chord tone, passing tone, approach note) and what the tool returns (notes created, summary). It does not mention side effects or auth requirements, but the algorithm and output are well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear action, musical context, parameter list, algorithm explanation, and example. It is slightly long but each section adds value. Could be tightened by removing redundancy in the parameter descriptions already in schema titles.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of walking bass generation and the presence of an output schema (inferred), the description covers input, algorithm, and output. It does not address edge cases (e.g., empty chords) but is otherwise sufficient for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description compensates by explaining most parameters: chords format, octave range, velocity range, bars_per_chord meaning, and mentions unit_index and track_index. However, unit_index and track_index are not fully explained beyond 'AU index' and 'Note track index', which is somewhat clear but could be more explicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a walking bass line over a chord progression, specifying the resource (bass line) and action (create). It distinguishes from siblings like create_bassline and create_electronic_bass by the specific walking bass style and algorithm, and ties it to jazz, blues, and swing contexts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for jazz/blues/swing and walking bass patterns, but does not explicitly state when to use this tool versus alternatives like create_bassline or create_bass_from_progression. No when-not or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_create_warp_markerA

Add a warp marker to a time-stretched or pitch-stretched audio region.

Warp markers define the mapping between musical position (ppqn) and audio time (seconds). The first and last markers are anchors — they pin the start and end of the audio.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. position_beats: Musical position in beats (e.g. 0.0 = start of region). seconds: Audio time in seconds at this position.

Returns the new marker count and the added marker's position/seconds.

ParametersJSON Schema
NameRequiredDescriptionDefault
secondsYes
unit_indexYes
track_indexYes
region_indexYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the tool modifies audio regions by adding markers, mentions anchors, and states the return value. It could add more about reversibility or permissions, but the core behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main purpose, and uses bullet points for parameter explanations. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (mentioned in context signals), the description adequately explains the concept of warp markers and the tool's behavior. It covers the purpose, parameters, and return value, making it complete for a create tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 5 required parameters with no descriptions. The description lists each parameter with a brief explanation (e.g., 'unit_index: AU index.'), providing meaning beyond the schema titles and adding value for all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a warp marker to a time-stretched or pitch-stretched audio region' and explains the concept of warp markers and anchors, distinguishing it from sibling tools like delete, update, and list warp markers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (for time-stretched or pitch-stretched regions) and explains the role of warp markers, but does not explicitly state when not to use it or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_audio_regionB
Destructive

Delete an audio region from the timeline.

unit_index: Audio unit index. track_index: Audio track index within the AU (type=2). region_index: Region index to delete (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation already marks destructiveHint=true. The description adds no behavioral context beyond parameter identification (e.g., side effects, reversibility, or whether the deletion is permanent).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and to the point, with the main action stated first and parameters listed after. It is efficient but could be formatted as a structured list for better readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core purpose and parameter meanings. However, it lacks information about return values (output schema is present but not described) and assumes familiarity with the DAW's indexing system.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the parameter explanations are the sole source. They provide basic meaning (e.g., 'unit_index: Audio unit index') but assume system knowledge and do not link to other tools (e.g., list_audio_regions for indices).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete an audio region from the timeline' with a specific verb and resource, distinguishing it from sibling tools like delete_region (which may affect non-audio regions) and delete_note_region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., delete_region or delete_clip). The description assumes the user knows to choose based on resource type, but does not explicitly state conditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_audio_unitA
Destructive

Delete an entire audio unit with all its tracks, effects, and sends.

Uses ProjectApi.deleteAudioUnit() — proper cleanup of all connected boxes. The primary output AU (index 0) cannot be deleted.

unit_index: Audio unit to delete (must be >= 1, as index 0 is the master output).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation already indicates destructiveHint: true, so the description does not need to reiterate destructiveness. It adds valuable context: proper cleanup of all connected boxes and the constraint that index 0 cannot be deleted. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a parameter note. It is front-loaded with the action and key constraints, with zero wasted words. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter destructive tool, the description covers the function, safety constraint, and cleanup behavior. An output schema exists, so not describing the return value is acceptable. Minor gap: could mention that all child elements are recursively deleted, but the phrase 'all its tracks, effects, and sends' addresses this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only specifies unit_index as an integer with no description. The description adds critical meaning: the unit index must be >= 1 because index 0 is the master and cannot be deleted. This fully compensates for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes an entire audio unit with all its tracks, effects, and sends. It also specifies that the primary output AU (index 0) cannot be deleted, which distinguishes it from other delete tools like delete_track that operate on individual tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions using ProjectApi.deleteAudioUnit() for proper cleanup and notes that index 0 is forbidden. However, it does not explicitly compare this tool to alternatives like delete_track or remove_effect, leaving the agent to infer when to use this versus other deletion tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_automation_eventA
Destructive

Delete a single automation event (ValueEventBox) from an automation track.

unit_index: Audio unit index. track_index: Track index within the unit (automation track). event_index: Event index within the track's value region.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
event_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true. The description confirms destructive behavior ('delete') and adds context about the value region and indices. However, it does not disclose side effects, prerequisites, or undo support, so it adds moderate value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: four sentences total, with the purpose front-loaded and parameter explanations following. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the action, parameters, and return type (success or error). It does not discuss prerequisites, error conditions, or behavior with invalid indices, but given the output schema exists and the tool is part of a larger set, it is reasonably complete for a delete operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters (unit_index, track_index, event_index), describing their roles and context (e.g., 'Track index within the unit (automation track)'). This adds value beyond the schema property titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes a single automation event (ValueEventBox). It specifies the exact resource type and action, and the sibling tools include create, update, duplicate, list, and move automation events, so the purpose is well-distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives like delete_audio_region or delete_note. Usage is implied by the tool name and context (automation events), but no when-not or comparative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_clipA
Destructive

Delete a clip from a track (session view).

unit_index: Audio unit index. track_index: Track index. clip_index: Clip index to delete (0-based).

Returns remaining clip count.

ParametersJSON Schema
NameRequiredDescriptionDefault
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate destructiveHint: true, so the description's mention of 'Delete' is consistent. The description adds value by stating it 'Returns remaining clip count', which is behavioral info not present in annotations. However, it does not disclose other behaviors like whether deletion affects automation, undo stack, or if it shifts remaining clip indices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise: two short sentences. The first sentence states the purpose, and the second lists the parameters with their meanings. Every word contributes to understanding, with no fluff or redundancy. It is optimally sized for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (delete operation, 3 parameters), the description covers the essential aspects: purpose, parameter meanings, and return value. It notes that clip indices are 0-based, which is important. However, it could be more complete by explaining that deleting a clip may shift subsequent clip indices or that the tool operates within the context of a unit and track. An output schema is not provided, but the description compensates by stating the return type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description carries the full burden. It provides clear explanations for all three parameters: 'Audio unit index', 'Track index', and 'Clip index to delete (0-based)'. This adds meaningful context beyond the schema titles. A higher score would require additional details like valid ranges or relationships between indices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a clip from a track (session view)', providing a specific verb ('Delete'), a distinct resource ('clip'), and context ('session view'). This distinguishes it from sibling delete tools like delete_note, delete_region, and delete_audio_unit, which target different resources. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that the clip must exist), when it is appropriate to delete a clip, or what to do before calling this tool (e.g., listing clips to obtain indices). There is no 'when not to use' or comparison with other deletion tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_markerA
Destructive

Delete a timeline marker by index.

marker_index: Index from list_markers (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
marker_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already provide destructiveHint=true, signaling destructive action. The description adds the method of deletion (by index) but does not elaborate on consequences (e.g., irreversibility, effect on project state). It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each essential. Front-loaded with the core purpose. No redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, straightforward purpose) and the presence of an output schema, the description is nearly complete. It could mention that the deletion is irreversible or what happens if the index is invalid, but these are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the single parameter 'marker_index' as 'Index from list_markers (0-based)', which adds critical meaning beyond the schema (only type and title). With 0% schema description coverage, this fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a timeline marker by index' with a specific verb (delete) and resource (timeline marker). It distinguishes from sibling tools like add_marker, set_marker_label, and delete_warp_marker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises to get the index from list_markers, which is a helpful prerequisite. However, it does not explicitly state when to use this tool versus alternatives (e.g., set_marker_label to modify, or other delete tools). Context is implied but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_noteA
Destructive

Delete a single note from a region.

note_index: Index of the note to delete (0-based, as returned by list_notes). unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region containing the note (0-based).

Returns remaining note count.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_indexYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation 'destructiveHint: true' already indicates mutation. The description adds that it deletes a single note and returns the remaining note count. It does not elaborate on side effects (e.g., note removed from region, impact on region structure) or error conditions. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for purpose followed by a bullet-like list of parameter explanations. It is front-loaded with the action and resource. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, destructive action) and the presence of an output schema, the description covers the purpose, parameter meanings, and return value (remaining note count). It lacks error handling details or behavioral edge cases, but overall is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are absent (0% coverage), but the tool description provides clear explanations for all four parameters: note_index (0-based, from list_notes), unit_index (-1 for all AUs), track_index (within AU), and region_index (0-based). This adds significant meaning beyond the bare schema types and titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a single note from a region,' using a specific verb and resource. It distinguishes from sibling tools like 'delete_note_region' (which deletes an entire note region) by specifying it operates on a single note. However, it doesn't explicitly differentiate from all other delete tools, so it's not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'delete_note_region' or other delete tools. There is no mention of prerequisites, fallback tools, or context for usage. The description only explains parameters, not usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_note_regionA
Destructive

Delete a note region from the timeline.

unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region index to delete (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation destructiveHint=true already indicates destructive behavior. The description adds no further behavioral context (e.g., permanence, undo capability, side effects) beyond stating the deletion action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one line for the action and one line per parameter. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation, the description covers the core functionality and parameter semantics. However, it omits any mention of return value or error handling, though an output schema exists (not shown).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides critical parameter details missing from the schema: unit_index can be -1 to search all AUs, track_index is within the AU, region_index is 0-based. Since schema description coverage is 0%, this adds essential meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a note region from the timeline', specifying the exact resource and action. It distinguishes from sibling tools like delete_audio_region and delete_note by using 'note region', but does not elaborate on what constitutes a note region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as delete_region, delete_note, or delete_audio_region. The agent must infer usage from the tool name alone, which is insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_regionA
Destructive

Delete a region from a track.

Removes the region and all its contents (notes for note regions, audio reference for audio regions, automation events for value regions).

track_index: Track index within the AU. region_index: Region to delete (0-based). unit_index: Audio unit index (-1 = search all AUs). region_type: 'note', 'audio', or 'value' (for filtering).

Returns remaining region count on the track.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
region_typeYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already set destructiveHint=true, so the description adds context about what is removed (notes, audio, automation). It also mentions the return value (remaining region count). Does not fully detail side effects like fades or crossfades.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise and well-structured: first sentence states purpose, then bullet-style parameter explanations. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters and a simple return value, the description covers most aspects. Explains what gets deleted and what parameters do. Could mention potential errors or prerequisites (e.g., region must exist).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains each parameter meaning: track_index, region_index, unit_index (with default -1), region_type (with allowed values 'note', 'audio', 'value'). This adds significant value beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes a region from a track and explains what gets removed depending on region type (notes, audio, automation). It distinguishes from siblings like 'delete_note_region' or 'delete_audio_region' by specifying a broader scope with region_type parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus other delete tools (e.g., delete_note_region, delete_audio_region). No explicit when/when-not or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_sectionA
Destructive

Delete all regions within a beat range across all tracks.

Scans all tracks across all specified audio units, finds every region that overlaps the [from_beat, to_beat) range, and deletes each one. This is the arrangement cleanup tool: "clear bars 9-12 so I can put something else there" or "remove the intro (bars 1-4) from all tracks".

Completes the section CRUD trilogy: duplicate (copy), move (cut-paste), delete (remove). One call replaces N delete_region calls.

from_beat: Start of the section to delete (beats). to_beat: End of the section to delete (beats, exclusive). unit_indices: Comma-separated AU indices to scan (default: all AUs).

Returns number of regions deleted, per-track details, and remaining counts.

Examples: delete_section(from_beat=0, to_beat=16) -> Remove first 4 bars from ALL tracks across ALL audio units delete_section(from_beat=32, to_beat=48, unit_indices="0,1") -> Remove bars 9-12 from AUs 0 and 1 only

ParametersJSON Schema
NameRequiredDescriptionDefault
to_beatYes
from_beatYes
unit_indicesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true. The description adds that the tool scans all tracks and audio units, deletes overlapping regions, and returns per-track details. This provides useful context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with summary, explanation, parameter list, and examples. Slight redundancy (e.g., 'across all tracks' repeated) but not excessive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of deleting across tracks, the description covers the operation, parameters, return values (number deleted, per-track details, remaining counts), and provides examples. No output schema exists, so description compensates effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains each parameter in plain language: from_beat (start), to_beat (exclusive end), unit_indices (comma-separated, default all). Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: delete all regions overlapping a beat range across all tracks. It clearly distinguishes itself from the sibling tool 'delete_region' by emphasizing batch deletion across tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios ('clear bars 9-12', 'remove the intro') and notes it replaces multiple delete_region calls. It does not explicitly state when not to use, but the guidance is clear and helpful.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_signature_changeA
Destructive

Delete a time signature change from the timeline.

Delete by position (closest match) or by index (0-based in sorted order). Pass index=-1 and position_beats=-1 to delete the last event.

position_beats: Position to match (closest event will be deleted). index: 0-based index in sorted order (-1 = use position match).

Returns updated signature event list.

ParametersJSON Schema
NameRequiredDescriptionDefault
indexYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description provides details beyond the destructiveHint annotation: it clarifies that deletion uses closest match by position and explains the -1 special values for index and position_beats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise but contains some redundancy (e.g., the initial line and then parameter explanations). Could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the two parameter usage, mentions the return value (updated signature event list), and handles the edge case of deleting the last event. Missing error cases, but sufficiently complete for a simple delete tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the input schema has no parameter descriptions, the tool description adds crucial semantics: it defines position_beats as the position to match and index as 0-based index, including the special -1 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a time signature change from the timeline' with a specific verb and resource, and it distinctively separates from siblings like add_signature_change or move_signature_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains two deletion modes (by position or by index) and notes the special case for deleting the last event, but lacks explicit guidance on when to choose one mode over the other or comparison with alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_trackB
Destructive

Delete a track from an audio unit. Removes all regions, clips, and notes on that track.

unit_index: Audio unit index. track_index: Track index within the unit.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint: true. The description adds that it removes all content on the track (regions, clips, notes), which is helpful but does not mention reversibility, permissions, or other consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for purpose, two lines for parameters, one line for return. Front-loaded with the core action. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (two integer params, destructive), the description covers the primary effect and parameter meanings. It omits discussion of error handling or undo capabilities, but an output schema exists for the return. Overall adequate for a straightforward deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides one-line explanations for each parameter ('Audio unit index', 'Track index within the unit'), adding basic meaning beyond schema titles. However, it lacks details on how to obtain these indices or valid ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a track from an audio unit' and lists the side effects (removing regions, clips, notes). It distinguishes from siblings like delete_region and delete_audio_unit, but does not explicitly compare, so it's clear but not perfectly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs other deletion tools (e.g., delete_audio_unit, delete_region). No prerequisites or context for usage provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_delete_warp_markerA
Destructive

Delete a warp marker from a time-stretched or pitch-stretched audio region.

Cannot delete anchor markers (first and last) — they pin the audio mapping.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. marker_index: Warp marker index (0-based, from list_warp_markers).

Returns remaining marker count.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
marker_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true, and the description correctly states deletion. It adds value by explaining the restriction on anchor markers and their role in pinning audio mapping, as well as the return value (remaining marker count). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact (7 lines) yet complete: a clear action statement, a restriction note, parameter definitions in a list format, and the return value. No redundant information; each sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 4 required parameters, destructive annotation, and lack of output schema, the description covers all necessary aspects: purpose, constraints, parameter meanings, and return value. It even references the sibling tool list_warp_markers for obtaining the marker index, ensuring the agent has sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by providing concise explanations for all 4 parameters: unit_index (AU index), track_index (within AU), region_index, and marker_index (0-based, from list_warp_markers). This adds essential context beyond the schema's bare types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a warp marker' from a time-stretched or pitch-stretched audio region, distinguishing it from sibling delete tools (e.g., delete_audio_region, delete_marker) and related warp marker tools (create, list, update).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that anchor markers (first and last) cannot be deleted, providing a clear when-not-to-use condition. However, no alternatives are mentioned, missing a chance to guide users to other tools for those cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_detect_bpmA
Read-only

Detect BPM (tempo) of an exported WAV file using onset detection + autocorrelation.

Pure Python implementation (no external dependencies):

  1. Parse WAV → mono mixdown

  2. Energy envelope (1024-sample windows)

  3. Onset detection (energy spikes above local average)

  4. Autocorrelation of onset train → dominant periodicity → BPM

Essential for Suno integration: Suno generates at its own BPM, but the openDAW project needs matching tempo. Detect → set_bpm for correct beat alignment when placing stems.

filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns: bpm (60-200), confidence (0-1), onset_count, duration_seconds.

Examples:

After importing a Suno track

result = detect_bpm("suno_track.wav")

→ {bpm: 128.0, confidence: 0.85, onset_count: 240, ...}

Then set project BPM

set_bpm(128)

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description details the algorithm (onset detection + autocorrelation), pure Python implementation, return fields with ranges, and the use case. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose, algorithm steps, use case, parameter, return fields, and example. It is slightly verbose with algorithm details but remains front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nested objects), the description covers all essential aspects: purpose, usage, parameter, returns, and example. The presence of an output schema means return values need not be detailed further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description thoroughly explains the 'filename' parameter: it can be a name in the exports directory or an absolute path, and includes an example. This fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Detect BPM (tempo) of an exported WAV file' with a specific verb and resource. It distinguishes from siblings like mcp_opendaw_set_bpm by outlining the detect→set workflow for Suno integration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use it (for Suno tracks before setting BPM) and provides a usage example. However, it does not explicitly list alternative tools or scenarios where this tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_detect_frequency_maskingA
Read-only

Detect frequency masking between stems — where instruments compete for the same frequency range.

The #1 mix problem. Bass and kick fight at 60-120Hz. Guitars and vocals mask each other at 2-4kHz. This tool finds these conflicts by comparing the spectral content of exported stems pairwise.

For each pair of stems, computes:

  • overlap_score (0-1): how much their spectra overlap in the same band

  • conflict_bands: which frequency bands have the most masking

  • severity: LOW / MEDIUM / HIGH based on overlap and energy

  • recommendation: specific EQ cut/boost suggestion

filenames: JSON array of stem filenames in exports dir, OR comma-separated list. Example: '["bass.wav","kick.wav","vocals.wav"]' or "bass.wav,kick.wav"

Returns per-pair analysis + prioritized list of masking issues.

Example:

Export stems first, then detect masking

export_stems("track") detect_frequency_masking('["track_bass.wav","track_drums.wav","track_other.wav"]')

→ {masking_issues: [{pair: ["bass","drums"], band: "bass", severity: "HIGH", ...}]}

ParametersJSON Schema
NameRequiredDescriptionDefault
filenamesYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations mark readOnlyHint=true, and the description aligns: 'detect', 'finds', 'computes'—no destructive actions. Adds value beyond annotations by detailing the computation (spectral overlap, conflict bands, severity, recommendation). No side effects mentioned, consistent with read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then expands with examples and output fields. Slightly lengthy but every sentence adds value. Could be more terse, but the structure is logical and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (true), the description appropriately summarizes return fields (overlap_score, conflict_bands, severity, recommendation) without duplicating the schema. Includes usage hint (export stems first) and an integrated example. Complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'filenames' has 0% schema description coverage, but the description compensates excellently: explains acceptable formats (JSON array or comma-separated), provides concrete examples, and clarifies it expects stem filenames already in the exports directory. This fully resolves the parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool detects frequency masking between stems, providing concrete examples (bass/kick at 60-120Hz, guitars/vocals at 2-4kHz). Among many sibling analysis tools, this one is uniquely positioned for a specific mix problem. The verb 'detect' paired with 'frequency masking' is precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises exporting stems first via 'export_stems', demonstrated in the example. While it doesn't explicitly state when not to use it, the context (post-export, pairwise analysis) is clear. It distinguishes from generic analysis tools by focusing on masking conflicts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_detect_keyA
Read-only

Detect musical key and mode of a WAV file using chroma features + Krumhansl-Schmuckler key profiles.

Pure Python implementation (no external dependencies):

  1. Parse WAV → mono mixdown

  2. Short-time FFT (4096-point, Hann window, 75% overlap) — pure Python radix-2 Cooley-Tukey

  3. Map spectral bins to 12 pitch classes → chroma vector

  4. Correlate chroma with major/minor key profiles for all 24 keys (12 roots × 2 modes)

  5. Best correlation → key + mode

Essential for Suno integration: detect key → build matching chord progression → create_harmonic_arrangement that fits the imported audio. Enables automatic remix pipeline: download → detect_bpm → detect_key → import → generate matching harmony → mix → render.

filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.

Returns: key (e.g. "A"), mode ("major"/"minor"), confidence (0-1), correlation, alternatives (top 3), chroma (12-element list).

Examples:

After importing a Suno track

result = detect_key("suno_track.wav")

→ {key: "A", mode: "minor", confidence: 0.72, ...}

Then build matching progression

create_chord_progression([["Am","G","F","E7"]])

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already show readOnlyHint, so description adds value by detailing algorithm steps (FFT, chroma, correlation) and return structure. No contradiction. Lacks error or performance notes but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: purpose, algorithm, use case, parameter, return values, example. Front-loaded. Slightly verbose on algorithm details but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, algorithm, input/output, integration pipeline, and example. Output schema not shown but described in full. Comprehensive for a single-param analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage for filename parameter; description compensates by explaining it can be a relative name (without path) or absolute path, and clarifies it's a WAV file. Adds significant meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Detect musical key and mode of a WAV file' with specific algorithm references. Distinguishes from siblings like detect_bpm and detect_scale_from_notes by targeting key/mode detection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes use case in Suno integration and remix pipeline, showing when to use this tool. Lacks explicit when-not-to-use vs alternatives but context is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_detect_problemsA
Read-only

Detect technical audio problems — clipping, DC offset, hum, sibilance, mud, harshness.

Scans for 7 common issues that ruin mixes:

  1. Clipping: samples at or near 0 dBFS (digital clipping)

  2. DC offset: non-zero mean (eats headroom, causes clicks on edit boundaries)

  3. Hum: 50/60Hz mains interference (+ harmonics)

  4. Sibilance: excessive 5-8kHz energy bursts (harsh 's' sounds)

  5. Mud: excessive 200-400Hz buildup (cloudy, unclear mix)

  6. Harshness: excessive 2-5kHz energy (fatiguing, piercing)

  7. Resonances: narrow peaks that stick out (room modes, bad recordings)

filename: WAV file in exports dir, or absolute path.

Returns per-problem detection with severity + recommendation.

Example: detect_problems("vocal_stem.wav")

→ {problems: [{type: "dc_offset", severity: "HIGH", value: 0.002, ...}]}

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description details the 7 problem types, the filename parameter constraints (exports dir or absolute path), and the output format (severity, value, recommendation). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a numbered list and example, but slightly verbose. Front-loaded purpose, but could be trimmed by a sentence or two. Still efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown but referenced), the description provides example output and covers input constraints. All necessary information for an AI agent to invoke the tool correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining the filename parameter: 'WAV file in exports dir, or absolute path.' This adds crucial context beyond the schema's type/required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it detects 7 specific technical audio problems (clipping, DC offset, hum, sibilance, mud, harshness, resonances), which distinguishes it from other analysis tools like detect_bpm or analyze_mix. The verb 'detect' and resource 'technical audio problems' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking audio quality issues and provides an example, but does not explicitly contrast with sibling tools (e.g., detect_frequency_masking) or state when not to use it. Still, the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_detect_scale_from_notesA
Read-only

Detect the musical scale/key from MIDI notes in a region.

Analyses the pitch class distribution of all notes in a region and matches it against 15 common scales using Pearson correlation. Unlike detect_key (which works on WAV audio), this works directly on MIDI note data — no audio file needed.

Scales tested (15):

  • major, natural_minor, harmonic_minor, melodic_minor

  • dorian, phrygian, lydian, mixolydian, locrian

  • pentatonic_major, pentatonic_minor, blues

  • hungarian_minor, double_harmonic, whole_tone

Returns:

  • best_match: {scale, root, correlation} — highest scoring scale

  • alternatives: top 5 matches with correlation scores

  • pitch_class_histogram: 12-bin histogram of note pitches

  • note_count: total notes analysed

  • chromatic_coverage: how many of 12 pitch classes are used

  • confidence: qualitative rating (high/medium/low based on correlation)

Use this before:

  • force_scale_notes (to know which scale to force)

  • diatonic_transpose_notes (to know the correct scale)

  • generate_melody (to match existing material's scale)

  • reharmonize_progression (to pick the right key)

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = first region, -2 = all regions on track).

Example: scale = detect_scale_from_notes(0, 0)

best_match: {scale: "natural_minor", root: "A", correlation: 0.87}

→ use force_scale_notes(root="A", scale="natural_minor")

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, description adds details: analyzes pitch class distribution, uses Pearson correlation, tests 15 specific scales, returns structured output with confidence rating. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: one-sentence summary, method explanation, list of scales, return value details, usage suggestions, parameter descriptions, and example. All sentences are relevant and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description already covers return values explicitly. Tool has only 3 parameters, and description explains all. Complete and no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions coverage is 0%, but description explains each parameter: unit_index, track_index, region_index (with default -1 meaning first region, -2 meaning all). Provides example usage with region_index defaulting to -1.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'detect musical scale/key from MIDI notes in a region', differentiates from sibling 'detect_key' which works on WAV audio. Provides method (Pearson correlation against 15 scales) and lists the scales.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it: before force_scale_notes, diatonic_transpose_notes, generate_melody, reharmonize_progression. Contrasts with detect_key for audio-based key detection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_diatonic_transpose_notesA

Transpose notes by scale steps (diatonic) instead of semitones (chromatic).

Moves each note up or down by N steps within the specified scale. Unlike transpose_notes (which shifts by fixed semitones), diatonic transpose preserves the scale — C major C→D = +1 step (2 semitones), E→F = +1 step (1 semitone).

Essential for: creating variations that stay in key, modal interchange, sequence construction (moving a motif up the scale), walking bass from scale degrees, and counterpoint writing.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks). region_index: Region index (-1 = all regions on track). steps: Number of scale steps to transpose. +1 = up one step, -1 = down one step, +3 = up a third, -5 = down a fifth. 0 = no change. root_note: Root note of the scale — C, C#, D, D#, E, F, F#, G, G#, A, A#, B. scale: Scale name — major, minor, dorian, phrygian, lydian, mixolydian, pentatonic_major, pentatonic_minor, blues, harmonic_minor, melodic_minor.

Returns per-track note counts transposed.

ParametersJSON Schema
NameRequiredDescriptionDefault
scaleNomajor
stepsNo
root_noteNoC
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains the mechanics (moves notes by scale steps, preserves scale), gives examples, and states the return value. It does not explicitly mention that the operation modifies notes in place, but the behavior is implied and reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient, starting with a clear verb and contrasting with siblings. The 'Essential for' section adds valuable context without being excessively verbose. Minor redundancy (e.g., examples already implied by parameter descriptions) keeps it from a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, 0% schema coverage, and presence of an output schema, the description adequately covers purpose, parameters, behavior, and use cases. It distinguishes from a key sibling. It could mention the scope (all notes in specified region/unit/track) more explicitly upfront, but parameter descriptions cover that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: for 'steps' it gives examples (+1 up, -1 down, +3 third), for 'root_note' it lists all notes, for 'scale' it lists all scale names. Every parameter is well-documented beyond the schema's minimal type/default info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool transposes notes by scale steps (diatonic) and explicitly contrasts with the sibling tool transpose_notes (chromatic). It provides concrete examples like C→D and E→F, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes an 'Essential for:' list of use cases (e.g., creating variations that stay in key, modal interchange) and contrasts with chromatic transposition, guiding when to use this tool. However, it does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_displace_rhythmA

Displace all notes in a region by a fixed rhythmic offset — laid-back, push, or circular rotation feel.

Rhythmic displacement shifts notes in time without changing their pitch or duration. This is one of the most expressive production techniques:

  • Laid-back (offset=0.0625 = 1/16 late): drums sit behind the beat, creating a relaxed, hip-hop/R&B feel (J Dilla, Questlove).

  • Pushed (offset=-0.0625 = 1/16 early): notes anticipate the beat, creating urgency and energy (rock, punk, certain jazz).

  • On-top (offset=0): reset any displacement back to original grid.

Two modes:

  • "shift" — add offset to every note's position. Notes can move past the region boundary (region duration auto-extends). Negative offset moves notes earlier; notes before position 0 are clamped to 0.

  • "circular" — rotate the pattern by offset. Notes that go past the region end wrap around to the beginning. This creates entirely new patterns from the same material — a 1/16 rotation of a straight 16th hi-hat pattern creates an off-beat pattern. The region length is preserved.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). offset: Displacement in beats. Positive = later (laid-back), negative = earlier (pushed). Common values: 0.0625 (1/16), 0.125 (1/8), 0.03125 (1/32), 0.25 (1/4). Range -4.0 to 4.0. mode: "shift" (add offset to position, region may extend) or "circular" (rotate within region bounds, region length preserved).

Returns per-track note counts and displacement stats.

Example:

J Dilla laid-back drums — 1/16 note late

displace_rhythm(unit_index=0, track_index=0, offset=0.0625, mode="shift")

Urgent pushed melody — 1/32 early

displace_rhythm(unit_index=0, track_index=3, offset=-0.03125, mode="shift")

Circular rotation — new pattern from same notes

displace_rhythm(unit_index=0, track_index=0, offset=0.125, mode="circular")

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoshift
offsetNo
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description details key behaviors: shift mode extends region, negative offset clamped at 0, circular mode wraps and preserves region length. Return stats are mentioned. No contradictions; adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections for purpose, modes, parameters, and examples. Every sentence adds value; no fluff. Front-loaded with the core action and musical intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects: purpose, two modes with behavioral differences, parameter details, and practical examples. With output schema existing, no need to detail return values separately. Complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description compensates fully by explaining each parameter (unit_index, track_index, region_index, offset, mode) with valid ranges, defaults, and common values. Examples further clarify parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Displace all notes in a region by a fixed rhythmic offset.' It elaborates on modes (shift/circular) and gives concrete musical examples (laid-back, pushed), distinguishing it from sibling tools like apply_swing or quantize_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit context for when to use each mode and offset value, with examples like 'laid-back' and 'pushed.' Implicitly guides when not to use (reset with offset=0), but does not explicitly name alternative tools for similar tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_double_melodyA

Double a melody at a parallel interval — thickening and harmonization.

Creates a copy of every note in the region shifted by the specified interval. Unlike copy_notes_to_track (chromatic transpose only), this supports named musical intervals and diatonic transposition (stays in key).

Same-region doubling (dest_track_index=-1) thickens the melody in place. Cross-track doubling (dest_track_index set) creates a separate layer — useful for assigning a different instrument to the doubled line.

Intervals (chromatic mode):

  • octave: +12 semitones (classic doubling)

  • double_octave: +24 semitones (organ/pipe effect)

  • fifth: +7 semitones (power chord, open sound)

  • fourth: +5 semitones (suspended, ambiguous)

  • third: +4 semitones (major third — use diatonic for correct quality)

  • sixth: +9 semitones (wide, romantic)

  • unison: +0 semitones (thickening only, velocity difference)

Diatonic mode (diatonic=True): Uses scale-degree offsets instead of fixed semitones. A diatonic third in C major is +2 scale steps (C→E, D→F, E→G), producing the correct quality (major or minor third) depending on the scale degree. Requires root+scale.

velocity_scale: Doubled line velocity (0.8 = slightly quieter, classic). time_offset: Delay the doubled line (0 = parallel, 0.25 = slight delay).

unit_index: Source AU index. track_index: Source note track index. interval: Named interval (octave/double_octave/fifth/fourth/third/sixth/unison). region_index: Source region (-1 = first region). diatonic: If True, use scale-degree offset (requires root+scale). root: Scale root note (C, C#, D, ... B). scale: Scale name (major, minor, dorian, phrygian, etc.). velocity_scale: Velocity multiplier for doubled notes (0-2). dest_track_index: Destination track (-1 = same region, thickening in place). dest_unit_index: Destination AU (-1 = same as source). time_offset: Beat offset for doubled notes (0 = parallel).

Returns count of notes doubled.

Example:

Octave doubling — thickens melody in place

double_melody(0, 3, "octave", velocity_scale=0.7)

Diatonic thirds on separate track — classic harmony

double_melody(0, 3, "third", diatonic=True, root="C", scale="major", dest_track_index=4, velocity_scale=0.8)

Power-chord doubling

double_melody(0, 3, "fifth", velocity_scale=0.9)

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
diatonicNo
intervalNooctave
unit_indexYes
time_offsetNo
track_indexYes
region_indexNo
velocity_scaleNo
dest_unit_indexNo
dest_track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It clearly states what the tool does: creates a copy of every note shifted by an interval, and describes the behavior for chromatic and diatonic modes, return value (count of notes doubled). It does not explicitly state that it modifies existing notes (destructive) or if it requires a selected region, but the overall behavior is well explained. A small gap: no mention of prerequisites (e.g., track must exist) or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but well-structured: it starts with a one-line purpose, then contrasts with sibling, explains mode options, lists interval definitions with musical context, and ends with example use cases. It could be slightly shorter by omitting some interval details that might be redundant for experienced users, but overall it is efficient and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and an output schema (present), the description covers all essential information: what the tool does, when to use it, how each parameter works, and example invocations. It provides enough context for an AI agent to select and invoke the tool correctly, including clarification of edge cases (same-region vs cross-track, diatonic mode requirements).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (no descriptions in the input schema parameters). The description compensates fully by explaining each parameter in detail: interval options with musical context, diatonic mode requirements, velocity_scale, time_offset, unit_index, track_index, etc. It adds substantial meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear action verb and resource: 'Double a melody at a parallel interval — thickening and harmonization.' It explicitly contrasts with the sibling tool copy_notes_to_track by highlighting support for named intervals and diatonic transposition, making the purpose distinct and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus alternative: 'Unlike copy_notes_to_track (chromatic transpose only), this supports named musical intervals and diatonic transposition (stays in key).' It further explains two distinct use cases (same-region vs cross-track) and includes concrete examples for octave doubling, diatonic thirds, and power-chord doubling, leaving no ambiguity about usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_download_audioA

Download an audio file from a URL (e.g. Suno CDN) to local disk.

Bridges the gap between AI music generators (Suno, Udio) and the DAW: generate a track → get audio URL → download → import_audio_to_tracks. Without this, you need manual curl/wget outside the MCP pipeline.

Supports any HTTP(S) URL pointing to WAV/MP3/FLAC/OGG. Uses streaming download with timeout. Files saved to /tmp by default (or custom dir).

url: Direct URL to the audio file (e.g. Suno CDN audio_url from chirp_generate). filename: Output filename (default: derived from URL path). output_dir: Directory to save (default /tmp). Must exist.

Returns absolute file path, size, and suggested next step (import_audio_to_tracks).

Examples:

Download a Suno track

download_audio("https://cdn.suno.ai/abc123.wav")

Custom name

download_audio("https://cdn.suno.ai/abc123.mp3", filename="my_track.mp3")

Then import with stem splitting

import_audio_to_tracks("/tmp/my_track.mp3", mode="bs6")

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
filenameNo
output_dirNo/tmp

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses supported formats (WAV/MP3/FLAC/OGG), streaming download with timeout, default save location (/tmp), and return values (path, size, suggestion). No annotations provided, so description carries full burden. Lacks details on error handling or overwrite behavior, but core behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections for purpose, pipeline context, supported formats, parameter details, return value, and examples. Front-loaded with core function. Some redundancy (e.g., examples repeated), but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameters, return, and next steps. Assumes output schema exists for return value details (not shown). Missing explicit error handling or edge cases, but for a download tool, the description is sufficiently complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description fully compensates by explaining each parameter: url (direct URL from AI generator), filename (default derived from URL), output_dir (must exist, default /tmp). Examples demonstrate usage with custom filenames.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb ('download'), resource ('audio file from URL'), and context (bridges AI generators and DAW). Distinguishes from siblings by explaining its position in the pipeline: generate track → get URL → download → import audio. Examples reinforce purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (after generating a track, before import_audio_to_tracks) and provides alternatives (manual curl/wget). Includes examples with specific use cases (Suno tracks) and next steps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_audiounitA

Duplicate an audio unit with all its content: instrument, effects, tracks, regions, notes, automation.

Creates a new audio unit of the same type (Instrument/Audio) with a copy of:

  • Instrument device (same factory type + all parameters)

  • Audio effect chain (same effects + all parameter values)

  • MIDI effect chain (same effects + all parameter values)

  • Note tracks, note regions, and all note events (pitch/duration/velocity/position)

  • Track volume, panning, mute state

  • Audio regions (if any, referencing same audio files)

  • Unit label, volume

unit_index: Source audio unit index to duplicate.

Returns the new unit index and details of what was copied.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details exactly what is copied (instrument, effects, tracks, etc.) but does not mention side effects like whether the original remains unchanged or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bullet points, front-loaded with purpose, and each sentence adds value. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since an output schema exists, return values are covered. The description comprehensively lists what is duplicated but could mention that the original audio unit remains unchanged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description only says 'unit_index: Source audio unit index to duplicate.' This adds minimal meaning beyond the schema, lacking explanation of range or how to obtain the index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool duplicates an audio unit with all its content, listing specific elements copied. It distinguishes from sibling duplication tools like clone_clip or clone_track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description implies duplication context, it does not explicitly state when to use this tool versus alternatives like duplicate_effect or duplicate_notes. No when-not or contrast is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_automation_eventA

Duplicate an automation event within the same region.

Copies the event's position, value, and interpolation. Can offset position and override the value.

unit_index/track_index/region_index: Automation region coordinates. event_index: Event index within the region. position_offset: PPQN offset from original position. value_override: New value (0-1) instead of copying. Omit to copy original.

Returns the new event's position and value.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
event_indexYes
track_indexYes
region_indexYes
value_overrideNo
position_offsetNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool copies position, value, and interpolation, can offset position, override value, and returns the new event's position and value. This provides sufficient behavioral context, though it does not mention side effects or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear opening, followed by behavioral details, parameter explanations, and return value. It is well-structured and avoids superfluous text, though it could be slightly tighter by combining some lines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity, the description explains all parameters and the return value, matching the output schema. It does not address error conditions or prerequisites, but for a duplication tool with an output schema, it is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description explains each parameter: coordinates (unit/track/region_index), event_index, position_offset as PPQN offset, value_override with range 0-1 and omission behavior. This adds significant meaning beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Duplicate an automation event within the same region,' specifying the exact action and resource. It further explains that it copies position, value, and interpolation, distinguishing it from sibling tools like create, update, move, or delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to duplicate an automation event) but does not explicitly state when not to use it or provide alternatives. While the purpose is clear, explicit usage guidance would help the agent decide between similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_effectB

Duplicate a single effect within an AU's effect chain, copying all parameter values.

Addresses upstream issue #273 (Ctrl+D for audio effects) via MCP. Works for both audio and MIDI effect chains.

unit_index: AU index containing the effect. effect_index: Index of the effect to duplicate within its chain. chain_type: "audio" (default) or "midi" — which effect chain to operate on.

Returns the new effect's index and type.

ParametersJSON Schema
NameRequiredDescriptionDefault
chain_typeNoaudio
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that parameter values are copied and that the tool works for both chain types. However, it does not describe side effects (e.g., whether the original is unaffected), where the duplicate is inserted, or behavior on invalid inputs. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear purpose sentence, a reference to the upstream issue, a note on chain support, a bullet-style parameter list, and a return value statement. No superfluous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the core action, parameters, and return value. However, it omits details on error handling (e.g., invalid indices), placement of the duplicate, and any effects on the original chain. Given the tool's simplicity and the presence of an output schema, it is mostly adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains each parameter with context: unit_index is the AU index, effect_index is the position in the chain, and chain_type specifies audio or MIDI with default. This adds meaning beyond the schema's bare titles and defaults, though it could clarify indexing (0-based?) and range constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it duplicates a single effect within an AU's effect chain, copying parameter values. It references the Ctrl+D shortcut and mentions support for both audio and MIDI chains. However, it does not specify where the duplicate is placed (e.g., after the original), which slightly reduces clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as the MCP equivalent of Ctrl+D for audio effects and states it works for both chain types. However, it provides no explicit guidance on when to avoid this tool in favor of siblings like clone_effect_chain or duplicate_audiounit, nor does it mention prerequisites or error conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_note_eventB

Duplicate a note event within the same region with optional position/pitch offset.

Copies the note's position, duration, pitch, velocity, cent, chance, playCount. Can transpose and shift the copy relative to the original.

unit_index/track_index/region_index: Region coordinates. note_index: Note index within the region. position_offset: PPQN offset from original position (default 0 = same position). pitch_offset: Semitone offset from original pitch (default 0 = same pitch).

Returns the new note's position, pitch, and duration.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_indexYes
unit_indexYes
track_indexYes
pitch_offsetNo
region_indexYes
position_offsetNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description discloses that it copies various note properties and can offset position/pitch, and returns new note data. However, it does not mention side effects, authorization needs, or error conditions (e.g., invalid note_index).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise and well-structured: purpose, copied properties, parameter explanations, return value. Each sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and an output schema, description covers all parameters and specifies return fields. It explains the core operation and offsets but lacks details on error handling or edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds meaning for all 6 parameters: explains unit/track/region coordinates, note index, and defaults for offsets. Provides units (PPQN, semitones) and context beyond schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool duplicates a note event within the same region with optional offsets. It lists copied properties, distinguishing from generic duplicate tools. However, it does not explicitly differentiate from sibling tools like duplicate_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as duplicate_notes or create_note. The description implies duplication within a region but does not state when-not-to-use or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_note_regionA

Duplicate a note region to a new position.

Copies the region and all its notes to offset_beats after the original. Useful for repeating patterns (e.g. duplicate 1-bar loop to bar 2).

unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region to duplicate (0-based). offset_beats: How far to shift the copy (in beats, e.g. 4.0 = next bar in 4/4).

Returns new region index.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
offset_beatsYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the region's notes are copied to offset_beats after the original and that it returns a new region index. However, it does not discuss potential side effects (e.g., whether the original region is modified, if there are constraints on offset_beats, or if the operation is reversible). Given the lack of annotations, the disclosure is decent but could be more thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficient: 8 sentences, no fluff. It front-loads the purpose, then includes usage context, then lists parameters with examples. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does, when to use it, and how to use it with parameter details. It mentions the return value ('Returns new region index'). For a duplication tool, this is largely complete. However, missing details like whether it can duplicate across tracks or what happens if region_index is invalid would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (no parameter descriptions in the JSON schema). The description compensates by explaining each parameter: unit_index (-1 = search all AUs), track_index (note track index within AU), region_index (0-based), and offset_beats (in beats, with example 4.0 = next bar in 4/4). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Duplicate a note region to a new position') and the resource ('note region'). It distinguishes itself from siblings like 'duplicate_region' and 'duplicate_note_event' by specifying it duplicates a note region (not audio region or individual note events). The verb+resource is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete use case example ('e.g. duplicate 1-bar loop to bar 2') and states it is 'Useful for repeating patterns'. While it does not explicitly mention when not to use or list alternative tools, the context of use is clear and sufficient for typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_notesA

Duplicate all notes within a region, shifting them after the last note.

Creates copies of every note in the region, shifted by (max(position+duration) - min(position)). This mirrors the DAW's native "duplicate notes" feature.

unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region whose notes to duplicate (0-based).

Returns count of duplicated notes and shift in beats.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It explains the shift calculation (max(position+duration) - min(position)) and what is returned (count and shift). However, it does not disclose side effects, error conditions, or authentication needs. Moderately transparent but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with three short paragraphs: first defines the action, second explains the shift logic and DAW mirroring, third lists parameters. No redundant sentences. Well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (context signals indicate has output schema: true), the description's note on return values ('count of duplicated notes and shift in beats') is sufficient. For a three-parameter mutation tool, it covers the core behavior and expected output, though it could mention prerequisites like region existence or limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description compensates by explaining each parameter: unit_index (including -1 special value), track_index, and region_index. This adds meaning beyond the schema titles. However, the descriptions are brief and do not specify constraints or valid ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Duplicate all notes within a region') and the resource ('notes within a region'), with the specific behavior of shifting them after the last note. It distinguishes itself from sibling duplicate tools by specifying it operates on notes in a region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it mirrors the DAW's 'duplicate notes' feature and lists parameters, but it does not provide explicit guidance on when to use this tool versus alternatives like mcp_opendaw_copy_notes_to_track or mcp_opendaw_duplicate_note_region. No when-to-use or when-not-to-use context is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_regionA

Duplicate any region (audio, note, or value) using the DAW's built-in duplicateRegion API.

Places the copy right after the original. With find_free_space=True, scans for the first available gap on any track (auto-resolves overlaps). Without it, places on the same track at the original's end position.

unit_index: Audio unit index (-1 = search all AUs). track_index: Track index within the AU. region_index: Region to duplicate (0-based). find_free_space: If True, find the first free space on any track. If False, place directly after the original on the same track.

Returns the new region's position and index.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes
find_free_spaceYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given no annotations, the description effectively discloses the placement behavior (after original or on free space on any track) and that it returns the new region's position and index. It does not mention side effects or permissions, but the core behavior is well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear purpose sentence, followed by high-level behavior explanation, then parameter list. No redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the tool's complexity and the presence of many sibling duplicate tools, the description is fairly complete for the tool itself. However, it lacks comparative guidance to help an agent select this tool over similar ones, slightly reducing contextual completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description fully explains all four parameters: unit_index (with -1 meaning search all AUs), track_index, region_index (0-based), and find_free_space (with clear behavior for True/False). This adds essential meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool duplicates any region (audio, note, or value) using the duplicateRegion API. It specifies the action and resource type, and distinguishes from sibling duplicate tools by focusing on regions rather than other entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the two modes based on find_free_space parameter, providing guidance within the tool. However, it does not guide when to choose this tool over other duplicate tools (e.g., duplicate_note_region, duplicate_notes) from the sibling set, lacking explicit selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_duplicate_sectionA

Duplicate all regions within a beat range to a new position.

Scans all tracks across all specified audio units, finds every region that overlaps the [from_beat, to_beat) range, and copies each one to target_beat with the same relative offset. This is the arrangement operation producers use constantly: "copy verse 1 to bar 17" or "duplicate this 8-bar section after itself".

Works with note regions, audio regions, and automation regions. Preserves all content (notes, audio, automation events).

from_beat: Start of the source section in beats. to_beat: End of the source section in beats (exclusive). target_beat: Where to place the duplicated section (beat 0 = start of project). unit_indices: Comma-separated AU indices to scan (default: all AUs).

Returns number of regions duplicated, per-track details, and new positions.

Examples: duplicate_section(from_beat=0, to_beat=16, target_beat=16) -> Copy first 4 bars (0-16 beats) to beat 16 (bars 5-8) duplicate_section(from_beat=0, to_beat=32, target_beat=32, unit_indices="0,1,2") -> Copy first 8 bars from AUs 0,1,2 to beat 32

ParametersJSON Schema
NameRequiredDescriptionDefault
to_beatYes
from_beatYes
target_beatYes
unit_indicesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states it works with note, audio, and automation regions, preserves content, and returns details. However, it does not mention potential overlapping regions or undo behavior, which would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is structured with a summary, detailed explanation, parameter list, and examples. It is front-loaded with the core action. Slightly verbose but well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity and no annotations, the description covers the operation, region types, parameter details, and return value. Examples enhance understanding. It is mostly complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains all parameters (from_beat, to_beat, target_beat, unit_indices), notes defaults, and provides examples. This adds significant meaning beyond the basic schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Duplicate all regions within a beat range to a new position.' It specifies the action (duplicate) and resource (regions within a beat range). The mention of 'arrangement operation producers use constantly' and examples differentiate it from other duplicate tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear examples like 'copy verse 1 to bar 17' and explains when to use (copying sections). However, it does not explicitly state when not to use it versus alternatives like duplicate_region or move_section, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_engine_panicA

Send a panic signal to the engine — stops all notes immediately.

Useful when audio gets stuck (hanging notes, frozen synthesis). Equivalent to a MIDI panic button.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses that it stops all notes immediately, which is a destructive action. However, it doesn't mention side effects, reversibility, or if it affects engine state beyond stopping notes. Minimal but functional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action. No filler. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with no parameters and output schema present. Description explains core function and use case. Could add more on safety or calling frequency, but sufficient for an emergency stop.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so description doesn't need to add parameter info. Baseline score for no parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool sends a panic signal to stop all notes immediately. Explicitly mentions use cases like hanging notes and frozen synthesis, and equates to a MIDI panic button. Distinguishes from sibling tools like engine_sleep or engine_wake.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use ('when audio gets stuck'). Lacks explicit when-not-to-use or alternatives like engine_sleep, but the analogy to a MIDI panic button implies emergency use. Clear enough for a simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_engine_sleepA

Put the audio engine to sleep — suspends audio processing to save CPU.

Use wake() to resume. Useful when doing non-audio operations (project editing, box manipulation) and the engine isn't needed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions suspending audio processing to save CPU but does not disclose side effects like whether playback stops or state is preserved. Adequate but minimal for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. Purpose is front-loaded, and usage context follows efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter tool with an output schema, the description covers the essential behavior and use case. Could optionally mention output, but not required per rules.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and description does not need to add param info. Baseline 4 for 0 parameters; no compensation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (put to sleep) and resource (audio engine) with a specific verb. Distinguishes from siblings like engine_wake and other audio processing tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions when to use (non-audio operations to save CPU) and the wake() alternative for resuming. Lacks explicit 'when not to use', but the positive use case is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_engine_wakeA

Wake the audio engine from sleep — resumes audio processing.

Use after sleep() when audio playback is needed again.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It states the tool wakes the engine and resumes processing, but does not disclose potential side effects or idempotency. For a simple wake operation, this is adequate but lacks extra detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with two short sentences. The first sentence states the purpose, and the second provides usage guidance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 params, no complex behavior), the description is complete. It explains what it does, when to use it, and an output schema exists (though not detailed). No further information is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema coverage is 100%. The description adds value by explaining the tool's purpose and usage, which goes beyond the empty schema. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Wake' and clearly identifies the resource as 'the audio engine'. It states the action of resuming audio processing, which is distinct from the sibling tool 'mcp_opendaw_engine_sleep'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'Use after sleep() when audio playback is needed again'. This provides clear context, though it could be more explicit about not using it when the engine is already awake.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_evaluate_rawA
Read-only

Execute arbitrary JavaScript in the DAW V8 context and return the result. For power users and debugging — explore openDAW internals directly. The script must be a function body (will be wrapped in an async arrow).

script: JavaScript code to execute. Has access to window.DAW and all DAW_ globals.

ParametersJSON Schema
NameRequiredDescriptionDefault
scriptYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description adds details: script wrapping in async arrow, access to DAW globals. No contradiction. Benefits from annotation coverage for safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, no fluff. Main action in first sentence, context in second, usage in third, parameter in fourth. Excellent front-loading and structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameter details, and script environment. Output schema exists so return values are covered. Minor gap: no error handling or execution limits, but acceptable for a debug tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'script' with 0% schema description coverage. The description compensates by explaining what the script can access and that it's wrapped as an async function body. Adds significant meaning beyond type alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it executes arbitrary JavaScript in the DAW V8 context. The verb 'execute' and resource 'JavaScript' are specific. No sibling does arbitrary code execution, so it stands out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly targets power users and debugging for exploring openDAW internals. Implicitly advises against using for routine tasks, but does not list explicit alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_expand_intervalsA

Expand or compress melodic intervals by a factor.

Multiplies the interval between each consecutive pair of notes by factor. Values >1 widen the melody (small steps become leaps), values <1 narrow it (leaps become steps). The first note's pitch is kept as anchor (or centered around the mean pitch).

This is a fundamental transformation in motivic development:

  • factor=2.0: seconds become thirds, thirds become fifths

  • factor=0.5: thirds become seconds, fifths become thirds

  • factor=1.5: gentle expansion, more expressive contour

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) factor: Interval multiplier (0.25-4.0). 1.0=no change, 2.0=double all intervals, 0.5=halve all intervals. anchor: Anchor point — "first" = keep first note pitch, expand from there, "center" = keep mean pitch, expand symmetrically, "last" = keep last note pitch, expand backwards. snap_to_scale: Scale name for snapping results ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "" = no snapping, chromatic result). root: Root note for scale snapping (C, C#, D, ... B).

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
anchorNofirst
factorNo
unit_indexYes
track_indexYes
region_indexNo
snap_to_scaleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains anchor behavior (first note kept, or mean centered), the effect on intervals, and snap-to-scale option. It doesn't detail side effects like reversibility or whether it modifies in place, but overall provides solid transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, examples, and parameter list. It is slightly lengthy but necessary given the parameter count, and front-loads the key purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no annotations, and presence of output schema, the description covers inputs comprehensively. It implies modification of notes in the region but doesn't explicitly state the output or side effects (e.g., whether notes are replaced). Still robust for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully documents all 7 parameters: unit_index, track_index, region_index, factor, anchor, snap_to_scale, and root. It includes defaults, range for factor (0.25-4.0), and explanations for each anchor and scale option.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it expands or compresses melodic intervals by a factor, with concrete examples for different factor values. It distinguishes itself from sibling tools like transpose (which shifts all notes equally) and invert by focusing on interval multiplication.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context as 'a fundamental transformation in motivic development' and gives example factors for typical uses. However, it does not explicitly state when not to use this tool or compare directly to alternatives beyond the implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_explode_chordsA

Explode chords into separate voice tracks.

Takes a chord track and splits each chord into individual voices, distributing them to separate tracks. The lowest note of each chord goes to voice 1 (bass), the next to voice 2, etc. This is the fundamental orchestration technique — converting a chord progression into individual instrumental parts.

Typical use: piano chord track → bass + cello + viola + violin. Or: synth chords → sub bass + pad + lead + pluck.

Args: unit_index: Source AU index with chord track track_index: Source note track index with chords region_index: Source region index (-1 = first region) num_voices: Number of voices to split into (2-8, default 4). Chords with fewer notes than num_voices get rests in higher voices. Chords with more notes than num_voices get extra notes merged into the highest voice. direction: Voice assignment order — "down": lowest note → voice 1 (bass), ascending voices "up": highest note → voice 1 (top), descending voices "outward": middle notes → outer voices, edge notes → inner target_units: Comma-separated AU indices for destination tracks. If empty, creates new AUs automatically. If provided, must have at least num_voices entries (e.g. "0,1,2,3"). velocity_balance: How to distribute velocity across voices — "natural": lower voices slightly louder (bass prominence) "equal": all voices same velocity "top_heavy": upper voices louder (melody prominence) "fade": velocity decreases from voice 1 to voice N

ParametersJSON Schema
NameRequiredDescriptionDefault
directionNodown
num_voicesNo
unit_indexYes
track_indexYes
region_indexNo
target_unitsNo
velocity_balanceNonatural

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It thoroughly explains the behavior: lowest note to voice 1, handling of fewer/more notes, direction options, velocity balance options, and target unit behavior. This level of detail exceeds expectations for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise one-liner, followed by a process explanation, a typical use example, and then parameter details. Every sentence adds value without redundancy. It's appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully covers the tool's functionality, parameter details, and use cases. With an output schema available (though not provided), the description does not need to explain return values. It is complete for an agent to correctly invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's 'Args' section provides comprehensive meaning for each parameter: defaults, valid ranges (2-8 for num_voices), behaviors (e.g., 'Chords with fewer notes... get rests'), and options (direction and velocity_balance with enumerated values). This fully compensates for the schema lack.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Explodes chords into separate voice tracks' and explains the orchestration process. The verb 'explode' is specific, and the resource ('chords' into 'voice tracks') is well-defined. This distinguishes it from sibling tools like 'invert_chord_notes' or 'spread_voicing' by focusing on splitting chords into separate tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides typical use cases ('piano chord track → bass + cello + viola + violin') and explains the orchestration technique. It does not explicitly state when not to use it or list alternatives, but the context is clear. The presence of many sibling tools makes this a solid 4, as it offers enough guidance for selecting the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_dawprojectA

Export the current project as a .dawproject file (Bitwig/Ableton/rePitch compatible format).

The dawproject format is a ZIP containing project.xml, metadata.xml, and audio samples. This enables interoperability with other DAWs that support the dawproject format.

Args: filename: Output filename (without extension). The .dawproject extension is added automatically.

Returns the file path of the exported .dawproject file.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoproject

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adds some behavioral context (ZIP format, automatic extension) but does not state whether the operation is destructive, requires authentication, or has performance implications. The safety profile is unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short sections: purpose, format explanation, and parameters. The first sentence is front-loaded. The Args section is slightly redundant but not excessive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter) and existence of an output schema, the description covers the essential aspects: output format, parameter details, and return value. Lacks discussion of limitations or defaults, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains the 'filename' parameter meaning and notes the extension is appended automatically, adding clarity beyond the schema's default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports the current project as a .dawproject file, specifying verb, resource, and format. It distinguishes from sibling tools like export_midi and export_stems by highlighting cross-DAW compatibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for interoperability with other DAWs but lacks explicit when-to-use or when-not-to-use guidance. No direct comparison with alternative export tools is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_dry_stemA

Export a single audio unit as a DRY stem (instrument output, no effects/channel strip).

Unlike export_single_stem (which routes through the channel strip with effects), this captures the raw instrument output before any audio effects, sends, or volume/pan processing. Useful for freezing, flattening, or re-amping workflows where you want the clean instrument signal to process externally.

unit_index: Audio unit index to export (must be > 0, not the output AU). filename: Output filename (without .wav extension). sample_rate: Export sample rate (default 48000).

Returns the path to the exported WAV and audio metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
unit_indexYes
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the tool captures raw output before audio effects, sends, volume/pan processing. It also notes unit_index must be >0 and not the output AU. However, it does not disclose potential side effects (e.g., whether it replaces original audio) or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with three clear paragraphs: purpose, comparison, parameters. Some slight redundancy in describing 'no effects' but overall efficient. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, comparison, parameter constraints, and use cases. Has output schema so return values are documented elsewhere. Lacks information on file location, persistence, or blocking behavior, but adequate for a straightforward export tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides meaningful parameter explanations: unit_index must be >0 and not output AU, filename without .wav extension, sample_rate default 48000. This adds critical context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports a single audio unit as a DRY stem, contrasting it with export_single_stem which includes effects. It specifies the resource (audio unit), the action (export), and the concept of dry stem (no effects/channel strip).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool versus export_single_stem: 'Unlike export_single_stem (which routes through the channel strip with effects), this captures the raw instrument output...' Also lists use cases: freezing, flattening, re-amping.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_effect_chainA

Export an effect chain (audio or MIDI) from an AU as a base64 preset.

Uses PresetEncoder.encodeEffects — serializes the effect chain into a preset binary. Can be imported into another AU via import_effect_chain.

unit_index: AU index to export from. effect_type: "audio" for audio effects, "midi" for MIDI effects.

Returns base64 preset bytes, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_typeNoaudio

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations present, so the description carries full burden. It discloses that it uses PresetEncoder.encodeEffects and returns base64 bytes or error, but does not explicitly state that the operation is non-destructive or read-only. The behavioral transparency is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three sentences plus parameter explanations, front-loading the purpose. No redundant information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters, no annotations, and an output schema, the description covers the return value (base64 preset bytes), the internal encoder, and forward reference to import_effect_chain. It omits context about the AU (likely an audio unit/device), but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by explaining unit_index (AU index to export from) and effect_type (audio or MIDI, with default 'audio'). It adds meaning beyond the schema but lacks indexing convention (e.g., 0-based or 1-based).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports an effect chain as a base64 preset. It distinguishes from siblings like export_preset (exports a single preset) and import_effect_chain (imports), specifying audio or MIDI chains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions the preset can be imported via import_effect_chain, hinting at a use case. However, it does not explicitly say when to use this over alternatives like clone_effect_chain or export_preset, nor does it provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_midiA

Export a note region's notes as a standard MIDI file (.mid).

Uses @opendaw/lib-midi MidiFileEncoder — converts note events to MIDI with timeDivision=96 (PPQN.Quarter=960 → 96 ticks per quarter).

filename: Output filename (without extension). unit_index: Audio unit index (-1 = search all AUs for note tracks). track_index: Note track index within the AU. region_index: Region to export (0-based).

Returns the saved file path.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the library used, time division, and returns the file path. However, it does not state side effects, destructive nature, or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a clear introductory statement, library detail, parameter list, and return value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the essential functionality, parameters, and return value. Could mention error cases or required project state but is adequate for a straightforward export tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds clear meaning for all 4 parameters (filename without extension, unit_index, track_index, region_index). Fully compensates for missing schema docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Export a note region's notes as a standard MIDI file (.mid).' This is a specific verb and resource, and it distinguishes from siblings like import_midi or export_stems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. The purpose is implied, but no context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_mixB

Render the full project mix to a WAV file.

Uses OfflineEngineRenderer (same as render_full). The 'method' parameter is accepted for backward compatibility but always uses offline rendering (faster, no engine needed).

filename: Output filename (without .wav extension). sample_rate: Export sample rate (default 48000). method: 'offline' (default), 'realtime', or 'auto' — all use offline.

Returns the path to the exported WAV and audio metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
methodNooffline
filenameYes
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden. It discloses that it uses offline rendering (faster, no engine), explains the method parameter's actual behavior, and mentions output includes path and metadata. However, it does not address potential side effects like file overwriting or project state requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the main action and key details front-loaded. It could be more structured with per-parameter bullet points, but overall it is efficient without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema available, the description need not detail return values. It covers the main purpose, method behavior, and parameters. However, it lacks information on prerequisites (e.g., project must be loaded), error conditions, or asynchronous behavior. For a tool with many siblings, more context on when to use it would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates well by explaining each parameter: filename (without .wav extension), sample_rate (default 48000), and method (always uses offline regardless of value). This adds meaning beyond the schema's types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renders the full project mix to a WAV file, with specifics about using OfflineEngineRenderer and the method parameter's backward compatibility. However, it does not explicitly distinguish itself from render_full or other export tools like export_stems, which could cause ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool over alternatives like render_full or export_stems. No prerequisites or scenarios mentioned. The description only states what it does, not when to choose it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_presetA

Export an audio unit as a preset (base64-encoded binary).

Uses PresetEncoder.encode — serializes the AU with all dependencies (instrument, effects, MIDI effects, optionally tracks/regions/notes) into a binary preset format. Output is base64-encoded for transport over JSON.

unit_index: AU index to export (must be an instrument, not Output). include_timeline: If true, include tracks/regions/notes in the preset.

Returns base64-encoded preset bytes and metadata, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
include_timelineNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses internal mechanism (PresetEncoder.encode), dependencies (instrument, effects, etc.), base64 encoding, and return type. It is transparent about what gets serialized.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (approx. 100 words), front-loaded with the main purpose, then technical details, then parameter explanations. No redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description need not detail return values, but it still mentions returning base64 bytes and metadata. It covers all necessary aspects for a 2-parameter export tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must add meaning. It explains unit_index must be an instrument (not Output) and include_timeline includes tracks/regions/notes. This goes beyond the schema's titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports an audio unit as a preset in base64-encoded format. It specifies the verb 'export', the resource 'audio unit', and the output format. This distinguishes it from siblings like export_midi or export_stems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through parameter constraints (unit_index must be an instrument, not Output) but does not explicitly compare to other export tools or state when to prefer this one. No alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_single_stemA

Export a single audio unit as a stem WAV with its effect chain applied.

Unlike export_stems (which exports ALL stems in one pass), this exports just one AU — faster when you only need a specific stem.

unit_index: Audio unit index to export (must be > 0, not the output AU). filename: Output filename. sample_rate: Export sample rate.

The stem includes all effects on that AU's chain (EQ, compression, reverb, etc).

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
unit_indexYes
sample_rateYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states that the stem includes the effect chain but does not disclose whether the operation is destructive, requires specific permissions, or any side effects (e.g., file overwrite, format details). For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, followed by a concise sibling comparison, a parameter list, and a final note on the effect chain. Every sentence adds value, and the structure is clean with line breaks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains input parameters and the effect chain inclusion but lacks details about the output (e.g., bit depth, channels, file location, overwrite behavior). Given that an output schema exists (per context), some of this may be covered there, making the description minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates by explaining each parameter: unit_index (must be >0, not output AU), filename (output filename), sample_rate (export sample rate). This adds critical constraints and purpose beyond the schema's type-only definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'export', resource 'single audio unit', and format 'stem WAV with its effect chain applied'. It explicitly distinguishes from sibling 'export_stems' by contrasting scope (single vs all) and use case ('faster when you only need a specific stem').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case (when you need one stem) and explicitly contrasts with the sibling 'export_stems'. However, it does not include exclusions or prerequisites, such as whether the AU must be enabled or if the file will be overwritten.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_stemsA

Export each audio unit as a separate stem WAV file.

Uses OfflineEngineRenderer with per-AU ExportConfiguration. Each instrument AU gets its own stem with effects included. Returns list of exported stem files.

Workflow: create_instrument_track(s) → load_audio → place_audio_region(s) → add_effect(s) → export_stems

ParametersJSON Schema
NameRequiredDescriptionDefault
sample_rateYes
filename_prefixYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers internal mechanism (OfflineEngineRenderer, per-AU ExportConfiguration) and output (list of stem files). It does not detail side effects like file overwriting, but for a read-like export tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four focused sentences plus a workflow line, no filler. Front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes workflow and return type, but missing parameter semantics limits completeness. Output schema exists but doesn't offset parameter gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description adds no detail on filename_prefix format or sample_rate expected range/units. Both required parameters lack semantic clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Export'), resource ('each audio unit as a separate stem WAV file'), and differentiates from sibling tools like export_dawproject or export_midi.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides a concrete workflow chain (create_instrument_track → load_audio → place_audio_region → add_effect → export_stems), guiding when to use this tool. However, it does not explicitly mention when not to use or alternatives like export_single_stem.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_export_stems_formatA

Export stems as separate files and convert each to MP3 or FLAC.

filename_prefix: Prefix for stem filenames. sample_rate: Export sample rate. format: 'wav' (default), 'mp3', or 'flac'. bitrate: MP3 bitrate (default '320k').

Runs export_stems, then converts each stem WAV to the requested format via ffmpeg.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNowav
bitrateNo320k
sample_rateYes
filename_prefixYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must stand alone. Describes two-step process (export_stems + ffmpeg conversion) but lacks details on error handling, temporary file behavior, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one line per parameter, one sentence describing the process. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and process. Could mention return value or file output details, but output schema exists. Minor gap: does not specify if it works on current project stems or requires prior export.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage; description lists each parameter with type, default, and meaning (e.g., bitrate default '320k', format options). Fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb ('export stems' + 'convert') and specific resource. Distinguishes from siblings like export_stems (which likely exports WAV only) by explicitly adding format conversion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use: when you need stems in MP3/FLAC rather than WAV. Mentions it runs export_stems first, hinting at relationship. No explicit 'when not to use' but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_extract_motifsA

Extract repeating melodic motifs from a MIDI region.

A motif is a short melodic phrase (3-8 notes) identified by its interval contour — the pattern of pitch changes between consecutive notes. The same motif transposed to a different key still matches, because the relative intervals are identical.

Essential for: understanding melodic structure of existing pieces, finding repetitive patterns for variation, identifying verse/chorus motifs, and building call-and-response arrangements from existing material.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks). region_index: Region index (-1 = all regions on track). min_motif_length: Minimum notes in a motif (default 3). max_motif_length: Maximum notes in a motif (default 8). min_repetitions: Minimum times a motif must appear to be reported (default 2). max_results: Maximum motifs to return, sorted by significance (default 20).

Returns list of motifs with contour, rhythm pattern, contour type, and occurrence positions.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexNo
max_resultsNo
track_indexNo
region_indexNo
min_repetitionsNo
max_motif_lengthNo
min_motif_lengthNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It explains the transposition invariance and output fields, but does not explicitly state that the tool is read-only (non-destructive) or describe failure conditions. For a read-only analysis tool, this is adequate but leaves some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: opening verb-object statement, definition, use cases, parameter list, and output summary. Every sentence adds value with no redundancy or off-topic content. It is front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters and an output schema (not shown), the description covers input parameters fully and outlines the output structure. It explains the motif concept and use cases. However, it could mention prerequisites (e.g., MIDI region must have notes) or limitations, but overall it is complete for an analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the parameter descriptions in the text are essential. Each parameter is explained with purpose and default values (e.g., 'min_motif_length: Minimum notes in a motif'). This adds significant meaning beyond the schema's names and defaults. However, details like the significance ordering of 'max_results' are not explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Extract repeating melodic motifs from a MIDI region') and defines what a motif is via interval contour. It distinguishes from siblings like 'analyze_melody' and 'transcribe_melody' by focusing on patterns. However, it could be more explicit about which sibling to use for broader analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists specific use cases ('Essential for: understanding melodic structure...') that guide when to use the tool. It does not explicitly state when not to use it or compare with alternatives like 'extract_rhythm' or 'analyze_melody', but the use cases are clear enough for an informed decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_extract_rhythmA

Extract rhythmic pattern from notes — onset grid, syncopation, IOI.

Returns a rhythmic analysis of notes in a region:

  • Onset grid: binary pattern showing which grid positions have note onsets

  • Inter-onset intervals (IOI): time between consecutive note starts

  • Syncopation score: how much the rhythm emphasises weak beats (0-1)

  • Rhythm density: fraction of grid positions with onsets

  • Rhythm string: compact representation (x=onset, .=rest)

  • Swing factor: ratio of odd vs even 16th positions

Grid resolutions:

  • "16th" — 16 positions per bar (default, most common)

  • "8th" — 8 positions per bar

  • "32nd" — 32 positions per bar (fine detail)

  • "quarter" — 4 positions per bar (coarse)

Useful for:

  • Understanding a rhythm before cloning it to another track

  • Measuring syncopation (high = funky, low = straight)

  • Extracting groove for groove_transfer

  • Comparing rhythms between sections

  • Feeding rhythm to generate_melody (rhythm param)

unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first region). grid: Grid resolution (16th/8th/32nd/quarter).

Returns rhythm analysis.

Example: rhythm = extract_rhythm(0, 0, grid="16th")

onset_grid, syncopation, ioi, rhythm_string

ParametersJSON Schema
NameRequiredDescriptionDefault
gridNo16th
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It lists all returned metrics (onset grid, IOI, syncopation, density, rhythm string, swing factor) and explains grid resolutions. No hidden side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with summary, return fields, grid resolutions, use cases, and parameter list. Slightly long but efficient; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists but description compensates with clear return value descriptions. Covers enough for agent to use correctly without external reference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%, but description fully documents all 4 parameters: unit_index, track_index, region_index (with default -1), and grid (with enumerated values and defaults). Adds meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Extract rhythmic pattern from notes'. Distinguishes from siblings like groove_transfer or harmonic rhythm analysis by focusing on rhythm parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases (cloning, syncopation measurement, groove transfer, comparison, melody generation). Does not state when not to use, but context is clear given sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_filter_notesA

Filter notes by criteria — list, delete, or keep matching notes.

Applies multiple filter criteria to notes in a region:

  • Pitch range (min_pitch / max_pitch, MIDI note numbers)

  • Velocity range (min_velocity / max_velocity, 0.0-1.0)

  • Time range (from_beat / to_beat, absolute beat positions)

Any criterion set to -1 is ignored (wildcard).

Actions:

  • list: Return matching notes (read-only, no changes)

  • delete: Delete all notes matching the criteria

  • keep: Delete all notes NOT matching the criteria (inverse filter)

Use cases:

  • Remove notes below C2 (cleanup sub-bass rumble): filter_notes(0, 0, min_pitch=36, action="delete")

  • Isolate melody in upper register: filter_notes(0, 0, min_pitch=72, action="keep")

  • Remove ghost notes (velocity < 0.3): filter_notes(0, 0, min_velocity=0.3, action="delete")

  • Find notes in bar 8-12: filter_notes(0, 0, from_beat=32, to_beat=48, action="list")

  • Trim notes outside a time window: filter_notes(0, 0, from_beat=0, to_beat=16, action="keep")

unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first region). min_pitch: Minimum MIDI pitch (-1 = no filter). max_pitch: Maximum MIDI pitch (-1 = no filter). min_velocity: Minimum velocity 0-1 (-1 = no filter). max_velocity: Maximum velocity 0-1 (-1 = no filter). from_beat: Start beat (-1 = no filter). to_beat: End beat (-1 = no filter). action: "list", "delete", or "keep".

Returns matching note details (list) or deletion count (delete/keep).

Example:

Delete all notes below C2

filter_notes(0, 0, min_pitch=36, action="delete")

Keep only notes in bars 1-4 (beats 0-16)

filter_notes(0, 0, from_beat=0, to_beat=16, action="keep")

ParametersJSON Schema
NameRequiredDescriptionDefault
actionNolist
to_beatNo
from_beatNo
max_pitchNo
min_pitchNo
unit_indexYes
track_indexYes
max_velocityNo
min_velocityNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description explains all behavioral aspects: actions are mutually exclusive, criteria are ANDed together, -1 disables a filter, and the return values differ by action (list returns note details, delete/keep return deletion count). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (intro, criteria, actions, examples). It is somewhat long but every part contributes essential information. Could be slightly tightened but remains effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and three actions, the description covers all aspects: parameter roles, wildcard semantics, action behaviors, return types, and realistic examples. The presence of an output schema further complements completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain each parameter. It does: unit_index, track_index, region_index, all pitch/velocity/beat parameters with ranges and wildcard -1, and the action enum. Examples reinforce usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it filters notes by criteria (pitch, velocity, time range) and supports three actions: list, delete, or keep. This distinguishes it from sibling tools like list_notes (no filter) or delete_note (single note deletion).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides multiple use cases with concrete examples and explains the wildcard behavior (-1). It does not explicitly mention when NOT to use (e.g., prefer delete_note for targeting a single known note), but the examples cover common scenarios effectively.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_find_overlapping_notesA

Find notes that overlap a given pitch and time range within a note region.

Useful for checking if a note can be placed without colliding with existing notes, or for finding chords/harmonies at a specific pitch range.

unit_index: AU index. track_index: Note track index within the AU. region_index: Note region index. pitch: MIDI note number to check (60 = C4). from_beat: Start of time range in beats. to_beat: End of time range in beats.

Returns list of overlapping notes (position, duration, pitch, velocity), or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
pitchYes
to_beatYes
from_beatYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool is a read-only query returning overlapping notes, with no side effects. It does not explicitly state read-only, but the description implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact (6 lines), with purpose first, then usage, then parameter list. Every sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity and presence of an output schema, the description covers purpose, usage, parameters, and return format. It could mention the output schema's structure, but that is not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 6 parameters are described with clear definitions despite the schema having 0% description coverage. The description adds meaning (e.g., pitch '60 = C4', from_beat and to_beat as time range boundaries).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds notes overlapping a given pitch and time range within a note region. It uses specific verb+resource ('Find notes that overlap') and distinguishes from siblings like list_notes or filter_notes by focusing on overlap detection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions two specific use cases: collision checking and harmony/chord finding. It implies when to use this tool but does not explicitly state when not to use it or name alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_flatten_note_regionsA

Flatten (merge) multiple overlapping note regions into a single region.

Merges selected note regions on the same track into one, combining all notes. The original regions are deleted and replaced by a single flattened region.

unit_index: AU index. track_index: Track index within the AU. region_indices: Comma-separated region indices to flatten (e.g. "0,1,2").

Returns the new flattened region info, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indicesYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that original regions are deleted and replaced, and returns new region info or error. Lacks details on permissions, additional side effects, or constraints beyond deletion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, front-loaded with purpose, then behavior, then parameter details, then return info. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists, description covers key behaviors and parameters. Mentions return type. Could include prerequisites like region existence, but adequate for a tool with simple inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds clear explanations for all three parameters, including an example for region_indices. Adds meaning beyond type and requirement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool flattens (merges) overlapping note regions on the same track, using specific verbs and resource. It distinguishes from generic 'merge' tools but does not explicitly differentiate from sibling 'merge_note_regions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when overlapping regions need to be combined, but does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_force_scale_notesA

Force all notes in a region into a specific scale — harmonic snap.

Finds every note that is NOT in the target scale and moves it to the nearest in-scale note. This is the harmonic equivalent of quantize_notes (which snaps timing to a grid). Useful after audio-to-MIDI transcription, random generation, or importing MIDI from unknown sources.

root_note: Root note name — C, C#, D, D#, E, F, F#, G, G#, A, A#, B. scale: Scale name — major, minor, dorian, phrygian, lydian, mixolydian, aeolian, locrian, pentatonic_major, pentatonic_minor, blues, harmonic_minor, melodic_minor. direction: How to resolve out-of-scale notes — "nearest" (closest, default), "up" (always shift up to next in-scale note), "down" (always shift down). preserve_octave: If True (default), keep notes in their original octave — only shift by 1-2 semitones. If False, allow octave jumps to find the nearest match.

Returns count of notes snapped, per-track breakdown, and which notes were changed.

ParametersJSON Schema
NameRequiredDescriptionDefault
scaleNomajor
directionNonearest
root_noteNoC
unit_indexNo
track_indexNo
region_indexNo
preserve_octaveNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full behavioral disclosure. It explains that notes are moved to the nearest in-scale note, details direction and preserve_octave behavior, and mentions the return value. It does not explicitly state whether the operation is destructive or replaces the region, but the description implies modification. Overall, it provides sufficient transparency for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It opens with the core purpose in a single line, followed by a brief explanation, then parameter details, and finally the return value. Every sentence adds value, and the structure is front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and the tool's moderate complexity (7 parameters, no nested objects), the description covers the essential behavior and return values. It explains the effect, parameter options, and expected output. The only minor gap is the missing documentation of the indexing parameters, but overall it is complete enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It covers root_note, scale, direction, and preserve_octave with clear explanations. However, it does not describe unit_index, track_index, or region_index, which are present in the schema. This leaves 3 out of 7 parameters undocumented, meaning the description only partially compensates for the lack of schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Force all notes in a region into a specific scale — harmonic snap.' It explains the action (finds out-of-scale notes and moves them) and compares it to quantize_notes, distinguishing it from siblings like quantize_notes or transpose_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends use cases: 'Useful after audio-to-MIDI transcription, random generation, or importing MIDI from unknown sources.' It also draws an analogy to quantize_notes, helping the agent understand when this tool is appropriate. However, it does not explicitly state when not to use it or list alternatives, leaving a small gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_freeze_audiounitA

Freeze an audio unit — pre-render its output offline to save CPU.

Uses audioUnitFreeze.freeze() which renders the AU's complete output via OfflineEngineRenderer and caches it. While frozen, the AU plays from cache instead of processing instruments/effects in real-time.

Cannot freeze AUs with sidechain dependents or the Output unit.

unit_index: AU index to freeze.

Returns success or error (e.g. sidechain dependents block freeze).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It describes the offline rendering, caching, playback from cache, and the specific function used. It also lists constraints and return type. It does not mention reversibility or side effects, but overall is informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a summary, then technical detail, constraints, parameter, and return. It is concise but could trim some technical jargon. Each sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter and existence of an output schema, the description covers the tool's behavior, constraints, parameter, and return. It lacks error handling specifics but is generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains 'unit_index: AU index to freeze.' This adds basic meaning but lacks specifics like range or how to obtain the index. Adequate for a single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose: 'Freeze an audio unit — pre-render its output offline to save CPU.' It uses a specific verb and resource, and explains the mechanism. The purpose is distinct from sibling tools like unfreeze_audiounit and get_unit_freeze_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives constraints like 'Cannot freeze AUs with sidechain dependents or the Output unit.' However, it does not explicitly state when to use this tool versus alternatives, nor does it provide comprehensive usage context beyond constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_generate_melodyA

Generate a melodic line from a scale using contour-guided random selection.

Creates a melody from scratch — no chord progression needed. The algorithm picks pitches from the specified scale, guided by a contour shape that controls the overall direction of the melodic line.

contour: Melodic shape:

  • "ascending" — starts low, rises throughout (build-up, tension)

  • "descending" — starts high, falls throughout (release, resolution)

  • "arch" — rises then falls (classic A-section, question-answer)

  • "v_shape" — falls then rises (dramatic, bridge)

  • "wave" — oscillates up and down (meandering, B-section)

  • "random" — no contour constraint, pure weighted random

rhythm: Rhythm pattern:

  • "quarter" — all quarter notes (steady, folk)

  • "eighth" — all eighth notes (driving, pop)

  • "syncopated" — mix of quarters and off-beat eighths (jazz, funk)

  • "mixed" — varied durations (16th to half, most musical)

  • "sparse" — mostly rests with occasional notes (ambient, intro)

The algorithm:

  1. Build a scale pitch list spanning 2 octaves centered on octave.

  2. For each beat position, determine the target contour height (0-1 mapping across the melody length).

  3. Map contour height to a pitch range in the scale.

  4. Weighted random selection: notes near the contour target get higher weight, notes far away get lower weight.

  5. Apply rhythm pattern to determine note durations and positions.

  6. Insert rests based on rest_probability.

root: Root note name (C, D, E, F, G, A, B + accidentals). scale: Scale name (major, minor, dorian, phrygian, lydian, mixolydian, aeolian, harmonic_minor, melodic_minor, pentatonic_major, pentatonic_minor, blues). bars: Number of bars (1-16, default 4). contour: Melodic contour shape (see above). rhythm: Rhythm pattern (see above). octave: Center MIDI octave (3=bass, 4=mid, 5=lead, 6=high, default 5). velocity: Base velocity 0-1 (default 0.7). rest_probability: Chance of a rest instead of a note (0-0.5, default 0.15). unit_index: AU index with note tracks. track_index: Note track index for the melody. start_beat: Position in beats.

Returns notes created, contour shape, scale used, pitch range.

Example:

Arch-shaped C major melody, 4 bars, mixed rhythm

generate_melody(root="C", scale="major", bars=4, contour="arch")

Ascending pentatonic build-up

generate_melody(root="A", scale="pentatonic_minor", bars=4, contour="ascending", rhythm="eighth")

Sparse ambient intro

generate_melody(root="D", scale="dorian", bars=8, contour="wave", rhythm="sparse", rest_probability=0.4)

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
scaleNomajor
octaveNo
rhythmNomixed
contourNoarch
velocityNo
start_beatNo
unit_indexNo
track_indexNo
rest_probabilityNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description explains algorithm steps but omits critical behavioral details such as whether the tool overwrites existing notes on the target track, idempotency, or required permissions. Agent cannot assess side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with summary, parameter breakdown, algorithm steps, and examples. Front-loaded with purpose. Slightly verbose in the algorithm section but each part is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Explains parameters, algorithm, and expected output. Lacks clarity on whether melody is appended or replaces existing notes, and prerequisites (e.g., must have a valid track). Output schema exists but description only lists returned fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero description coverage, but the description fully explains all 11 parameters with musical context (e.g., contour shapes, rhythm styles), algorithm details, and three examples. Adds high value beyond schema titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Generate a melodic line from a scale using contour-guided random selection.' Differentiates from sibling melody tools by emphasizing no chord progression needed and specific contour/rhythm parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'no chord progression needed' and provides musical character for each contour/rhythm option. However, lacks explicit comparison to alternatives like create_melody or create_melody_from_progression, and does not specify when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_audio_file_infoA
Read-only

Get metadata about the audio file referenced by an audio region.

Returns file name, start/end time in seconds, and sample loading state. Useful for inspecting audio regions before processing.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index.

Returns audio file info, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds the list of returned fields and states it returns 'error' on failure, but lacks deeper behavioral details like error conditions or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, starting with the purpose, then return fields, then parameter explanations. No unnecessary words, though the parameter descriptions are embedded in prose rather than structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity and presence of an output schema, the description adequately covers parameters, return values, and basic usage. Lacks detail on error handling but sufficient for a simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining all three parameters (unit_index, track_index, region_index) with clear definitions, adding significant meaning beyond the bare integer types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get metadata about the audio file referenced by an audio region' and lists specific return fields (file name, start/end time, sample loading state), distinguishing it from sibling tools like get_region_info or get_sample_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Useful for inspecting audio regions before processing,' providing some context but no explicit guidance on when to use this tool over alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_automation_valueA
Read-only

Get the automation value at a specific position on a value (automation) track.

Resolves the automation curve value at the given position, accounting for interpolation, region loops, and multiple overlapping regions.

unit_index: AU index. track_index: Value (automation) track index within the AU. position_beats: Position in beats (float).

Returns the normalized value (0.0-1.0), or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds value by explaining that it resolves the automation curve, accounting for interpolation, region loops, and multiple overlapping regions. It also states the normalized value range (0.0-1.0). This goes beyond the annotations to clarify behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear first sentence stating the purpose, a second paragraph adding behavioral detail, and a third paragraph listing parameters. It is front-loaded and fairly efficient, though the parameter list could be integrated into a bullet format for even easier scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only get tool with annotations and an output schema, the description covers the essential behavior: resolving the curve, handling interpolation/loops/overlaps, and returning a normalized value. It could mention what happens if the position is out of bounds or the track doesn't exist, but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description bears the full burden. It briefly explains each parameter: 'unit_index: AU index', 'track_index: Value (automation) track index within the AU', 'position_beats: Position in beats (float)'. This adds meaning beyond the schema's names and types, though could include valid ranges or units.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'get' and the resource 'automation value at a specific position on a value (automation) track'. It explains that it resolves the curve accounting for interpolation, loops, and overlapping regions. This distinguishes it from sibling tools like list_automation_events (which lists events) or set_automation (which writes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for reading automation values at a point, but it does not explicitly state when to use this tool versus alternatives like list_automation_events or other get tools. No when-not-to-use guidance or comparisons are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_bar_intervalA
Read-only

Get the start and end PPQN of the bar containing the given position.

Useful for snapping regions, clips, and events to bar boundaries.

position_ppqn: Position in PPQN.

Returns bar_start (ppqn), bar_end (ppqn), bar_length (ppqn), and time signature.

ParametersJSON Schema
NameRequiredDescriptionDefault
position_ppqnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so the description's role is to add behavioral detail. It states the return values ('bar_start, bar_end, bar_length, and time signature'), which goes beyond the annotation. It does not mention any side effects or contradictions. The description aligns with the read-only nature and adds transparency about the output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and well-structured: first sentence states the core function, second gives usage context, third details parameter and return. It is front-loaded with the most important information and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with an output schema, the description covers all necessary aspects: purpose, usage, parameter explanation, and return values. The tool's complexity is low, and the description provides sufficient context for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'position_ppqn' is explained as 'Position in PPQN', which adds minimal meaning beyond the parameter name. The schema has 0% description coverage, so the description should provide more context, such as expected range or format. Without that, the agent must infer what PPQN values are valid. The description adds little value here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the start and end PPQN of the bar containing the given position.' This is a specific verb-resource combination. It also mentions a use case ('snapping regions, clips, and events to bar boundaries'), which differentiates it from sibling tools like mcp_opendaw_get_tempo_at or mcp_opendaw_get_region_info that also provide positional info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly suggests when to use the tool: 'Useful for snapping regions, clips, and events to bar boundaries.' This provides clear context for usage. However, it does not explicitly state when not to use it or mention alternative tools, which would have warranted a 5. The usage guidance is implied rather than exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_device_chain_detailA
Read-only

Get detailed info about all devices on an AU — instrument, audio effects, MIDI effects.

One call to inspect the full device chain: instrument name/type, all effects with labels, enabled state, minimized state, and parameter counts.

unit_index: AU index.

Returns instrument info, audio_effect array, midi_effect array.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description's read-only nature is consistent. It adds behavioral context: it's a single call that returns arrays for instrument, audio effects, and MIDI effects. No additional disclosures about performance, errors, or edge cases are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: four short sentences that front-load the purpose, detail the output, explain the parameter, and state the return structure. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description does not need to detail return values exhaustively. It lists the key components (instrument info, audio_effect array, midi_effect array) and the attributes per effect. The sole parameter is fully explained, making the tool description self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for parameters, so the description carries the full burden. It explains that 'unit_index' is the AU index, adding meaning beyond the schema's 'Unit Index' title. This helps the agent understand what value to provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves detailed info about all devices on an AU, covering instrument, audio effects, and MIDI effects. It lists specific returned fields (labels, enabled state, minimized state, parameter counts), distinguishing it from siblings like get_effect_chain or get_midi_effect_chain that focus on a subset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it—when you need the full device chain in one call. It doesn't explicitly mention alternatives or when not to use it, but the context is clear. Siblings like get_effect_chain exist, but no exclusionary guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_effect_chainA
Read-only

Get the full effect chain for an audio unit.

unit_index: Audio unit index.

Returns ordered list of effects with their type, enabled state, and index.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral detail about the return structure, which complements the readOnlyHint annotation. No contradictions, and the description clarifies what the read operation retrieves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each serving a purpose: first defines the action, second details the return format. No superfluous text, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with an output schema, the description is adequate but misses details like index base (0-based?), validity conditions, or error cases. Could be more precise.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description repeats the parameter name with minimal extra meaning ('Audio unit index'), adding little beyond the schema's title. With 0% schema description coverage, the description should provide more context, such as indexing convention or range.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full effect chain for an audio unit, and specifies the return format as an ordered list of effects with type, enabled state, and index. This distinguishes it from sibling tools like list_effects or get_effect_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this versus similar tools like list_effects or get_effect_state. The description implies its purpose but does not compare or exclude alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_effect_stateA
Read-only

Get full state of an effect: enabled, minimized, sidechain, all parameters.

More detailed than list_effect_parameters — includes enabled/bypass state, minimized state, sidechain connection, and full parameter dump.

unit_index: Audio unit index. effect_index: Effect position in the chain (0-based).

Returns complete effect state snapshot.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns a 'complete effect state snapshot' including enabled/bypass, minimized, sidechain, and parameters. This adds context beyond the readOnlyHint annotation, but does not reveal any potential performance or rate-limiting implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences summarizing purpose and differentiation, plus logical parameter explanations. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description accurately summarizes the return without detail. It also fully documents the parameters and provides sibling differentiation, making the tool self-contained for selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains both parameters ('unit_index' and 'effect_index') with concise, meaningful definitions. Since the schema provides no descriptions (0% coverage), the description fully compensates by clarifying the index meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the 'full state of an effect' and lists specific components (enabled, minimized, sidechain, all parameters). It also explicitly differentiates from the sibling tool 'list_effect_parameters' by stating it is more detailed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool over its sibling (when more detail is needed than list_effect_parameters). However, it does not mention when not to use it or provide alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_engine_statusA
Read-only

Get real-time engine status: playing state, position, BPM, CPU load, recording state.

Returns: is_playing: bool position_beats: current playback position in beats bpm: current BPM cpu_load: CPU load percentage (0-1) is_recording: bool is_counting_in: bool count_in_beats_remaining: beats left in count-in playback_timestamp: playback timestamp in beats marker: current marker [uuid, index] or null engine_started: whether engine is initialized

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint: true. The description adds value by detailing the return fields and indicating real-time nature. No contradictory or missing behavioral information for a read-only status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a brief header and a structured list of return fields. Every sentence is useful, front-loaded, and no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and presence of output schema, the description fully enumerates all return fields with types and meanings. Complete for an agent to understand the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so no need for additional semantics. Baseline score of 4 applies as per instructions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get real-time engine status' and lists specific fields (playing state, position, BPM, CPU load, recording state). This distinguishes it from other get tools like get_track_info or get_project_info, which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While no explicit when/when-not guidance is given, the tool's purpose and name make it obvious it's for querying engine status. Among siblings, only this tool provides engine_status, so usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_full_project_stateA
Read-only

Get a complete snapshot of the project — all AUs, tracks, regions, effects, mixer state.

One call to inspect the entire project structure. Useful for agents to understand the current state before making changes.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation (true) already signals safety. The description adds value by specifying the scope of data returned ('complete snapshot...all AUs, tracks, regions, effects, mixer state'), which goes beyond the annotation. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the key action and resource. The second sentence provides usage guidance. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description need not detail return structure. It adequately covers the tool's purpose and use case, leaving nothing essential unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters and schema coverage is 100%, so the description does not need to explain param details. The baseline is 4 for zero-param tools, and the description correctly states the tool returns a complete snapshot without requiring inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and clearly defines the resource ('complete snapshot of the project') while listing major components (AUs, tracks, regions, effects, mixer state). This distinguishes it from sibling tools that retrieve partial state (e.g., get_track_info, get_effect_state).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Useful for agents to understand the current state before making changes.' This provides context for its use. However, it does not explicitly list when not to use it or offer direct comparison to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_midi_effect_chainA
Read-only

Get the MIDI effect chain for an audio unit.

unit_index: Audio unit index. Returns ordered list of MIDI effects with type, enabled state, and index.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, confirming the tool is read-only. The description adds value by detailing the output: 'ordered list of MIDI effects with type, enabled state, and index', which goes beyond the structured annotation. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences for purpose and a single line for the parameter. Every word is necessary, no redundancy, and it is front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and an output schema exists. The description covers the return content and parameter meaning. It lacks notes on edge cases (empty chain, invalid index), but given the output schema, it is sufficiently complete for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description explains 'unit_index: Audio unit index.' This adds essential context beyond the schema's type-only definition, effectively compensating for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', the resource 'MIDI effect chain', and the context 'for an audio unit'. It distinguishes from siblings like 'get_effect_chain' by specifying 'MIDI', making the purpose precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly guide when to use this tool versus alternatives such as 'list_midi_effects' or 'get_effect_chain'. While the name and context imply usage for a specific audio unit's MIDI effects, there is no when-not or comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_mixer_stateA
Read-only

Get the full mixer state — all audio units with volume, panning, mute, solo, and type.

Returns a list of channel strips with their current values. Useful for inspecting the mix balance and routing at a glance.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description aligns with the readOnlyHint annotation, confirming a read-only operation. It adds that the result is a list of channel strips with current values, providing behavioral context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no filler. The key action and result are front-loaded, followed by a brief use case. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema that likely defines the return format, the description adequately covers what the tool does, its return content, and typical use case. It is complete for safe inspection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description does not need to add parameter details. The schema coverage is 100%, so baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it retrieves the full mixer state, listing specific attributes (volume, panning, mute, solo, type) and the return format (list of channel strips). This clearly distinguishes it from sibling tools like get_track_info or list_tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It suggests use for inspecting mix balance and routing, which implies the appropriate context. However, it does not explicitly state when not to use it or mention alternative tools for detailed track inspection, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_neuralamp_modelA
Read-only

Get the NeuralAmp (Tone3000) model JSON for a NeuralAmp effect.

Returns the full NAM model JSON string, or an error if the effect is not a NeuralAmp or has no model loaded.

unit_index: AU index. effect_index: Effect index in the audio effect chain.

Returns model_json (string) or empty if no model loaded.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation readOnlyHint=true already indicates read-only. The description adds that it returns an error if the effect is not a NeuralAmp or has no model loaded, and returns empty if no model loaded, providing useful behavioral details beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: purpose, return behavior, parameter definitions. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with two parameters, and the description covers the return value (string or empty) and error cases. With output schema present, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), but the description briefly defines each parameter ('unit_index: AU index', 'effect_index: Effect index'), adding meaning beyond the bare names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets the NeuralAmp model JSON for a specific effect, using a specific verb and resource. It distinguishes from the sibling tool 'set_neuralamp_model' which modifies the model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving model data, but does not explicitly state when to use this tool versus alternatives. It does mention error conditions (not a NeuralAmp, no model loaded) which provides some context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_note_rangeA
Read-only

Get the pitch range and max duration of notes in a note region.

Returns min pitch, max pitch, and longest note duration — useful for determining the vocal/instrument range and planning transpose operations.

unit_index: AU index. track_index: Note track index within the AU. region_index: Note region index.

Returns min_pitch, max_pitch, max_duration_beats, note_count, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by listing specific return fields (min_pitch, max_pitch, max_duration_beats, note_count) and error possibility, confirming no destructive behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences plus parameter definitions) with a clear structure: action, returns, then parameter list. No redundant information; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (3 simple parameters, an existing output schema hinted by 'Returns'), the description covers the purpose, return values, and parameter meanings completely. The mention of 'or error' handles edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by providing a brief explanation for each of the 3 parameters: unit_index, track_index, region_index. This adds meaning beyond the schema's type-only definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets pitch range and max duration of notes in a note region, specifying return values (min pitch, max pitch, longest note duration) and use cases. It distinguishes from siblings by focusing on range rather than listing all notes or statistics, but does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives context for use: 'useful for determining the vocal/instrument range and planning transpose operations.' However, it does not specify when not to use this tool versus similar ones like list_notes or note_stats, nor does it mention prerequisites or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_piano_modeA
Read-only

Get piano roll view settings.

Returns keyboard type (88/76/61/49), time range, note scale, note labels, transpose.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds that it returns specific fields but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the verb and resource, and efficiently lists what is returned. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description fully explains the tool's purpose and return values. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is effectively 100%. The description does not need to add parameter meaning. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves piano roll view settings and enumerates the returned fields (keyboard type, time range, note scale, note labels, transpose). It distinguishes itself from sibling set_piano_* tools by being a getter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when current piano roll settings are needed, but does not explicitly state when to use versus alternatives or provide any exclusion criteria. Given the presence of set_piano_* siblings, the getter role is implied but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_project_durationA
Read-only

Get the total project duration — the end position of the last region across all tracks.

Returns the duration in beats and seconds, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as readOnlyHint=true. The description adds that the tool returns duration in beats and seconds or an error, but does not disclose additional behavioral aspects like side effects or cost. Given annotations, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the core purpose and then detail the return format. Every word is necessary, earning a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with an output schema and annotations, the description is quite complete. It explains what the duration represents and what units are returned. Could mention edge cases (e.g., no regions) but is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and schema_description_coverage is 100%. The description has no need to explain parameters. Baseline score of 3 is correct as no additional meaning is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the total project duration — the end position of the last region across all tracks.' It provides a specific verb (Get) and resource (total project duration), and distinguishes from sibling tools like 'get_project_info' by focusing solely on duration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (when total duration is needed) but does not explicitly state usage context or list alternatives. With many sibling 'get_' tools, explicit guidance would improve clarity, but the purpose is self-explanatory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_project_infoA
Read-only

Get a quick project overview: BPM, time signature, track/AU/effect counts, total duration.

Single-call summary — lighter than get_project_state (no per-track detail).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already declares this as a read-only operation. The description adds minimal behavioral context beyond confirming it's a 'quick overview'. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The essential information is front-loaded and presented clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description appropriately focuses on the input and behavior. It mentions the key data fields returned, which is comprehensive for a project info tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100% by default. The description does not need to add parameter information; the baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Explicitly states it provides a quick project overview including BPM, time signature, track/AU/effect counts, and total duration. It also distinguishes from get_project_state by noting it's lighter and lacks per-track detail, which helps differentiate among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly indicates when to use this tool (for a quick overview) and compares it to get_project_state, providing a clear alternative. Does not explicitly state when not to use, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_project_metadataA
Read-only

Get project metadata: creation date, BPM, time signature, AU count, track count.

Quick overview of the project state in one call.

Returns created (ISO date), bpm, time_signature, audio_unit_count, total_track_count.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds the specific return fields (created, bpm, time_signature, etc.), which is useful context beyond annotations. No additional behavioral traits (e.g., performance, side effects) are disclosed, but given the annotation coverage, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: three short sentences that front-load the purpose and return fields. No wasted words, though there is slight redundancy between the first and third sentences. Still, it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple metadata fetch with zero parameters and an output schema present, the description provides all necessary context: what it returns and that it's a quick overview. No gaps given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description doesn't need to add parameter info. Context notes schema coverage is 100% (trivially) and baseline for 0 params is 4. The description does not add anything beyond what the schema provides, but that's acceptable here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets project metadata and lists specific fields (creation date, BPM, time signature, AU count, track count). It distinguishes itself as a 'quick overview' but does not explicitly differentiate from siblings like get_project_info or get_full_project_state, thus not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a 'quick overview in one call,' but provides no explicit when-to-use vs alternatives like get_full_project_state or get_project_info. No exclusions or conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_project_stateA
Read-only

Get full project state: BPM, sample rate, playing status, track list, effects chain.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the read-only nature is known. Description adds value by listing return contents, but does not disclose additional behavioral traits (e.g., cost, side effects).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words; clearly front-loaded with verb and resource; each listed component is relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and existence of output schema, description provides reasonable coverage of what the state includes. Could mention more aspects, but sufficient for a high-level getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage is trivially 100%. Baseline of 4 for zero parameters applies; description adds no extra parameter info, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get' and resource 'full project state', listing specific components (BPM, sample rate, playing status, track list, effects chain). It distinguishes from sibling get_* tools by emphasizing comprehensive snapshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like get_track_info or get_mixer_state. The description does not mention context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_region_infoA
Read-only

Get detailed info about a single region — position, duration, loop, mute, content.

unit_index: AU index. track_index: Track index within the AU. region_index: Region index.

Returns region metadata including type-specific info (notes count, audio file, automation events).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation 'readOnlyHint: true' is consistent with the description. The description adds value by stating that the tool returns metadata and type-specific info (notes count, audio file, automation events). This provides useful behavioral context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for the purpose, then a brief parameter list. It is front-loaded with the key information and contains no redundant or vague statements.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description appropriately focuses on input parameters and high-level return info. It mentions type-specific details, which is sufficient for an agent to understand what the tool provides. Could potentially mention that it returns detailed region metadata, but overall it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no descriptions (0% coverage), so the description compensates by explaining each parameter (e.g., 'track_index: Track index within the AU'). This adds meaning beyond the schema's titles, helping an agent correctly specify the target region.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get detailed info about a single region') and lists the specific attributes returned (position, duration, loop, mute, content). It distinguishes itself from sibling tools like 'get_track_info' and 'list_notes' by focusing on a single region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains each parameter's role (unit_index, track_index, region_index), providing context on how to use the tool. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., listing all regions). The purpose is clear enough that an agent can infer usage for retrieving specific region info.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_region_play_modeA
Read-only

Get the play mode of an audio region — stretch type, playback rate, cents, transient mode.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index.

Returns play mode details, or info if no stretch mode (plain playback).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only. The description adds that it returns play mode details or info for plain playback, which provides some behavioral context beyond the annotation. However, it lacks details on potential error conditions or index conventions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus parameter annotations—no filler, front-loaded with the main purpose. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description sufficiently covers the tool's function: it identifies the resource, explains parameters, and notes the fallback case. Minor missing detail: index starting point (0 or 1) is not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides basic parameter explanations (unit_index: AU index, etc.), adding meaning beyond bare property names. However, this is minimal and could be more detailed (e.g., index ranges or valid values).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the play mode of an audio region, listing specific attributes (stretch type, playback rate, cents, transient mode). This verb+resource pattern distinguishes it from sibling tools like get_region_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., get_region_info or other region-related tools). No prerequisites or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_sample_infoA
Read-only

Get detailed info about an audio sample by UUID.

Uses the SampleManager to fetch metadata about audio files registered in the project. Returns sample rate, channels, frames, and loading state.

sample_uuid: UUID of the audio sample (from list_samples).

Returns sample metadata, or error if not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
sample_uuidYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds context: returns metadata or error if not found, using SampleManager. No contradictions; clarifies behavior beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with no wasted sentences. Each sentence adds value: purpose, implementation detail, parameter hint, and return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with one parameter and output schema, the description covers purpose, parameter source, return fields, and error case. It is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains sample_uuid is a UUID from list_samples, adding meaningful context beyond the schema's type and title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get detailed info about an audio sample by UUID' with specific return fields (sample rate, channels, frames, loading state), distinguishing it from siblings like get_audio_file_info by focusing on sample metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the sample_uuid comes from list_samples, guiding the user on parameter source, but does not explicitly discuss when to use this tool versus alternatives or provide exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_script_device_codeA
Read-only

Read the current user JavaScript code from a scriptable device.

Returns the full code string, header line, and code length.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
device_typeYes
device_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds value by specifying the returned data structure (code string, header line, code length). No contradictions, and no additional side effects or requirements are disclosed, but the safety profile is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at two sentences, with no filler or redundancy. Every sentence adds value: one states the action, the other the return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations are present, the description is largely complete. It covers the tool's purpose and return format. However, it does not explain what constitutes a 'scriptable device' or how to interpret the parameters, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not explain any of the three parameters (device_type, unit_index, device_index). Although parameter names are somewhat self-explanatory, the description fails to compensate for the lack of schema descriptions, leaving an agent to guess their exact semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads user JavaScript code from a scriptable device, with a specific verb and resource. It also lists the return fields (full code string, header, code length), distinguishing it from the sibling set_script_device_code tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reading code, and the sibling set_script_device_code is the obvious alternative for writing. However, it lacks explicit 'when to use' or 'when not to use' guidance, and no prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_signature_eventsA
Read-only

List all time signature change events in the project.

Returns the base signature (4/4 by default) and all signature change events with their accumulated PPQN positions, bar counts, and nominator/denominator.

Returns base_signature, events array with index/position/bars/nominator/denominator.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, and the description confirms read-only behavior. It adds value by specifying return structure, including default base signature, which is useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear first sentence and additional detail on return format. Slightly verbose with the second paragraph, but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema, the description fully describes the tool's return structure, including default base signature and event field details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, schema coverage is 100%, and the description correctly omits parameter details. No additional meaning is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all time signature change events and mentions return fields. However, it does not differentiate from the sibling 'mcp_opendaw_list_signature_changes', which may have similar functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'mcp_opendaw_list_signature_changes' or 'mcp_opendaw_change_base_signature'. No context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_studio_settingsA
Read-only

Get all studio preferences/settings (engine, visibility, editing, debug, storage, time-display, pointer).

Returns all settings categories with current values.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds limited behavioral context beyond stating it returns all categories and values. No mention of side effects, auth, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with categories, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter get-all tool with output schema and readOnlyHint annotation, the description covers the essential purpose and return scope completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline is 4. Description adds no parameter info, but the category list in description provides context on what the function returns, which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get' and resource 'all studio preferences/settings', with explicit category list distinguishing it from modify tools like set_studio_setting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly implies use for reading all settings, but lacks explicit when-not-to-use or comparison with the sibling set_studio_setting. Agent can infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_tempo_atA
Read-only

Get the BPM at a specific position, accounting for tempo automation.

position_beats: Position in beats (float).

Returns BPM at that position, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it 'account[s] for tempo automation' and returns 'BPM at that position, or error,' which provides some behavioral context beyond annotations but does not cover edge cases or state dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (two sentences), front-loads the core purpose, and every sentence adds necessary information without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one parameter and an output schema, the description covers the essential input and output. It could briefly mention position validity (e.g., within project range) but is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the parameter description ('position_beats: Position in beats (float)') meaningfully adds units and type information that the schema lacks, helping the agent understand the expected input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action ('Get the BPM at a specific position') and the resource ('BPM'), and distinguishes itself by accounting for tempo automation, which differentiates it from sibling tools like mcp_opendaw_get_project_info or mcp_opendaw_list_tempo_changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you need BPM at a specific position considering automation) but does not explicitly mention alternatives or when not to use it. The context is adequate but lacks clear exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_track_infoA
Read-only

Get detailed info about a track — type, regions, clips, enabled state, target.

unit_index: AU index. track_index: Track index within the AU.

Returns track metadata and region/clip counts.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral context (e.g., error handling, side effects), but does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two short sentences plus parameter clarifications. It's front-loaded with the main purpose and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description is not required to detail return values, but it still mentions 'Returns track metadata and region/clip counts.' For a simple getter with two parameters, this is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explicitly explains both parameters: 'unit_index: AU index. track_index: Track index within the AU.' This adds essential meaning beyond the schema's type and title fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get detailed info about a track' and lists the info types (type, regions, clips, enabled state, target). This distinguishes it from sibling 'get' tools like get_region_info or get_audio_file_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No mention of when to use this tool vs alternatives, no prerequisites or exclusions provided. The description only states what it does without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_get_unit_freeze_statusA
Read-only

Check if an audio unit is frozen and whether it can be frozen.

Freeze status indicates the AU's output has been pre-rendered to audio, freeing CPU. An AU with sidechain dependents cannot be frozen.

unit_index: AU index.

Returns frozen (bool), can_freeze (bool), has_sidechain_dependents (bool).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, but the description adds context about freeze meaning pre-rendered audio and sidechain restrictions. This provides behavioral depth beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is four sentences, front-loaded with purpose, and contains no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (inferred from return description), the tool fully describes what it returns and the meaning of each boolean field. It also explains why can_freeze might be false. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It briefly describes unit_index as 'AU index', which is minimal but sufficient given the simple integer parameter. Could add more context on finding the index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if an audio unit is frozen and whether it can be frozen, distinguishing it from sibling like freeze_audiounit. It also explains the freeze concept and restriction about sidechain dependents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states the tool checks freeze status and can_freeze, implying it should be used before freezing. However, it does not explicitly state when not to use it or compare to other get_* status tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_groove_transferA

Transfer groove (timing + velocity feel) from a source region to a destination region.

Extracts the groove template from source notes: for each grid position within the groove cycle (groove_length beats), records the average timing offset from the grid and the average velocity ratio. Then applies this template to destination notes — shifting their timing and scaling velocity to match the source feel.

This is NOT copying notes — it transfers the feel. A 1-bar drum groove can be applied to a 4-bar programmed pattern. The groove cycles every groove_length beats.

source_unit_index: AU index of the groove source (e.g. a drum track). source_track_index: Note track index on the source AU. source_region_index: Region index on source (-1 = first). dest_unit_index: AU index of destination (-1 = same as source). dest_track_index: Note track index on destination AU (-1 = same as source track). dest_region_index: Region index on destination (-1 = all regions on track). groove_length: Groove cycle length in beats (4 = 1 bar of 4/4, 3 = waltz, 2 = half-bar). timing_strength: 0-1, how much timing offset to apply (0 = no change, 1 = full source groove). velocity_strength: 0-1, how much velocity pattern to apply (0 = no change, 1 = full source groove). grid: Grid for computing timing offsets — "16th" or "8th".

Returns groove template stats and per-region modification counts.

ParametersJSON Schema
NameRequiredDescriptionDefault
gridNo16th
groove_lengthNo
dest_unit_indexNo
timing_strengthNo
dest_track_indexNo
dest_region_indexNo
source_unit_indexYes
velocity_strengthNo
source_track_indexYes
source_region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the extraction and application process: 'Extracts the groove template... then applies this template to destination notes — shifting their timing and scaling velocity.' However, it does not specify whether the operation is destructive or reversible, nor does it mention the effect on the source region. The mention of return values (groove template stats) adds some transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a high-level summary, then detailing the process, and finally listing parameter explanations. While it is somewhat lengthy, every sentence adds value. A slightly more compact format (e.g., table for parameters) could improve conciseness, but it remains clear and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 10 parameters and the presence of an output schema, the description covers all parameters thoroughly and explains the non-obvious concept of groove cycle. It mentions return values. However, it lacks discussion of prerequisites (e.g., must have notes in source region) and edge cases (e.g., groove_length exceeding region length), leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description fully compensates by providing detailed explanations for all 10 parameters. It includes concrete examples (groove_length: '4 = 1 bar of 4/4, 3 = waltz, 2 = half-bar'), ranges (timing_strength: 0-1), and allowed values (grid: '16th' or '8th'). This adds significant meaning beyond the schema's titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Transfer groove (timing + velocity feel) from a source region to a destination region.' It distinguishes this from copying notes by explicitly stating 'This is NOT copying notes — it transfers the *feel*.' The example of applying a 1-bar drum groove to a 4-bar pattern further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use this tool by explaining the concept of groove transfer and contrasting it with note copying. It gives an example scenario (1-bar groove to 4-bar pattern). However, it does not explicitly list alternatives or state when not to use it relative to sibling tools like apply_swing or humanize_notes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_humanize_notesA

Add human-like variation to existing notes — velocity, timing, duration, and swing.

Makes programmed MIDI feel less robotic by applying small random deviations. Works on all notes in the specified track(s)/unit(s), or globally with unit_index=-1.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). velocity_amount: Velocity deviation depth 0-1 (0.15 = ±15% of current velocity). Example: 0.05 = subtle, 0.15 = natural, 0.25 = loose. timing_amount: Timing offset depth in beats 0-1 (0.15 = up to ±15% of a 16th note = ±3.6 ticks). Example: 0.05 = tight, 0.15 = natural groove, 0.30 = sloppy. duration_amount: Duration deviation depth 0-1 (0.10 = ±10% of current duration). swing: Swing amount 0-1 (0 = straight, 0.5 = light swing, 1.0 = full triplet feel). Shifts every other 16th note later by swing * 1/3 of a 16th. seed: Random seed for reproducibility (same seed = same humanization).

Returns per-track note counts and total notes humanized.

Example: humanize_notes(unit_index=0, velocity_amount=0.15, timing_amount=0.12, swing=0.35)

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo
swingNo
unit_indexNo
track_indexNo
timing_amountNo
duration_amountNo
velocity_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that it modifies notes non-destructively (applies random deviations), and specifies the return value ('per-track note counts and total notes humanized'). It does not mention prerequisites or potential side effects, but the behavioral description is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line summary, then general behavior, then parameter details. It is front-loaded with purpose. While lengthy, the detail is necessary for parameter clarity; no superfluous sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, no annotations, but an output schema exists), the description covers all necessary aspects: purpose, parameter semantics, behavior, and return value. It is complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates with detailed explanations for all 7 parameters, including value ranges, examples (e.g., '0.05 = subtle, 0.15 = natural'), and behavioral impact (e.g., 'Shifts every other 16th note later by swing * 1/3 of a 16th'). This exceeds the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Add human-like variation to existing notes — velocity, timing, duration, and swing.' It uses a specific verb ('Add') and resource ('notes') and distinguishes from siblings like humanize_pitch by enumerating the dimensions of variation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the scope ('all notes in specified track(s)/unit(s), or globally with unit_index=-1') but does not explicitly guide when to use this tool over alternatives like apply_swing or humanize_pitch. It lacks when-not and alternative comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_humanize_pitchA

Add micro-detune (cents) to notes — intonation humanization.

Real instruments and vocals never play perfectly in tune — there's always slight pitch drift. humanize_notes handles velocity/timing/duration, but pitch stays quantized. This tool adds per-note cent offsets to simulate natural intonation imperfections.

Useful for:

  • String sections that sound too perfect

  • Vocal MIDI parts that need warmth

  • Brass arrangements needing intonation character

  • Any programmed MIDI that feels sterile

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). cents_depth: Maximum deviation in cents (0-50, default 5 = +/-5 cents). 3 = subtle warmth, 5 = natural, 10 = loose, 20 = detuned, 50 = chaotic. bias: Directional bias in cents (-20 to +20, default 0 = centered). Positive = sharp tendency, negative = flat tendency. Useful for simulating ensembles that drift sharp. seed: Random seed for reproducibility (same seed = same detune pattern).

Returns per-track note counts, total notes detuned, cent range.

Example:

Subtle string warmth

humanize_pitch(unit_index=0, track_index=2, cents_depth=4, seed=7)

Detuned brass

humanize_pitch(unit_index=0, track_index=3, cents_depth=12, bias=-3)

ParametersJSON Schema
NameRequiredDescriptionDefault
biasNo
seedNo
unit_indexNo
cents_depthNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description explains the operation (adds per-note cent offsets), return values (per-track counts, total detuned, cent range), and parameter effects. Lacks explicit statement on reversibility or side effects, but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Contains two paragraphs plus a bullet list and an example. Every sentence adds value, no fluff. Front-loaded with purpose and usage, then parameter details, then example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a tool with 6 parameters, no annotations, and an output schema. Covers purpose, usage guidelines, parameter semantics, and return value. Includes examples and distinguishes from sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description fully documents each parameter: unit_index, track_index, region_index with -1 meanings; cents_depth with qualitative examples; bias direction; seed for reproducibility. Adds significant meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it adds micro-detune (cents) to notes for intonation humanization. Distinguishes from sibling humanize_notes which handles velocity/timing/duration but not pitch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly contrasts with humanize_notes and provides specific use cases (string sections, vocal MIDI, brass, sterile MIDI). Tells when to use and when not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_identify_chordsA

Identify chords from existing notes in a region — harmonic analysis / reverse engineering.

Reads all notes from a region, groups them by temporal overlap (notes sounding together within group_tolerance beats), and for each group identifies the chord by matching the pitch-class set against known chord types (maj, min, 7, maj7, min7, sus2, sus4, add9, dim, aug).

Useful for: understanding imported MIDI, analyzing AI-generated progressions, reverse-engineering a track's harmony, or verifying that generated chords match the intended progression.

unit_index: AU index to analyze. track_index: Note track index to analyze. region_index: Region index (-1 = first region). group_tolerance: Beats of tolerance for grouping notes as simultaneous (default 0.25 = notes within a 16th note of each other are grouped together). min_notes: Minimum notes to attempt chord identification (default 3 = triad minimum).

Returns list of detected chords with time position, root, type, and confidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
min_notesNo
unit_indexYes
track_indexYes
region_indexNo
group_toleranceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description adequately explains the algorithm: reads notes, groups by temporal overlap, matches pitch-class sets. It informs that the tool returns chord lists with time, root, type, and confidence, and describes parameter effects (e.g., group_tolerance, min_notes). Slight omission of project-state implications (read-only).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary line, process explanation, use cases, and parameter list. It is relatively concise given the amount of information, though slightly verbose in the algorithm section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity, 5 parameters, no schema descriptions, and no annotations, the description covers input explanation, process, and output. It lacks edge-case handling (e.g., empty region, identical chords), but provides sufficient context for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 5 parameters are described in the description with clear explanations beyond the schema's type/default: unit_index and track_index as indices, region_index with -1 meaning first, group_tolerance explained with musical context (16th note), min_notes with a triad example. This compensates fully for 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with 'Identify chords from existing notes in a region — harmonic analysis / reverse engineering,' providing a specific verb and resource. It clearly differentiates from sibling analysis tools by focusing on chord identification from note regions, explaining the grouping and matching process.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Lists clear use cases: understanding imported MIDI, analyzing AI-generated progressions, reverse-engineering harmony, verifying chords. While it doesn't explicitly state when not to use it or name alternatives, the contexts are specific and helpful for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_import_audio_to_tracksA

Import an audio file into the DAW, optionally split into stems on separate tracks.

One-call pipeline: audio file → (optional stem separation) → create instrument tracks → load each stem → place on tracks at start_beat. This is the Suno-to-DAW bridge: generate a track with Suno, download it, then import with stem splitting for mixing and mastering.

Without mode: loads the whole file as one track (simple import). With mode: splits into stems, creates one track per stem, loads and places each.

file_path: Absolute path to WAV/MP3/FLAC/OGG file on disk. mode: Stem separation mode (empty = no split, single track). Modes: "bs6" (6-stem), "scnet" (4-stem), "ensemble" (max quality), "polarformer" (vocal/instrumental), "drumsep" (drum parts). start_beat: Beat position to place the audio region(s) (default 0). bpm: Tempo for the project (affects beat alignment, default 120).

Returns: track count, per-track info (name, sample_id, duration, stem name), and suggested next steps (apply_genre_mix, render_full).

Examples:

Simple import — one track, no splitting

import_audio_to_tracks("/tmp/suno_track.wav")

Split into 6 stems, each on its own track

import_audio_to_tracks("/tmp/suno_track.wav", mode="bs6")

Vocal/instrumental split at beat 4

import_audio_to_tracks("/tmp/vocal.wav", mode="polarformer", start_beat=4)

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
modeNo
file_pathYes
start_beatNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses behaviors: it creates instrument tracks, loads stems, and describes the pipeline. It mentions side effects like track creation and returns detailed info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with overview, parameter details, return info, and examples. It is slightly verbose but each section adds value. Could be tightened without loss of clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and presence of an output schema, the description covers all necessary aspects: return values (track count, per-track info, suggested next steps) and integration with other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining each parameter (file_path, mode, start_beat, bpm) with details, default values, and mode options. Examples further clarify usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it imports audio files, optionally splits into stems, creates tracks, and places them at start_beat. It uniquely positions itself as a 'Suno-to-DAW bridge', distinguishing it from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on when to use (import audio, optionally with stem separation) and includes examples for different modes. However, it does not explicitly mention when not to use or provide alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_import_dawprojectA

Import a .dawproject file into the current session.

The dawproject format is a ZIP containing project.xml, metadata.xml, and audio samples. This enables loading projects created in Bitwig, Ableton, or other DAWs supporting dawproject.

Args: filename: Path to the .dawproject file to import.

Returns the import result with track and sample counts.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, yet description does not disclose behavioral traits like whether the current session is overwritten, error handling, or file size limits. Minimal transparency beyond the import operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two paragraphs plus Args; purpose is front-loaded. Some extra detail on file format could be trimmed but overall efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Mentions return of track/sample counts (output schema exists), but lacks information on side effects on the session, error conditions, or success criteria. Adequate for a 1-param tool but could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds 'Path to the .dawproject file to import,' providing context beyond the raw schema's type and title. Clearly defines the parameter's role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Import a .dawproject file into the current session,' specifies the file format and compatible DAWs, and distinguishes from related tools like export_dawproject and import_midi.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use when needing to load a dawproject file but lacks explicit guidance on when to use this vs. other import tools (e.g., import_midi). No prerequisites or constraints provided beyond 'current session.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_import_midiA

Import a MIDI file and create note events on a note track.

Parses standard MIDI (.mid) files and creates note regions with all notes. Supports format 0 and 1. Ticks are converted to openDAW PPQN (960/quarter).

file_path: Path to .mid file (absolute or relative to MCP server). unit_index: Audio unit index with a note track (-1 = search all AUs). track_index: Note track index within the AU. offset_beats: Offset in beats to shift all notes (e.g. start at bar 2 = 4.0).

Returns note count and time range.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
unit_indexYes
track_indexYes
offset_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses MIDI format support, PPQN conversion, and return values (note count, time range). However, it does not clarify whether importing overwrites existing notes or appends, nor error behavior on invalid files. Moderate transparency, leaving some behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single paragraph with inline parameter explanations. It front-loads the main purpose and format support. While concise, a more structured layout (e.g., separate sections) could improve readability. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description adequately covers return values and key conversion details. Lacks mention of error handling or edge cases (e.g., invalid file path, unsupported format). Mostly complete for a file import tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must explain parameters. It does so thoroughly: file_path, unit_index (including -1 meaning), track_index, offset_beats (with example). All parameters are clearly defined with practical context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Import a MIDI file and create note events on a note track', specifying verb and resource. Also notes supported MIDI formats. Does not explicitly differentiate from sibling import tools (e.g., mcp_opendaw_import_dawproject) but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides basic context (what it does) and parameter explanations, but no explicit guidance on when to use this tool vs alternatives, such as when to search all AUs (unit_index=-1) or how to locate the track_index. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_import_presetA

Import a preset (base64-encoded binary) as a new audio unit.

Uses PresetDecoder.decode — deserializes the preset into the current project, creating a new AU with all its dependencies (instrument, effects, MIDI effects, tracks, notes).

preset_b64: Base64-encoded preset bytes from export_preset.

Returns the new AU's index, type, and label, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
preset_b64Yes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool deserializes the preset into the current project, creating a new AU with all dependencies, and returns index, type, label, or error. This is transparent about the effect and return value, though it could mention error handling or destructive potential.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main purpose, and includes necessary details without unnecessary words. Each sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (importing a preset with dependencies) and the presence of an output schema, the description covers input, process, and output adequately. No obvious gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds significant meaning by specifying the parameter format (base64-encoded) and its origin (from export_preset). This goes beyond the schema's plain string type, but could include constraints like maximum size.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool imports a base64-encoded preset and creates a new audio unit with all dependencies. This is a specific verb-resource pair that distinguishes it from other import tools like import_midi or import_audio_to_tracks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions preset_b64 comes from export_preset, which provides a clear usage hint. However, it does not explicitly state when not to use this tool or compare to alternatives, leaving some ambiguity for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_insert_restsA

Insert rests at specified beat positions by removing notes.

Deletes notes at given beat positions to create space, syncopation, or breathing room in dense patterns. Unlike thin_notes (which removes by interval/velocity/random strategy), this works positionally — you specify exactly where rests should appear.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) rest_positions: Comma-separated beat positions where rests should be inserted (e.g. "0,1,2,3" = every beat, "1.5,3.5" = offbeats only). tolerance_beats: Tolerance for matching note start to rest position (0.05 = within a 32nd note, 0.25 = within a 16th). mode: Deletion mode — "delete" = remove notes starting at rest positions, "truncate" = shorten notes that overlap rest positions (cut them at the rest point), "shorten" = reduce duration of notes near rest positions by half but don't delete them. shorten_neighbors: If True, also shorten notes immediately before rest positions to create cleaner separation. Only with mode="delete".

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNodelete
unit_indexYes
track_indexYes
region_indexNo
rest_positionsNo0,1,2,3
tolerance_beatsNo
shorten_neighborsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the tool's behavior: it removes notes at specified beat positions, and explains the three deletion modes (delete, truncate, shorten), tolerance, and neighbor shortening. No annotations are provided, so the description carries the full burden. It clearly communicates the destructive nature but does not mention undo behavior or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a brief intro, comparison to a sibling, and a detailed Args section. While comprehensive, it could be slightly more concise; however, it remains readable and front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to explain return values. It adequately covers the tool's behavior, parameter meanings, and mode details. Missing elements like prerequisites (e.g., existence of notes at positions) are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the 'Args' section in the description provides thorough explanations for all 7 parameters, including examples (e.g., '0,1,2,3' for rest_positions) and clarifications (tolerance in musical terms like 'within a 32nd note'). This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Insert rests at specified beat positions by removing notes.' It explains the effect (creating space, syncopation, breathing room) and distinguishes itself from the sibling tool 'thin_notes' by emphasizing positional control rather than interval/velocity/random strategies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with 'thin_notes,' providing a clear alternative and indicating when to use this tool (positional rest insertion). However, it does not mention other potential alternatives like 'delete_note' or conditions when not to use this tool, slightly limiting guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_invert_chord_notesA

Invert a chord at a specific position — move bottom N notes up an octave (or top N down).

A chord inversion (voicing change) rearranges which chord tone is lowest without changing the chord itself. 1st inversion: the 3rd is in the bass. 2nd inversion: the 5th is in the bass. This tool finds notes at a given beat position, groups them as a chord, and moves the bottom N notes up an octave (or top N down).

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index chord_position: Beat position of the chord to invert inversion: Number of notes to invert (1=first inversion, 2=second inversion, 3=third for 7th chords) direction: "up" = move bottom notes up an octave (standard), "down" = move top notes down an octave (drop voicing) Returns: JSON with notes_inverted, original pitches, new pitches, chord root.

ParametersJSON Schema
NameRequiredDescriptionDefault
directionNoup
inversionNo
unit_indexYes
track_indexYes
region_indexYes
chord_positionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the internal process (find notes at beat, group as chord, move notes) and return fields (notes_inverted, original pitches, etc.). Does not mention error conditions but is fairly transparent for a technical tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is structured with a summary line, explanatory paragraph, and parameter list. Slightly long but each part adds value. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, the description covers return values and inputs. Does not specify prerequisites (e.g., chord must exist at position) or error handling, but overall sufficient for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates by listing all parameters with explanations (e.g., inversion=1 first, 2 second, 3 third for 7th chords; direction up=standard, down=drop). Adds value beyond schema defaults and titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inverts chord notes by moving bottom N up or top N down an octave. It explains inversions (1st, 2nd) and distinguishes from siblings like invert_notes and spread_voicing by focusing on chord voicing at a specific beat position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains inversion theory and parameter roles but does not explicitly compare to alternatives like spread_voicing or invert_notes. It implies usage for changing chord voicing without altering the chord itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_invert_notesA

Invert melody around a pitch axis — mirror reflection.

Each note's pitch is reflected around the axis: newPitch = 2*axis - oldPitch. Example: with axis=60 (C4), C4(60)→C4(60), D4(62)→Bb3(58), E4(64)→Ab3(56).

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all regions on the track). axis: Pivot pitch for inversion (default 60 = C4). Notes equidistant from axis on opposite sides swap. Use the first note's pitch for tonal inversion.

Returns count of notes inverted and notes skipped (out of MIDI range).

ParametersJSON Schema
NameRequiredDescriptionDefault
axisNo
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It describes the transformation and return count but does not mention whether the operation is destructive, reversible, or has side effects on the project state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, front-loading the purpose, then the formula, example, parameters, and return values without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers parameters, behavior, and return values well, but omits error conditions, limitations, and prerequisite knowledge (e.g., MIDI note numbers). Since an output schema exists, the return description is not essential but adds value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully explains each parameter: unit_index, track_index, region_index (with special -1 meaning), and axis (default 60, pivot pitch) with usage tips, adding significant meaning beyond schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inverts a melody around a pitch axis via mirror reflection, providing a formula and example that distinguish it from sibling tools like transpose or reverse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use each parameter (unit, track, region, axis) and recommends using the first note's pitch for tonal inversion, but it does not explicitly guide when to choose inversion over alternatives or mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_audio_busesA
Read-only

List all audio buses in the project (primary output + FX buses).

Returns bus index, name, enabled state, and the associated audio unit index.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the readOnlyHint annotation by specifying that it lists both primary output and FX buses and returns bus index, name, enabled state, and associated audio unit index. This provides clear insight into the tool's output and scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the purpose, the second lists the return values. No redundant or wasteful language. Every sentence is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (not shown) and no parameters, the description is complete. It enumerates the main return fields (index, name, enabled state, audio unit index), which is sufficient for an agent to understand the tool's functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter information. The baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all audio buses in the project (primary output + FX buses).' It specifies the verb 'List', the resource 'audio buses', and the scope (project, including primary output and FX buses), effectively differentiating from sibling tools that modify or create buses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives like create_audio_bus or set_bus_enabled. While the context of sibling tools implies it is a read-only listing tool for gaining an overview, no explicit when/when-not guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_audio_regionsA
Read-only

List all audio regions with file name, position, and duration.

unit_index: Audio unit index. track_index: Specific audio track (-1 = all audio tracks).

Returns list of regions with: region_index, track_index, position_beats, duration_seconds, file_name.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. Description confirms listing behavior and adds context about returned fields. No additional behavioral traits (e.g., performance, error handling) are disclosed, but the read-only nature is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise and well-structured: a brief purpose statement, followed by parameter descriptions, then return fields. It is front-loaded and uses clear formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema (2 params) and existence of an output schema, the description covers key aspects: what the tool does, what parameters mean, and what fields are returned. It lacks detail on edge cases or order, but is adequate for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description compensates by explaining both parameters, including the special value -1 for track_index. This adds meaningful context beyond the schema's type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists audio regions with specific fields. It explains parameters and return values, making the purpose evident. However, it does not explicitly differentiate from sibling list tools like list_clips or get_region_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains parameters and the special meaning of track_index=-1 for all tracks. It implies usage for querying audio regions but does not provide when-to-use or when-not-to-use guidance relative to other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_automatable_fieldsA
Read-only

List all automatable parameter fields on an instrument (or specific Playfield sample).

Shows which fields support Pointers.Automation — only these can be automated.

unit_index: Audio unit index containing the instrument. sample_index: For Playfield, which sample slot (-1 = top-level instrument).

Returns field names with current values and whether they're automatable.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
sample_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation indicates readOnlyHint=true, and the description reaffirms a read-only behavior by stating 'List' and 'Shows'. It adds behavioral details such as returning field names, current values, and automatable status, and explains the parameters. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three focused sentences: purpose, key behavior note, and parameter explanations. No unnecessary words, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (as indicated by context signals), the description adequately covers purpose, parameters, and return values (field names, current values, automatable flag). The description is sufficient for an agent to understand and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must provide parameter meaning. It explains unit_index as 'Audio unit index containing the instrument' and sample_index as 'For Playfield, which sample slot (-1 = top-level instrument)', adding clear semantics beyond the schema's type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all automatable parameter fields on an instrument (or specific Playfield sample)' and specifies that it shows fields supporting 'Pointers.Automation'. This differentiates it from sibling tools like list_effect_parameters and list_instrument_params, which likely list all parameters without the automation filter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implies usage for discovering automatable fields before applying automation, but does not provide direct guidance on when not to use it or mention specific sibling tools. The context is moderately clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_automation_eventsA
Read-only

List automation events (ValueEventBox) on a unit's automation tracks.

Finds all Value-type tracks (automation) on the given audio unit and returns their automation points: position (beats), value (0-1), interpolation type.

unit_index: Audio unit index. track_index: Specific automation track (-1 = all automation tracks on the unit).

Returns list of tracks with their automation events.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds context about the read-only operation and output format, but the readOnlyHint annotation already covers the safety profile. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, front-loading the main action, with no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately covers the tool's behavior and parameters. Could mention handling of empty results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds crucial meaning to both parameters (unit_index and track_index), including the special value -1 for track_index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists automation events (ValueEventBox) on a unit's automation tracks, specifying the return values. However, it does not explicitly differentiate from sibling tools like list_automation_events_detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to retrieve automation points) and explains parameter usage but lacks explicit guidance on when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_automation_events_detailA
Read-only

List all automation events on a value track with full detail — position, value, interpolation.

More detailed than list_automation_events — includes interpolation type and curve slope.

unit_index: AU index. track_index: Value (automation) track index.

Returns event list with positions in beats, values, and interpolation details.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation 'readOnlyHint' already marks the tool as read-only. The description adds behavioral context by noting the return includes 'positions in beats' and 'interpolation details'. No contradiction with annotations; it enriches the agent's understanding of what the tool provides beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is about five sentences, front-loading the purpose and key differentiator. It is clear and without fluff. Every sentence serves a purpose, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has an output schema (not shown but present) and read-only annotation, the description covers the purpose, a sibling comparison, parameter meanings, and return structure. It is fairly complete for a list tool with two parameters, though it omits details like ordering or result limits (likely covered by output schema).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions in schema), so the description must compensate. It provides brief explanations: 'unit_index: AU index' and 'track_index: Value (automation) track index'. This adds basic meaning beyond property names but lacks details like valid ranges or format. With 0% coverage, a score of 3 reflects minimal but present compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists automation events on a value track with full detail including position, value, and interpolation. It distinguishes from the sibling 'list_automation_events' by explicitly stating it includes interpolation type and curve slope, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear comparative guideline: 'More detailed than list_automation_events' indicates when to use this tool versus the sibling. It also explains the two required parameters. While it lacks explicit 'when not to use' caveats, the comparative guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_clipsA
Read-only

List clips (session view / clip launcher) on tracks.

Clips live on TrackBox.clips (ClipCollection). Three types:

  • NoteClipBox: MIDI clips (index, duration, mute, label, hue, triggerMode)

  • AudioClipBox: Audio clips (same + file, gain, playMode)

  • ValueClipBox: Automation clips (same + events)

unit_index: Audio unit index. track_index: Track index (-1 = all tracks on the unit).

Returns list of clips with type, index, duration, mute, label, loop.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond the readOnlyHint annotation: it explains clip types, properties returned (type, index, duration, mute, label, loop), and parameter behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: a one-line purpose statement, followed by clip type details, parameter explanations, and return list. Every sentence adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers what the tool does, parameter meanings, and return fields. It is complete for an AI agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only titles with 0% description coverage. The description fully compensates by explaining each parameter: unit_index is 'Audio unit index' and track_index is 'Track index (-1 = all tracks on the unit).' This adds essential meaning for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List clips (session view / clip launcher) on tracks.' It specifies the three clip types and their properties, making the resource and verb unambiguous. This distinguishes it from siblings like list_tracks or list_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit parameter explanations, including the special case of track_index = -1 for all tracks. However, it does not explicitly discuss when not to use this tool or compare it to alternatives, though the context is clear for listing clips.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_effect_parametersA
Read-only

List all parameters of an effect on an audio unit.

unit_index: Audio unit index. effect_index: Effect position in the chain (0-based, from add_effect return).

Returns parameter names, current values, units, and ranges.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations provide readOnlyHint=true, indicating the tool is read-only. The description adds value by specifying that the tool returns parameter names, current values, units, and ranges, which goes beyond the annotations' information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a clear single-sentence purpose followed by parameter explanations and return value summary. No superfluous text; each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential information: purpose, parameter meanings, and return content. Given the tool's simplicity and the presence of an output schema, it is sufficiently complete. It does not discuss error conditions, but that is acceptable for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides full semantic meaning for both parameters: unit_index described as 'Audio unit index' and effect_index as 'Effect position in the chain (0-based, from add_effect return)'. Since schema description coverage is 0%, the description fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all parameters of an effect on an audio unit. It specifies the action (list) and resource (parameters of an effect), and distinguishes from siblings like list_effects (which lists effects) by explicitly focusing on parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the parameters (unit_index and effect_index) with clear guidance on effect_index being zero-based and from add_effect return. While it does not explicitly state when to use this tool versus other effect parameter tools, the context is clear enough for typical use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_effectsA
Read-only

List all available audio and MIDI effect types.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds the scope (audio and MIDI) but does not disclose any additional behavioral traits such as whether the list is sorted, if it includes inactive effects, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words. It front-loads the purpose immediately with 'List all available...'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of an output schema, the description is sufficient. It could optionally mention the output format, but the output schema covers that. Slightly more context about the nature of the list (e.g., names or IDs) would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema coverage is 100%. With no parameters, the description cannot add parameter meaning, but baseline is 4. It is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available audio and MIDI effect types, with a specific verb and resource. It distinguishes from siblings like 'list_midi_effects' (only MIDI) and 'list_effect_parameters' (parameters of a specific effect).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. There is no mention of when not to use it or comparison with querying specific effect lists or filtering options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_genre_profilesA
Read-only

List all available genre reference profiles for mix analysis.

Each profile defines target LUFS, spectral balance, stereo width, and dynamic range for professional mixes in that genre.

Use compare_to_profile() to check your mix against any of these.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context beyond the readOnlyHint annotation by detailing what each profile contains (LUFS, spectral balance, stereo width, dynamic range). This informs the agent about the output without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short paragraphs, each adding value: purpose, content detail, and usage guidance. No extraneous information; perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of parameters and the presence of readOnlyHint and an output schema, the description fully covers what the tool does and the nature of its return values. It references a sibling for further action, making it contextually complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so no additional semantics are needed. The description implicitly covers the purpose, meeting the baseline expectation for no-param tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List all available genre reference profiles for mix analysis', providing a specific verb and resource. It clearly distinguishes this tool from siblings like compare_to_profile(), which uses these profiles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance by stating 'Use compare_to_profile() to check your mix against any of these', telling the agent when to use this tool vs. the sibling. It implies a prerequisite: list profiles before comparing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_instrument_paramsA
Read-only

List all parameters of the instrument connected to an audio unit.

unit_index: Audio unit index (-1 = auto-detect first non-master AU with an instrument).

Returns instrument type, all parameter fields with values, units, and constraints. Works with: Vaporisateur (cutoff/resonance/ADSR/etc), Tape (flutter/wow/noise/saturation), Nano (volume/release), Soundfont (presetIndex), MIDIOutput (channel), Playfield, Apparat.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes beyond the readOnlyHint annotation by detailing the return content: instrument type, parameters with values, units, and constraints. It also lists compatible instruments, providing context not in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the purpose and then covering parameter, return value, and compatible instruments in a single, well-structured paragraph with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and existing output schema, the description is fully complete: it explains the parameter, specifies return content, and lists compatible instrument types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining the unit_index parameter's meaning and domain (-1 for auto-detect). It also adds context about supported instrument types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'parameters of the instrument connected to an audio unit'. It distinguishes itself from sibling tools like list_effect_parameters and list_midi_effect_params by specifying 'instrument' parameters. The parameter unit_index is defined with auto-detect logic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the unit_index parameter, including the sentinel value -1 for auto-detection, and lists compatible instruments. However, it does not explicitly state when not to use this tool or provide alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_markersA
Read-only

List all timeline markers with positions and labels.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, and the description confirms a read-only list operation. No additional behavioral traits (e.g., about scoping or performance) are disclosed. The description is consistent but does not add value beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the action and resource. Every word is necessary and no filler exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, read-only, output schema exists), the description fully covers what the tool does and what information it returns. It mentions 'positions and labels' which aligns with likely output schema fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The description is not required to explain parameters but correctly indicates no inputs needed. Baseline 4 for 0 parameters is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List all timeline markers with positions and labels' which clearly specifies the action (list), the resource (timeline markers), and the returned data (positions and labels). This distinguishes it from sibling tools like mcp_opendaw_add_marker (writes) and mcp_opendaw_list_transient_markers (lists a different type).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives such as mcp_opendaw_add_marker or mcp_opendaw_set_marker_label. Usage is implied for viewing markers, but no guidance on when not to use or prerequisites is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_midi_effect_paramsA
Read-only

List all parameters of a MIDI effect with current values.

unit_index: Audio unit index. effect_index: MIDI effect position in the chain (0-based).

Returns parameter names, values, units, and constraints.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds that the tool returns current values and provides the return structure (names, values, units, constraints), which is useful behavioral context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences with no unnecessary words. It frontloads the purpose, then explains parameters, then describes the return. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description correctly notes what is returned (names, values, units, constraints). It covers the purpose, parameters, and output, though it could mention prerequisites (e.g., the effect must exist).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides clear explanations for both required parameters: 'unit_index: Audio unit index.' and 'effect_index: MIDI effect position in the chain (0-based).' This adds meaning beyond the raw integer types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('list all parameters') and the resource ('a MIDI effect with current values'). It distinguishes itself from sibling tools like 'list_effect_parameters' (likely audio effects) and 'list_midi_effects' (list effects themselves).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the parameters and their roles, but does not provide explicit guidance on when to use this tool vs. sibling list tools. Usage is implied by the tool name and parameter descriptions, but no alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_midi_effectsA
Read-only

List all available MIDI effect types.

MIDI effects process note data before it reaches the instrument. They are inserted on the MIDI effect chain (au.midiEffects).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds context about MIDI effects processing note data and being on the au.midiEffects chain, providing useful behavioral insight beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no wasted words. The main action is front-loaded, and the additional sentences provide essential context without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (unseen), the description need not detail return values. It fully explains what the tool lists and the role of MIDI effects, making it complete for a discovery tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With no parameters and 100% schema coverage, the description correctly has no parameter info. It compensates by explaining the tool's purpose and context, which is sufficient for a parameterless list tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all available MIDI effect types' with specific verb and resource, and distinguishes from similar tools like 'list_effects' by specifying these are MIDI effects that process note data before the instrument.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for discovering MIDI effect types and mentions where they are inserted, but does not explicitly state when to use this tool versus alternatives like 'list_effects' or 'get_midi_effect_chain'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_midi_output_devicesA
Read-only

List all MIDI output devices registered in the project (hardware MIDI outputs).

Returns id, label, delayInMs, sendTransportMessages for each device.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. Description adds value by listing the specific return fields (id, label, delayInMs, sendTransportMessages) and clarifying that these are hardware MIDI outputs, providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is two sentences, front-loaded with purpose and concise listing of return fields. Every sentence is necessary and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with output schema and annotations, the description is complete. It states what is listed and the fields returned, covering all needed context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List all MIDI output devices' with specific verb and resource. It also specifies 'hardware MIDI outputs' and lists return fields, distinguishing it from other list tools like list_audio_buses or list_effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description does not explicitly provide when-to-use or when-not-to-use guidance. However, the name and description are self-explanatory for a simple list operation, so it is adequate but lacks explicit alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_modular_connectionsA
Read-only

List all connections (patch cables) in a Modular device.

au_index: Audio unit index. effect_index: Effect index within the AU.

Returns connections with source and target module/connector info.

ParametersJSON Schema
NameRequiredDescriptionDefault
au_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds minimal behavioral context beyond stating it lists connections and returns source/target info. It does not detail permissions, side effects, or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences for parameters and one for output. Every line adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple read-only nature and presence of an output schema, the description covers the core purpose and parameter semantics. It lacks error scenarios or what happens with invalid indices, but is sufficient for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% so description must explain parameters. It does: 'au_index: Audio unit index. effect_index: Effect index within the AU.' This adds meaning beyond the bare schema, though it lacks format or boundary details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all connections (patch cables) in a Modular device.' with a specific verb and resource. It distinguishes itself from sibling tools like 'connect_modular_modules' (write) and 'list_modular_devices' (list devices).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implies use for inspecting connections before connecting, but provides no exclusions or context for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_modular_devicesA
Read-only

List all Modular audio effect devices in the project.

Returns a list of modular devices with their AU index, label, and module/connection counts. Modular is a patchable modular synthesizer inside an audio effect slot.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds value by specifying the output fields (AU index, label, module/connection counts). No contradictions. Could mention if the list is always available given project state, but not necessary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary action, followed by output details and a definition of 'Modular'. Every sentence adds meaning without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, read-only annotations, and an output schema (exists), the description provides sufficient context: what it lists, return fields, and domain definition. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so baseline 4 applies. No parameter information needed. The schema coverage is 100% (empty), and the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and the resource (modular audio effect devices). It distinguishes from sibling tools like list_modular_connections and list_modular_modules by focusing on devices themselves. The additional context explaining 'Modular' clarifies the domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly provide when-to-use or when-not-to-use guidance. However, for a simple listing tool with no parameters, usage is straightforward. No alternatives are mentioned, but the description is self-explanatory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_modular_modulesA
Read-only

List all modules in a Modular device.

au_index: Audio unit index. effect_index: Effect index within the AU.

Returns modules with their type, label, x/y position, inputs, outputs, and parameter values. Module types: gain, delay, multiplier, audio-input, audio-output.

ParametersJSON Schema
NameRequiredDescriptionDefault
au_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds detail on the specific fields returned (type, label, x/y, inputs, outputs, parameter values) and known module types, providing behavioral context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single-sentence purpose, then parameter descriptions, then return fields and types. Every sentence adds value, and key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values are documented elsewhere. The description adds context about module types and the kind of data returned. It could mention error cases or prerequisites (e.g., device must be a Modular device), but overall is fairly complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains 'au_index' as 'Audio unit index' and 'effect_index' as 'Effect index within the AU', adding meaning beyond the schema's generic titles. However, it does not specify how to obtain these indices (e.g., via list_modular_devices).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and resource 'modules in a Modular device'. It specifies what is returned (type, label, x/y position, inputs, outputs, parameter values) and lists module types. This distinguishes it from siblings like 'list_modular_devices' and 'add_modular_module'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., 'list_modular_devices', 'add_modular_module'). It does not mention prerequisites or exclusions, leaving the agent to infer context from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_note_regionsA
Read-only

List all note regions with position, duration, and note count.

unit_index: Audio unit index (-1 = all AUs). track_index: Specific note track (-1 = all note tracks).

Returns list of regions with: region_index, unit_index, track_index, position_beats, duration_beats, label, note_count.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotation readOnlyHint=true already indicates no side effects. The description adds value by listing return fields and explaining parameter semantics, without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one line for purpose, two lines for parameters, one line for return fields. No wasted words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description covers action, parameter behavior, and return fields adequately. No missing context given the output schema exists externally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining both parameters: unit_index as audio unit index with -1 for all, and track_index as note track with -1 for all, providing complete meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'List all note regions' with specific data fields (position, duration, note count). It is clear but does not explicitly differentiate from sibling tools like 'list_notes' or 'list_audio_regions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains parameter usage (e.g., -1 for all) but provides no guidance on when to use this tool vs. alternatives, such as 'list_notes' for individual notes or 'list_audio_regions' for audio regions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_notesA
Read-only

List all note events within a region.

Returns each note with position (beats), duration (beats), pitch (MIDI 0-127), velocity (0-1), cent, and chance (0-100).

unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region to list notes from (0-based).

Returns list of notes sorted by position.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations include readOnlyHint=true, so the description does not repeat that. It adds behavioral context: notes are sorted by position, and unit_index=-1 searches all AUs. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for purpose, then return fields, then parameter explanations, then sorting. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 parameters, no nested objects) and the presence of an output schema, the description covers all necessary information: purpose, parameters, output fields, and sorting behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains each parameter: unit_index (-1 searches all), track_index (within AU), region_index (0-based). This adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List all note events within a region', clearly specifying the action and resource. It distinguishes itself from sibling list tools (e.g., list_tracks, list_clips) by focusing on note events within a region.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. While the name is self-explanatory, the description does not mention alternatives or prerequisites, which would help an agent choose this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_playfield_samplesA
Read-only

List all drum pads (samples) on a Playfield drum machine.

unit_index: Audio unit index (-1 = auto-detect Playfield).

Returns list of pads with MIDI note, enabled state, and effects.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds value by specifying the returned data (MIDI note, enabled state, effects), which is beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences front-load the purpose and include all necessary information with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the presence of an output schema, and the description's additional detail on return content, completeness is achieved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds crucial meaning to the sole parameter unit_index, explaining that -1 auto-detects Playfield, which is not evident from the schema alone (schema coverage 0%).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists drum pads (samples) on a Playfield drum machine, distinguishing it from generic sample-listing tools like mcp_opendaw_list_samples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the unit_index parameter with auto-detect hint. While no explicit when-not or alternatives are given, the purpose is narrowly scoped to Playfield drum pads, making usage clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_samplesA
Read-only

List all audio file samples used in the project.

Returns sample UUIDs and metadata for each audio file referenced in the project.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds scope (all audio file samples) and output details (UUIDs and metadata) beyond the readOnlyHint annotation. However, for a read-only list tool, the annotation already covers the safety profile, so the description adds modest value. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the main purpose. No redundant or extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and the existence of an output schema, the description adequately covers the tool's functionality. It mentions the return of UUIDs and metadata, which is complete for a list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema description coverage is 100% (empty properties). The description correctly implies no input needed, which is sufficient. Baseline 4 for 0 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all audio file samples in the project and returns UUIDs and metadata. It uses a specific verb ('list') and resource ('audio file samples'), distinguishing it from sibling list tools that target other entities (e.g., list_notes, list_tracks).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It simply states what it does, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_script_paramsB
Read-only

List @param declarations on a scriptable device with full mapping info.

Each parameter includes: label, index, current value, default value, min, max, mapping type (unipolar/linear/exp/int/bool), and unit. Mapping info is parsed from // @param <name> <default> <min> <max> <type> <unit> declarations in the code — the code is the single source of truth.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
device_typeYes
device_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds value by explaining the data source (parsed from code comments) and what information is included (label, index, values, mapping type, unit).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, and includes substantive detail about output fields; could be slightly optimized but is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 0% parameter coverage and no usage guidance, the description is incomplete despite having an output schema; it fails to address the most critical gap (input parameter semantics).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any of the three input parameters (unit_index, device_type, device_index), leaving the agent without guidance on how to specify the target device.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'list' and resource '@param declarations on a scriptable device', uniquely identifying the tool's purpose among many sibling list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus other parameter listing tools like list_effect_parameters or list_instrument_params; context is implicit from the title and description but could be improved.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_script_samplesA
Read-only

List @sample declaration slots on a scriptable device.

Each sample slot is a WerkstattSampleBox with: label, index, file (pointer to AudioFileBox). Sample slots are auto-created from // @sample <name> declarations in the code. The file pointer is null until a sample is loaded.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
device_typeYes
device_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral detail beyond the readOnlyHint annotation by explaining that file pointers are null until a sample is loaded. This helps the agent understand the state of returned data, which is consistent with the read-only nature declared in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs, front-loads the main purpose, and includes no unnecessary words. Every sentence adds value, explaining the function and the structure of returned slots.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations, the description covers output structure but fails to explain input parameters. It is complete for the output but leaves input semantics ambiguous, which is a moderate gap for a tool with three required parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, placing the burden on the description to explain parameters. However, the description does not explain what device_type, unit_index, or device_index represent or how they identify the scriptable device, leaving the agent to guess their meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists @sample declaration slots on a scriptable device, specifying the verb 'List' and the resource 'sample declaration slots'. It further describes the structure of each slot (WerkstattSampleBox with label, index, file), distinguishing it from other list tools by focusing on script samples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing script samples but lacks information about when not to use it or comparisons to sibling tools like list_samples or list_playfield_samples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_sendsA
Read-only

List all aux sends on an audio unit.

unit_index: Audio unit index to inspect.

Returns list of sends with: send_index, target_bus_name, send_level_db, routing.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description confirms a read-only operation. Additionally, it specifies the return fields (send_index, target_bus_name, send_level_db, routing), providing behavioral detail beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: three short lines covering purpose, parameter, and return fields. No redundant information, ideal for quick parsing by an AI.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a simple read-only operation and one parameter, the description is largely complete. It covers the return format explicitly. No major gaps, though it could mention that the operation is safe (covered by annotation).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter `unit_index` is explained as 'Audio unit index to inspect,' adding clear meaning beyond the raw schema (integer type). This helps the agent understand what value to provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List all aux sends on an audio unit,' clearly specifying the verb (list), resource (aux sends), and scope (on an audio unit). It distinguishes from sibling tools like create_send or remove_send, which are for modification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. The description implies it is for inspection, but does not mention when not to use or compare to other list tools like list_audio_buses. However, the purpose is straightforward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_signature_changesB
Read-only

List all time signature changes on the timeline's signature track.

Returns each signature event with position (beats), numerator, and denominator.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description adds minimal behavioral insight beyond stating it returns events with specific fields. It does not describe any other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action, and contains no unnecessary words. It efficiently conveys purpose and return structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema, the description is mostly complete. However, it lacks differentiation from the similar sibling 'get_signature_events', which reduces contextual completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. Per guidelines, zero parameters default to baseline 4. The description adds no parameter info, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all time signature changes on the timeline's signature track and specifies return fields. However, it does not distinguish from the sibling tool 'mcp_opendaw_get_signature_events', which likely has a similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'get_signature_events' or 'add_signature_change'. The description only states what it does without offering usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_split_modesA
Read-only

List available stem separation modes with descriptions.

Returns all modes supported by mcp_opendaw_split_stems, with SDR scores and use-case recommendations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. Description adds that it returns SDR scores and use-case recommendations, providing behavioral detail beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no waste, front-loaded purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a parameterless list tool with an output schema. Mentions sibling tool and output contents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema is fully covered. Description adds no parameter info but is not needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'available stem separation modes', and distinguishes it from siblings by explicitly linking to mcp_opendaw_split_stems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage before calling split_stems to see available modes. No exclusions or alternatives, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_tempo_changesA
Read-only

List all tempo (BPM) changes on the timeline's tempo track.

Returns each tempo event with position (beats), BPM, and interpolation type. The tempo track uses normalized values mapped to minBpm..maxBpm (default 60..240).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, confirming safe read. Description adds context about normalized values and mapping, but doesn't disclose potential limitations (e.g., event count, performance). Incremental value beyond annotations is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two precise sentences, front-loaded with action and resource, no redundancy. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of output schema, description provides necessary detail (returned fields, mapping). Could mention ordering or scope (entire project), but sufficient for a simple list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100% by default. Description explains output fields and mapping, adding value beyond schema. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists tempo changes on the timeline's tempo track, specifying returned data (position, BPM, interpolation type). Distinguishes from siblings like add_tempo_change (write) and get_tempo_at (single point).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly indicates usage for retrieving existing tempo events, but no explicit guidance on when to use vs alternatives (e.g., get_tempo_at, list_signature_changes). Lacks when-not-to-use or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_tracksA
Read-only

List all tracks across all audio units with their type, effects, and regions.

Returns structured info: audio units with their tracks (audio/note/automation), effects chain, volume, panning, and region count.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint: true. The description adds return structure (effects chain, volume, panning, region count) but no deeper behavioral traits like performance or state changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. First states action and scope, second details return structure. No wasted words, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with output schema, the description sufficiently outlines returned data (audio units, tracks, effects, volume, panning, region count).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline for zero params is 4; description adds no param info but doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all tracks across all audio units' with specific info returned: type, effects, regions. It distinguishes from other list_* siblings by focusing on tracks across units.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_notes or list_effects. No exclusions or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_transient_markersA
Read-only

List transient markers for an audio region's audio file.

Transient markers are auto-detected hit points in the audio. Useful for beat slicing and groove extraction.

unit_index/track_index/region_index: Audio region coordinates.

Returns array of transient positions (in samples) or empty if none.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is consistent with the readOnlyHint annotation, stating it lists markers. It adds value by describing the return format ('array of transient positions (in samples) or empty if none'), providing behavioral insight beyond the annotation alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with only three sentences plus a parameter explanation. It is front-loaded with the purpose, contains no redundant information, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description adequately covers purpose, parameter meaning, and output format. It mentions the possibility of an empty return. However, it does not address prerequisites like ensuring the region exists, and the sample unit could be clarified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It explains that 'unit_index/track_index/region_index: Audio region coordinates,' adding meaning to the parameters. However, it does not specify valid ranges or how to obtain these indices, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'transient markers for an audio region's audio file'. It explains what transient markers are (auto-detected hit points) and provides use cases (beat slicing, groove extraction), effectively distinguishing this tool from general list_markers tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the tool is 'Useful for beat slicing and groove extraction,' which implies when to use it. However, it does not explicitly state when not to use it or provide direct alternatives among siblings. The context is clear but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_value_regionsA
Read-only

List automation regions (ValueRegionBox) on value/automation tracks.

Finds all Value-type tracks (automation) and lists their regions with position, duration, loop settings, mute, and label.

unit_index: Audio unit index (-1 = search all AUs). track_index: Specific value track (-1 = all value tracks on the unit).

Returns list of automation regions.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already set readOnlyHint=true, so the description reinforces it by describing a read-only list operation. It adds context that the tool searches all Value-type tracks and returns region details. No contradictions; behavior is transparent and consistent with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly concise with two short paragraphs: first explains the tool's action and output, second details parameters. Every sentence adds value, but the explanation of parameters could be integrated into a single structured format. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (as indicated by context), the description does not need to detail return values. Parameters are well-documented, and the tool's scope is clear. Complete enough for an agent to use correctly, though adding a note about the output schema structure would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden. Both parameters are explained with their meaning and sentinel values (-1 for all). This adds significant meaning beyond the raw schema, though could be slightly more detailed (e.g., data types implied but not stated).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists automation regions on value/automation tracks, specifying the returned fields (position, duration, loop settings, mute, label). It differentiates itself by focusing on 'ValueRegionBox' and 'value/automation tracks', though it could be more explicit about how it differs from similar list tools like list_automation_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies usage when you need to list automation regions, but given many sibling list tools, the agent needs clearer decision criteria (e.g., 'Use this instead of list_automation_events when you need region-level data'). Missing when-not-to-use or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_vaporisateur_paramsA
Read-only

Get full Vaporisateur synthesizer state: oscillators, LFO, noise, main params.

unit_index: Audio unit index (-1 = auto-detect Vaporisateur).

Returns:

  • oscillators: [{index, waveform, volume, octave, tune}]

  • lfo: {waveform, rate, sync, attack, decay, release}

  • noise: {volume, attack, decay, release}

  • main: cutoff, resonance, attack, release, filterEnvelope, decay, sustain, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only (readOnlyHint=true). The description adds the return structure and auto-detect behavior, but does not disclose potential errors (e.g., invalid unit index) or performance implications. Beyond annotations, it provides moderate behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, and uses bullet points for return fields. Every sentence adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter schema and the described return structure, the description is fairly complete. It covers purpose, parameter meaning, and output fields. Minor missing details: error handling for auto-detect failure or invalid indices, but overall sufficient for a read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the unit_index parameter. The description fully compensates by explaining its meaning ('Audio unit index (-1 = auto-detect Vaporisateur)'), which is essential for correct tool usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full Vaporisateur synthesizer state, listing included components (oscillators, LFO, noise, main params). It is specific to Vaporisateur and distinguishes itself from sibling tools like set_vaporisateur_osc_param (which sets a parameter) and list_instrument_params (generic).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the unit_index parameter with auto-detect behavior but does not explicitly state when to use this tool versus siblings or provide when-not guidance. The context implies usage for retrieving Vaporisateur state, but lacks explicit exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_list_warp_markersA
Read-only

List warp markers on a time-stretched or pitch-stretched audio region.

Warp markers define the mapping between musical position (ppqn) and audio time (seconds). Used for tempo-matching audio regions.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index.

Returns warp marker list (position, seconds, isAnchor), or empty if no stretch mode.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description correctly indicates a read-only operation (list) consistent with the readOnlyHint annotation. It details the return value (warp marker list with position, seconds, isAnchor) and the edge case (empty if no stretch mode), providing full behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose, background, parameters, return value. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and existing output schema, the description covers purpose, usage context, parameters, return behavior, and edge case. It is fully self-contained for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates by explaining each parameter (unit_index, track_index, region_index) with brief descriptions. While not exhaustive, it adds meaningful context beyond the schema's empty descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists warp markers on time-stretched or pitch-stretched audio regions, with a distinct verb and resource. It differentiates from sibling tools like create_warp_marker, delete_warp_marker, and update_warp_marker by focusing on listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool is used for tempo-matching audio regions, providing context. However, it does not explicitly state when not to use it. Alternatives like get_region_info are not mentioned, so guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_load_audioA

Load an audio file (WAV/MP3/FLAC/OGG) into the DAW project.

file_path: Absolute path to the audio file on disk. If the file is inside the headless-daw/public/ directory, it will be fetched via URL (much faster for large files). Otherwise loaded via base64. name: Optional display name (defaults to filename).

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
file_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the loading method (URL vs base64) based on file location, adding useful behavioral context. However, it does not mention side effects, such as whether it creates tracks or replaces existing audio, leaving some behavior unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: the main action is front-loaded, followed by parameter details. There is no unnecessary text, and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple load tool with a known output schema, the description covers the main behavior and parameter semantics. It could be improved by elaborating on what 'load into the DAW project' entails (e.g., track creation, audio pool), but it is otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining both parameters: file_path with loading behavior and name with a default value. This adds meaningful context beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it loads audio files (WAV/MP3/FLAC/OGG) into the DAW project. However, it does not explicitly differentiate from similar tools like mcp_opendaw_import_audio_to_tracks, leaving some ambiguity about the exact placement or usage context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the file_path behavior and name default but does not provide explicit guidance on when to use this tool versus alternatives. The context for using this tool is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_load_effect_presetA

Load a .opb preset file into the DAW and apply it to an audio unit.

Reads the preset bundle, decodes the effect chain via PresetDecoder, and inserts it onto the specified audio unit. If unit_index is -1, uses the primary (first non-output) audio unit.

filepath: Path to the .opb preset bundle file. unit_index: Target audio unit index. -1 = primary instrument unit.

ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYes
unit_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It reveals internal details (reads bundle, decodes via PresetDecoder, inserts onto unit), which is helpful. However, it does not specify whether the insertion replaces or appends existing effects, or mention potential side effects like silencing the unit temporarily.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core purpose, followed by internal detail and parameter explanations. It is structured logically, though it could be slightly more terse by removing the internal mechanism sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (context signals indicate present), the description does not need to detail return values. It covers the essential functionality but could be improved by noting potential error conditions (e.g., invalid file path, incompatible preset format).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does so by explaining both parameters: filepath is 'Path to the .opb preset bundle file' and unit_index is 'Target audio unit index. -1 = primary instrument unit.' This adds meaningful context beyond the schema's type/title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('load a .opb preset file' and 'apply it to an audio unit') and the resource (effect preset for audio unit). The tool name itself reinforces this, and the description distinguishes it from siblings by specifying the file format and target.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a specific usage hint for the unit_index parameter (use -1 for primary unit), but does not explicitly state when to use this tool versus alternatives like import_preset or replace_from_preset. No exclusions or comparative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_load_projectA

Load a previously saved project from a .odaw file.

Restores the full project state (tracks, regions, effects, notes, settings) from a serialized ArrayBuffer. The engine must be restarted after loading (call start_engine again).

filename: Name of the .odaw file in the exports directory (without path). Returns: box count and confirmation.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries burden. It mentions full state restoration and engine restart but does not disclose whether loading overwrites unsaved changes or other side effects, leaving gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is reasonably concise but mixes purpose, usage, parameter info, and return value in a somewhat scattered order. Could be more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the return note is acceptable, but missing details on error handling (file not found) and impact on running engine make it less complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds crucial context: filename is just the name (no path) and file is in exports directory. This goes beyond the schema's type/title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool loads a previously saved .odaw file and restores the full project state, distinguishing it from create, save, or export tools among many siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs the engine must be restarted after loading and specifies file location (exports directory, no path). Lacks comparison to import tools or warning about data loss, but provides good context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_map_velocity_by_pitchA

Map velocity based on pitch — expressive dynamics from note height.

Adjusts note velocity proportionally to pitch position. High notes get quieter, low notes get louder (or vice versa). This simulates natural acoustic instrument behaviour where register affects perceived intensity.

Modes:

  • "higher_quieter" — high notes quieter, low notes louder (piano natural, orchestral mockups). Default. Kick drum louder than hi-hat.

  • "lower_quieter" — low notes quieter, high notes louder (lead synth patches, bell-like timbres where highs cut through).

  • "bell_curve" — loudest in the middle register, quieter at extremes (vocal range, mid-range instruments like guitar/violin).

  • "inverse_bell" — quietest in the middle, louder at extremes (experimental).

intensity: 0-1, how much pitch affects velocity (0 = no change, 0.5 = moderate, 1.0 = full effect). At 0, velocities are unchanged.

The formula for "higher_quieter": relative_pos = (pitch - pitch_ref) / 48 (48 = 4 octaves range) factor = 1.0 - relative_pos * intensity new_vel = current_vel * factor (clamped to min/max)

pitch_ref: MIDI pitch that serves as the neutral point (no change). 60 = C4 (middle C). Adjust for your instrument's register.

Use cases:

  • Make flat MIDI velocities sound more natural (piano, orchestra)

  • Drum kits: kick (low pitch) louder than hi-hat (high pitch)

  • Lead synth: highs cut through more (lower_quieter)

  • Vocal range emphasis (bell_curve around pitch_ref=64)

unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first, -2 = all regions). mode: higher_quieter / lower_quieter / bell_curve / inverse_bell. intensity: 0-1, strength of pitch-to-velocity mapping. min_velocity / max_velocity: Clamp range. pitch_ref: Neutral pitch (default 60 = C4).

Returns modification summary with per-octave velocity stats.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNohigher_quieter
intensityNo
pitch_refNo
unit_indexYes
track_indexYes
max_velocityNo
min_velocityNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It explains the formula, modes, intensity effect, clamping, and return summary. However, it does not explicitly state whether the modification is destructive or reversible, though it implies in-place modification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with sections: purpose, explanation, modes, formula, parameters, use cases. It is front-loaded with purpose. Some redundancy (e.g., parameter listing twice) could be tightened, but overall it is clear and organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, output schema exists), the description is comprehensive. It covers the transformation logic, all parameters, mode details, use cases, and mentions the return type. The output schema handles return value details, so the description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains all 8 parameters, including mode options, intensity range, pitch_ref default, and clamp range. It also provides formula details and default values, adding significant meaning beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool maps velocity based on pitch, with specific modes for different effects. It distinguishes from sibling velocity tools by emphasizing the pitch-velocity relationship, which is unique among the listed velocity tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases such as making flat MIDI velocities more natural, drum kits, lead synth, and vocal range emphasis. It implies when to use different modes but does not directly contrast with alternative tools or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_match_to_referenceA

Automatically match your mix to a reference track — spectral + loudness alignment.

Like Phantom's match_to_reference: takes your mix and a reference, then:

  1. Measures LUFS difference → applies gain compensation

  2. Measures per-band spectral difference → applies EQ correction

  3. (Optional) Measures stereo width → applies stereo adjustment

Outputs a matched WAV file. This is automated A/B matching — the mix gets as close to the reference as possible without re-mixing.

filename: Your mix WAV (exports dir or absolute path). reference: Reference track WAV (exports dir or absolute path). output_filename: Output filename (default: _matched.wav). match_lufs: Match integrated LUFS. match_spectrum: Match per-band spectral energy (7-band EQ correction). match_stereo: Match stereo width (experimental).

Returns analysis of what was applied + output file path.

Example: match_to_reference("my_mix.wav", "pro_track.wav")

→ {lufs_adjusted: +1.4 dB, eq_curves: [...], output: "my_mix_matched.wav"}

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
referenceYes
match_lufsNo
match_stereoNo
match_spectrumNo
output_filenameNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details the automated process: gain compensation, EQ correction, optional stereo adjustment, output of a matched WAV file, and a return object with analysis. It labels stereo matching as 'experimental'. While it doesn't mention file permissions or side effects, it adequately discloses the main behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise purpose sentence, step-by-step breakdown, parameter list, and example. Each section adds value without redundancy. The parameter list is clear and the example illustrates typical usage. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, operation steps, parameter details, and return structure (via example). Given that the tool has an output schema, the example return is a bonus. For a moderately complex matching tool, the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema). The description compensates by listing all 6 parameters with clear explanations: filename, reference, output_filename, and three boolean flags (match_lufs, match_spectrum, match_stereo) with defaults. An example call further clarifies usage. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: automatically matching a mix to a reference track via spectral and loudness alignment. It explicitly references 'Phantom's match_to_reference' and explains the three-step process, making the purpose unmistakable and distinguishing it from sibling tools like compare_to_reference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool's workflow (LUFS, spectral, stereo matching) and provides an example. It implies usage for A/B matching but does not explicitly state when not to use it or suggest alternatives. The reference to a known plugin helps, but lacks direct exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_measure_lufsA

Measure LUFS (integrated) and true peak of an exported WAV file.

Uses ITU-R BS.1770-4 simplified algorithm:

  • K-weighting: 2nd-order high-shelf (+4dB @ ~1.5kHz) + highpass (~38Hz)

  • Gated mean squares (400ms blocks, 75% overlap, -10 LU relative gate)

  • Integrated LUFS = -0.691 + 10*log10(gated mean square)

filename: Name of the WAV file in the exports directory (without path).

Returns: LUFS (integrated), true peak (dBTP), max sample, duration seconds.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals the algorithm (ITU-R BS.1770-4 simplified), the measurement steps (K-weighting, gating), and the specific return values (LUFS, true peak, max sample, duration). This goes beyond typical descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear first sentence stating purpose, followed by algorithm details, parameter explanation, and return values. However, the algorithm details (e.g., K-weighting coefficients, gate threshold) may be excessive for an AI agent and could be streamlined for better conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (single parameter, no nested objects, no output schema but return values listed), the description is fully complete. It explains what the tool does, how it works, what input it needs, and what output to expect. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (filename) with no description. The tool description adds critical context: 'Name of the WAV file in the exports directory (without path).' This clarifies the file location and format, which is not evident from the schema alone. Schema coverage is 0%, so the description compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool measures LUFS (integrated) and true peak of an exported WAV file, with a specific verb ('Measure') and resource ('WAV file'). It distinguishes itself from sibling analysis tools (e.g., analyze_dynamics, analyze_mix) by focusing on loudness metrics per ITU-R standard.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides algorithm details but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites (e.g., file must be exported first) or exclusions (e.g., not for real-time monitoring). Usage context is only implied by the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_merge_consecutive_notesA

Merge consecutive notes of the same pitch into single sustained notes.

Scans notes sorted by position. When two notes have the same pitch and the gap between them is within max_gap_beats, they are merged into one note spanning from the first note's start to the last note's end. Useful for cleaning up repeated hits, converting staccato patterns to sustained notes, or simplifying busy passages.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) same_pitch_only: If True, only merge notes with identical pitch. If False, merge any consecutive notes regardless of pitch (uses first note's pitch for the merged result). max_gap_beats: Maximum gap between note end and next note start to qualify for merging (0.0 = touching/overlapping only, 0.25 = up to a 16th note gap, 1.0 = up to 1 beat gap). velocity_mode: Velocity for merged note — "first" = use first note's velocity, "last" = use last note's velocity, "max" = use highest velocity, "avg" = use average velocity across merged notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo
max_gap_beatsNo
velocity_modeNofirst
same_pitch_onlyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description thoroughly explains the behavioral algorithm: scanning sorted notes, merging based on pitch and gap, and handling the `same_pitch_only` flag. It does not mention whether the operation is destructive or reversible, but given no annotations, the description provides good insight into what the tool does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by algorithm explanation and parameter details. It is slightly verbose but front-loaded with the most important information, making it easy for an AI agent to understand.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all parameters and the merge algorithm comprehensively. It does not mention error conditions, preconditions (e.g., notes must exist), or undo behavior. An output schema exists, so missing return value explanation is acceptable. Minor gaps prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the tool's description includes a detailed 'Args:' block that explains each parameter's meaning, including `max_gap_beats` with examples (0.0, 0.25, 1.0) and `velocity_mode` options ('first', 'last', 'max', 'avg'). This adds significant value beyond the JSON schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Merge consecutive notes of the same pitch into single sustained notes.' It explains the scanning logic and distinguishes from sibling tools like merge_note_regions and merge_note_tracks by focusing on same-pitch consecutive notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for use: 'Useful for cleaning up repeated hits, converting staccato patterns to sustained notes, or simplifying busy passages.' However, it does not explicitly state when not to use it or compare with alternatives such as merge_note_regions or merge_note_tracks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_merge_note_regionsA

Merge two note regions on the same track into one.

Copies all notes from region B into region A's note collection, adjusting positions so they remain at their original absolute timeline position. Region A's duration is extended to cover both regions. Region B is deleted.

The regions do not need to be adjacent — if there's a gap between them, the merged region spans the full range (with silence in the gap).

Use cases:

  • Join verse + chorus into one continuous region

  • Consolidate split regions back together

  • Merge separately-recorded MIDI takes

  • Simplify arrangement before export

unit_index: AU index. track_index: Note track index. region_index_a: First region (keeps its identity, absorbs B's notes). region_index_b: Second region (deleted after merge).

Returns merged region details.

Example:

Merge regions 0 and 1 into one

merge_note_regions(0, 0, 0, 1)

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_index_aYes
region_index_bYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with no annotations, the description fully discloses behavior: it copies notes from B to A while preserving absolute positions, extends region A's duration, deletes region B, and handles gaps with silence. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a concise main statement followed by behavior details, use cases, parameter explanations, return info, and an example. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers all key aspects: behavior, parameters, use cases, and return value. It could mention error conditions (e.g., regions on different tracks) but is otherwise thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 0%, but the description adds detailed explanations for each parameter (unit_index, track_index, region_index_a, region_index_b) in plain language, making their roles clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it merges two note regions on the same track. However, it does not explicitly differentiate from sibling tools like 'consolidate_region' or 'flatten_note_regions', which might have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides relevant use cases (joining verse+chorus, consolidating split regions, etc.) and notes that regions need not be adjacent. However, it lacks explicit guidance on when not to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_merge_note_tracksA

Merge notes from a source track into a destination track.

Combines notes from two tracks into one, optionally deleting the source. Overlapping notes are resolved by the chosen strategy. Unlike copy_notes_to_track (which just copies), merge consolidates two note streams into a single coherent track — the source notes are integrated into the destination region and optionally removed from origin.

Typical use cases:

  • Merge a doubled melody into the main melody track

  • Consolidate counterpoint into the harmony track

  • Combine left-hand and right-hand piano into one track

  • Flatten multi-track MIDI into a single instrument

Args: source_unit: AU index of source track source_track: Note track index within source AU dest_unit: AU index of destination track dest_track: Note track index within destination AU source_region: Source region index (-1 = first region) dest_region: Destination region index (-1 = first region, or auto-create if none exists) delete_source: If True, delete source notes after merge. If False, notes remain in both tracks (copy mode). resolve_overlaps: Strategy for overlapping notes — "keep_higher_velocity" = keep louder note at conflict point, "keep_lower_velocity" = keep quieter note, "keep_source" = prefer source notes, "keep_dest" = prefer destination notes, "keep_both" = keep all overlapping notes (no resolution), "shorten_earlier" = truncate the earlier-starting note to end where the later one begins. transpose: Semitones to transpose source notes (-24 to 24).

ParametersJSON Schema
NameRequiredDescriptionDefault
dest_unitYes
transposeNo
dest_trackYes
dest_regionNo
source_unitYes
source_trackYes
delete_sourceNo
source_regionNo
resolve_overlapsNokeep_higher_velocity

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details merging behavior, delete_source option, overlap resolution strategies, transpose, and region handling. It does not mention side effects like permanent changes or performance, but the key behaviors are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, comparison, use cases, and parameter list. It is front-loaded with the main action. While slightly lengthy, every section contributes useful information, making it appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, and the description does not explain return values. However, for a complex tool with 9 parameters and overlap strategies, the parameter semantics are thorough. Minor gap in return value documentation prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description includes an 'Args' section that explains each parameter in detail, including defaults, meaning, and allowed values (e.g., resolve_overlaps strategies). This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Merge notes from a source track into a destination track' and explicitly distinguishes from sibling tool copy_notes_to_track, saying it consolidates two note streams rather than just copying. This provides a specific verb+resource with clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides typical use cases (e.g., merge a doubled melody, consolidate counterpoint) and contrasts with copy_notes_to_track. However, it does not explicitly state when not to use this tool, though the contrast implies the exclusive scenario. Slightly lacking in exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_modulate_progressionA

Transpose a chord progression to a new key.

Modulation is the technique of changing key within a song. This tool takes a progression like "Am-F-C-G" (key of A minor) and transposes every chord to a new key while preserving chord qualities (major/minor/ 7th etc.) and interval relationships.

Common modulations:

  • Up a fourth (C→F): most natural, adds energy for chorus

  • Up a fifth (C→G): bright, triumphant

  • To relative major (Am→C): minor→major mood shift

  • To relative minor (C→Am): major→minor mood shift

  • Down a third (C→A): darker, bridge section

progression: Source progression (e.g. "Am-F-C-G"). target_key: Target key root note (e.g. "C", "F", "D", "Bb"). direction: "up" or "down" (affects octave placement, default "up").

Returns the modulated progression string + per-chord mapping.

Example:

A minor → C major (relative major)

modulate_progression("Am-F-C-G", target_key="C")

→ "C-G-Am-F" (I-V-vi-IV in C major)

A minor → F (up a fourth for chorus)

modulate_progression("Am-F-C-G", target_key="F")

C major → A minor (relative minor for bridge)

modulate_progression("C-G-Am-F", target_key="A")

ParametersJSON Schema
NameRequiredDescriptionDefault
directionNoup
target_keyNoC
progressionNoAm-F-C-G

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: preserves chord qualities, interval relationships, and that direction affects octave placement. Also states return value includes modulation string and per-chord mapping. No annotations provided, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, examples, and parameter details. Could be slightly more concise but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input, behavior, common use cases, and output. With output schema present, description is sufficiently complete for a transformation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds essential meaning to each parameter with examples and defaults, compensating effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool transposes a chord progression to a new key, with specific examples and common modulation patterns. It distinguishes itself from siblings by focusing on modulation vs. reharmonization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when to use modulation (e.g., for chorus, bridge) with examples, but does not explicitly exclude cases where alternatives like reharmonization are better.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_audio_unitA

Move an audio unit up or down in the mixer order.

Uses AudioUnitBoxAdapter.move(delta) — reindexes the AU within its type group (Instrument/Aux/Output). Delta is relative: -1 = up, +1 = down.

unit_index: Current AU index. delta: Relative move (-1 up, +1 down).

Returns new index or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
deltaYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description adds value by explaining internal method (AudioUnitBoxAdapter.move), delta semantics, and return type. Does not explicitly state that it modifies project state (destructive), but move operations are inherently modifying.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short purposeful sentences plus parameter definitions. Front-loaded purpose, efficient structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core behavior, parameter constraints, and return value. Simple tool with output schema present. Could mention mutability but not necessary for clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but description explains both parameters: unit_index as current index and delta as relative move with allowed values -1/+1. This provides crucial meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'move' and resource 'audio unit' in mixer order, distinguishing from sibling move tools like move_effect and move_track. Also provides implementation detail and group scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Purpose is clear but no explicit guidance on when to use vs alternatives like rename or delete. Only implied usage for reordering within type groups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_automation_eventA

Move an automation event to a new position on the timeline.

unit_index: AU index. track_index: Value (automation) track index. event_index: Event index (from list_automation_events). new_position_beats: New position in beats (float).

Returns success with old and new positions.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
event_indexYes
track_indexYes
new_position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses that the tool moves an event and returns old and new positions, but does not mention reversibility, constraints, or side effects. Basic but sufficient for a simple move operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one sentence for purpose, then bullet-like parameter descriptions. No extraneous text, front-loaded with the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core purpose, parameters, and return value. With an output schema present, it need not detail return structure. Lacks behavioral depth but adequate for a simple mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains all four parameters (unit_index, track_index, event_index, new_position_beats) with brief descriptions and notes that event_index comes from list_automation_events. Provides enough meaning for an agent to guess valid values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Move) and resource (automation event) on the timeline. It distinguishes from siblings like move_notes or move_region_content by specifying automation events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies by referencing list_automation_events that prior listing is needed, but does not explicitly state when to use this tool versus alternatives like move_notes or move_region. No exclusions or alternative guidance provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_effectA

Reorder an effect within an audio unit's effect chain.

Chain order matters: EQ → Compressor → Reverb sounds different than Compressor → EQ → Reverb. Use this to move effects to the desired position.

unit_index: Audio unit index. from_index: Current effect position (0-based). to_index: Target effect position (0-based).

Effects between from and to shift accordingly.

ParametersJSON Schema
NameRequiredDescriptionDefault
to_indexYes
from_indexYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains that effects between from and to shift accordingly and mentions indices are 0-based. However, it does not describe return value, error handling for out-of-range indices, or whether the operation is undoable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise with five lines: purpose, chain order note, three parameter descriptions, and a final note on shifting. No redundant information, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple reorder operation with three parameters, the description covers core behavior and parameter meanings. However, it lacks details on output schema and edge case handling (e.g., out-of-bounds indices), which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% description coverage, but the description provides concise definitions for all three parameters: unit_index is 'Audio unit index', from_index and to_index are 'Current/Target effect position (0-based).' This adds meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Reorder an effect within an audio unit's effect chain.' It uses a specific verb and resource, and the chain order explanation distinguishes it from sibling tools like add_effect or remove_effect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the phrase 'Use this to move effects to the desired position.' It gives context on why chain order matters but does not explicitly state when not to use it or contrast with alternatives like duplicate_effect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_notesA

Move notes from a source region to another track — copy + delete.

Copies notes from source region to destination track (auto-creating a region or appending to an existing one), then optionally deletes the originals. Useful for splitting material across tracks, reorganising arrangements, or moving a section to a different instrument.

Args: source_unit: Source audio unit index source_track: Source note track index source_region: Source region index dest_unit: Destination audio unit index dest_track: Destination note track index time_offset: Shift all moved notes by N ticks (0 = keep positions) transpose: Transpose all moved notes by N semitones (0 = no change) velocity_scale: Multiply velocity of moved notes (1.0 = unchanged, 0.8 = quieter, 1.2 = louder, clamped to 0-1) delete_source: If True (default), delete notes from source after copy. If False, behaves like copy_notes_to_track. dest_region: Destination region index (-1 = auto-create or append to last)

Returns: JSON with notes_moved, notes_deleted, source_region_cleared, and destination region info.

ParametersJSON Schema
NameRequiredDescriptionDefault
dest_unitYes
transposeNo
dest_trackYes
dest_regionNo
source_unitYes
time_offsetNo
source_trackYes
delete_sourceNo
source_regionYes
velocity_scaleNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It transparently describes the copy+delete behavior, parameter effects (e.g., velocity scale clamped 0-1, time_offset, transpose), auto-creation/appending of destination regions, and the return JSON structure. Missing information includes what happens if the source region is cleared or if destination track doesn't exist, but overall it is quite thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line summary, a contextual paragraph, and a clean Args block. Every sentence provides essential information without redundancy. The format is front-loaded with the core concept, then detailed parameter documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, 5 required) and the presence of an output schema, the description covers the operation well. It explains the return shape and parameter interactions. It could briefly mention prerequisites (e.g., source region must exist) but is largely complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's Args block explains every parameter in detail, including defaults, ranges (velocity_scale clamped 0-1), and behavior (delete_source: 'If True (default), delete notes from source after copy. If False, behaves like copy_notes_to_track'). This adds significant meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Move notes from a source region to another track — copy + delete' and explains the operation as copying notes then optionally deleting originals. It distinguishes from sibling tools like copy_notes_to_track by explicitly mentioning the delete_source flag, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides specific use cases: 'splitting material across tracks, reorganising arrangements, or moving a section to a different instrument.' It contrasts with copy_notes_to_track when delete_source=False. However, it does not explicitly state when not to use this tool, such as if one wants to keep the source intact without copying. Still, the guidance is clear enough for most scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_region_contentA

Shift the content start of a region without moving the region itself.

Moves the content inside the region by delta_beats — adjusts waveform offset (audio) or note positions (MIDI) while keeping the region position. Useful for realigning content within a region after tempo changes.

For audio regions with seconds timeBase, delta is converted via tempo map. For note regions, note positions shift by -delta (content moves left = positive delta).

unit_index: AU index. track_index: Track index within the AU. region_index: Region index. delta_beats: Shift amount in beats (positive = content moves left, region shrinks from left).

Returns new position, duration, and loopDuration, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
delta_beatsYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries full burden. It discloses critical behavior: for audio regions with seconds timeBase, delta conversion via tempo map; for note regions, note positions shift by -delta. It also mentions return values (new position, duration, loopDuration) and error cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose sentence followed by details and bulleted parameters. It is slightly verbose in a couple of sentences, but overall efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has simple parameters and an output schema exists, the description covers key behaviors and returns. It omits prerequisites (e.g., region existence) and side effects, but is largely complete for effective selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description defines each parameter clearly: unit_index, track_index, region_index, and delta_beats with context-specific meaning. This adds significant semantic value beyond the schema's basic types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Shift the content start') and clarifies what the tool does: it moves content inside a region without moving the region itself. It distinguishes from siblings like move_region_to_track or set_region_position by focusing on content shifting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a use case ('useful for realigning content within a region after tempo changes') and explains behavior differences for audio vs note regions. However, it does not explicitly state when not to use this tool or compare to alternatives like move_notes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_region_to_trackB

Move a region from one track to another (possibly in a different audio unit).

The region keeps its position, duration, and content. The source track loses the region.

src_unit_index: Source audio unit index. src_track_index: Source track index within source unit. region_index: Region index within source track. dst_unit_index: Destination audio unit index. dst_track_index: Destination track index within destination unit.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
region_indexYes
dst_unit_indexYes
src_unit_indexYes
dst_track_indexYes
src_track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the region retains its position/duration/content and source loses the region, and that it returns success or error. However, it omits side effects, error conditions, or project state changes beyond the move.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise with 6 sentences, starting with a clear purpose statement followed by a parameter list. No redundant information; well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a mutation tool with no annotations, the description lacks prerequisites (e.g., region/track existence) and does not specify error handling or edge cases. Output schema exists but is minimal; description could provide more context for robust agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates by listing all 5 parameters with brief context (e.g., 'Source track index within source unit'). However, explanations are minimal and lack constraints, ranges, or indexing details that would fully clarify parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it moves a region between tracks, possibly across audio units, and specifies that the region keeps its properties and source loses the region. However, it does not explicitly distinguish itself from similar siblings like 'copy_region_to_track' or 'transfer_region', which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the action is implied to be for moving a region to a different track, there is no explanation of prerequisites, when not to use, or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_sectionA

Move all regions within a beat range to a new position (non-destructive rearrangement).

Scans all tracks across all specified audio units, finds every region that overlaps the [from_beat, to_beat) range, and moves each one to target_beat with the same relative offset. Unlike duplicate_section, this removes the original — a true cut-and-paste operation.

This is the arrangement tool for restructuring: "move the bridge from bar 33 to bar 17" or "shift this 4-bar fill 8 bars earlier". One call replaces N delete + N create sequences.

from_beat: Start of the source section in beats. to_beat: End of the source section in beats (exclusive). target_beat: Where to move the section (beat 0 = start of project). unit_indices: Comma-separated AU indices to scan (default: all AUs).

Returns number of regions moved, per-track details, and old/new positions.

Examples: move_section(from_beat=32, to_beat=48, target_beat=16) -> Move bars 9-12 to bar 5 (shift 16 beats earlier) move_section(from_beat=0, to_beat=16, target_beat=32, unit_indices="0,1") -> Move first 4 bars from AUs 0,1 to beat 32

ParametersJSON Schema
NameRequiredDescriptionDefault
to_beatYes
from_beatYes
target_beatYes
unit_indicesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and details the non-destructive nature, scanning all tracks across audio units, moving with relative offset, and returning counts. It does not fully disclose if automation or other data is moved, or potential limitations, but overall it is highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise first sentence and a clear breakdown of parameters and examples. While somewhat lengthy, every sentence adds value and no extraneous information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (though not shown), the description adequately covers use cases, parameters, and return value summary. It does not address error conditions or edge cases, but for a moderately complex tool, it provides sufficient context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains all four parameters in detail: from_beat, to_beat (exclusive), target_beat (beat 0=start), and unit_indices (default all). Examples further clarify usage, fully compensating for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool moves all regions within a beat range to a new position, specifying it's a cut-and-paste operation. It distinguishes from duplicate_section by noting it removes the original, and provides concrete examples like 'move the bridge from bar 33 to bar 17', making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with duplicate_section and notes it replaces multiple delete+create sequences, giving clear when-to-use guidance. However, it lacks explicit when-not-to-use or prerequisites, though the context is sufficient for an agent to make informed decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_signature_eventA

Move a time signature change event to a new PPQN position.

Automatically recalculates relative positions of subsequent events.

event_index: Index of the signature event (from add_signature_change list). target_ppqn: New position in PPQN.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
event_indexYes
target_ppqnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses a key behavior: 'Automatically recalculates relative positions of subsequent events.' This adds value beyond the simple action of moving a single event, as it informs the agent of side effects. It also mentions the return type 'success or error'. However, it does not describe reversibility, error conditions, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences for the purpose and effect, then a clear parameter list. Every sentence adds essential information without redundancy. The key action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (implying return values are documented elsewhere), the description adequately covers the main action, parameter meanings, and a behavioral note. It is complete enough for an agent to use the tool correctly, though it could mention prerequisites (e.g., the event must exist) or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the input schema has no descriptions for the parameters (0% coverage), the description compensates by explicitly defining both parameters: 'event_index' is described as 'Index of the signature event (from add_signature_change list)' and 'target_ppqn' as 'New position in PPQN.' This adds crucial context about the source of the index and the unit of the position.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Move a time signature change event to a new PPQN position.' The verb 'Move' is specific, and it distinguishes this tool from related siblings like add_signature_change, delete_signature_change, and list_signature_changes by focusing on repositioning an existing event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is given. The description implies that this tool should be used when you need to reposition a signature event and want automatic recalculation of subsequent events, but it does not mention alternatives (e.g., delete and re-add) or conditions under which the tool is inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_move_trackA

Move a track up or down within an audio unit.

Uses AudioUnitBoxAdapter.moveTrack(adapter, delta) — reindexes the track. Delta is relative: -1 = up, +1 = down.

unit_index: AU index. track_index: Track index within AU. delta: Relative move (-1 up, +1 down).

Returns new index or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
deltaYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the underlying method (AudioUnitBoxAdapter.moveTrack) and that it reindexes the track, which gives some behavioral insight. However, it does not disclose side effects like how other tracks' indices shift or whether the change is permanent. The return value is specified as 'new index or error.' This is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using a short opening sentence followed by technical details. It avoids unnecessary words. Each sentence serves a purpose: purpose, implementation mention, parameter explanations, and return. Could be slightly more front-loaded, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward move operation, the description covers what, how, parameters, and return. The output schema likely documents the return format fully. It does not mention prerequisites (e.g., existence of unit/track), but these may be inferred. Overall sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It does so: 'unit_index: AU index', 'track_index: Track index within AU', 'delta: Relative move (-1 up, +1 down).' This adds meaning beyond the bare integer types, specifying valid values for delta and the roles of the indices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Move a track up or down within an audio unit'). The verb 'move' and resource 'track' are explicit. The context 'within an audio unit' distinguishes it from sibling tools like mcp_opendaw_move_audio_unit (moves the unit itself) and mcp_opendaw_move_notes (moves notes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like mcp_opendaw_move_audio_unit or other move tools. Sibling tools exist, but the description does not indicate when this tool is appropriate or when to use other tools instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_note_statsA

Get comprehensive statistics for notes in a region.

Returns a full statistical profile of the MIDI content:

  • Note count, pitch range (min/max/span)

  • Velocity statistics (min/max/mean/median/std)

  • Duration statistics (min/max/mean in beats)

  • Density (notes per beat)

  • Pitch class histogram (how often each of 12 pitch classes appears)

  • Most common pitches (top 5)

  • Time span (first note to last note end)

Useful for:

  • Analyzing imported MIDI before processing

  • Comparing regions (which has more notes, wider range)

  • Identifying register (is this bass, mid, or lead?)

  • Detecting programming issues (all same velocity = robotic)

  • Feeding data to arrangement decisions

unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first region).

Returns statistics object.

Example: stats = note_stats(0, 0)

stats includes: note_count, pitch_range, velocity_stats, density, pitch_class_histogram

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Describes returned data comprehensively but does not explicitly state it is read-only or disclose potential side effects. For a read-only analysis tool, this is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured: concise summary, bullet list of statistics, practical use cases, parameter details, and example. Some repetition (e.g., 'statistics object' in multiple places) but overall efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and presence of output schema, the description thoroughly covers purpose, returned data, parameter roles, and usage examples. Includes edge case for region_index default. No gaps for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (no descriptions in schema), but the description adds meaningful explanations for each parameter: 'unit_index: AU index', 'track_index: Note track index', 'region_index: Region (-1 = first region)'. Includes an example call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Uses specific verb 'Get comprehensive statistics' and resource 'notes in a region'. Clearly distinguishes from sibling analysis tools (e.g., audio analysis tools) by explicitly listing MIDI-specific statistics like pitch class histogram, velocity stats, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a 'Useful for' section with concrete scenarios (analyzing imported MIDI, comparing regions, identifying register, detecting robotic velocities). While it doesn't explicitly state when not to use it, the use cases are clear and practical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_place_audio_regionA

Place a previously loaded audio sample as a region on a track.

sample_id: The ID returned by mcp_opendaw_load_audio. unit_index: Audio unit index (default 0). start_beat: Beat position to place the region. track_index: Track index within the audio unit (default 0).

NOTE: The audio unit must be an instrument AU with a Tape device. Use mcp_opendaw_create_instrument_track first if no instrument AU exists.

ParametersJSON Schema
NameRequiredDescriptionDefault
sample_idYes
start_beatYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action 'place' and a prerequisite constraint, but does not explain side effects, what the tool does to the track (e.g., create or overwrite), or what the output schema returns. This is insufficient for a mutative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (~100 words) and well-structured: a one-sentence summary, followed by parameter details, then a critical note. No redundant or irrelevant information. Front-loaded with the key purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the domain and the number of sibling tools, the description covers prerequisites and parameters but lacks behavioral context (e.g., return value, confirmation, potential errors). An output schema exists but is not mentioned, leaving the agent unaware of what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains all four parameters in a list, adds context for sample_id (origin), and states defaults for unit_index and track_index. This adds meaningful information beyond the schema's bare titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Place'), the resource ('previously loaded audio sample'), and the target ('as a region on a track'). It explicitly links to the prerequisite tool (mcp_opendaw_load_audio) and distinguishes from other creation tools by specifying the need for a loaded sample.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use: after loading an audio sample. It includes a critical note about the required audio unit type (instrument AU with Tape device) and directs to mcp_opendaw_create_instrument_track if absent, effectively telling when not to use and providing an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_ppqn_to_partsA

Convert a PPQN position to musical parts: bars, beats, semiquavers, ticks.

Useful for understanding where a position falls in the musical grid, accounting for time signature changes.

position_ppqn: Position in PPQN (960 = 1 quarter note).

Returns bars, beats, semiquavers, ticks, and the active time signature.

ParametersJSON Schema
NameRequiredDescriptionDefault
position_ppqnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It mentions that the conversion accounts for time signature changes, implying state dependency, and lists return values. However, it does not explicitly state it is a read-only operation or disclose potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear action statement, a brief use-case, parameter description, and return values. Every sentence contributes meaning without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple conversion tool with one parameter and an existing output schema, the description covers the purpose, parameter, and return values adequately. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description's parameter explanation adds value. It gives the unit ('960 = 1 quarter note'), which provides crucial context beyond the schema's type and title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it converts PPQN position to musical parts (bars, beats, semiquavers, ticks), with a specific verb and resource. It distinguishes itself from the sibling tool mcp_opendaw_ppqn_to_seconds, which converts to seconds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says it is useful for understanding where a position falls in the musical grid, accounting for time signature changes. This implies when to use, but does not explicitly exclude alternatives or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_ppqn_to_secondsA

Convert a position in beats (PPQN units) to seconds using the project's tempo map.

Accounts for tempo automation — each segment of the timeline may have a different BPM, so the conversion integrates over tempo change events. 1 beat = PPQN.Quarter = 960 pulses.

position_beats: Position in beats (float, e.g. 4.0 = beat 4).

Returns seconds (float), or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It explains that the tool accounts for tempo automation and integrates over tempo change events, and notes the return type (float or error). However, it does not mention side effects, authorization needs, or edge cases, which is adequate for a simple read-only conversion tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (5 sentences) with a clear structure: purpose, behavior, unit definition, parameter explanation, and return value. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter conversion tool and the presence of an output schema (per context signals), the description covers all necessary aspects: operation, input, account for tempo map, and return type. No additional context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only the parameter name and type; the description adds meaning by specifying the unit (beats), example value (4.0), and context (position in beats). This goes beyond the schema, which has 0% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool's purpose: converting a position in beats (PPQN units) to seconds using the project's tempo map. It defines the unit (1 beat = 960 pulses) and distinguishes the tool from siblings like 'seconds_to_beats' and 'ppqn_to_parts'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool—when conversion accounts for tempo automation and integrates over tempo changes. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for an agent to decide appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_quantize_notesA

Quantize note positions to a grid division.

Snaps each note's start position to the nearest grid line.

division: Grid division — '1/4', '1/8', '1/16', '1/32', or '1/64'. unit_index: Audio unit index (-1 = all AUs). track_index: Specific note track (-1 = all note tracks). strength: 1.0 = full quantize, 0.5 = 50% (keeps some groove).

Returns count of notes quantized.

ParametersJSON Schema
NameRequiredDescriptionDefault
divisionYes
strengthYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains the effect on note positions and the strength parameter, but does not disclose mutation behavior, undoability, or side effects. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise with a clear first sentence and bullet-like parameter explanations. Could be more structured with sections, but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main behavior and return value, but lacks context on error conditions, idempotency, range of index parameters, and whether the operation is reversible. Given no annotations, slightly incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, description adds full meaning for all 4 parameters: division values, unit_index default, track_index default, and strength interpretation. Essential for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'quantize' and the resource 'note positions', and explains it snaps to a grid. It distinguishes itself from sibling tools like 'quantize_velocities' by focusing on positions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives (e.g., 'apply_swing', 'humanize_notes'). Does not mention prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_quantize_velocitiesA

Quantize note velocities to discrete stepped levels.

Snaps each note's velocity to the nearest of N evenly-spaced levels, like MPC 16-level mode or stepped dynamics. Great for creating uniform, robotic feel (techno, industrial) or restoring clean velocity tiers from humanized performance data.

Args: unit_index: Audio unit index (from list_tracks) track_index: Note track index within the unit levels: Number of velocity steps (2-128). 2 = on/off, 4 = pp/p/mf/f, 8 = classical dynamics, 16 = MPC classic, 32 = fine control. mode: "snap" = nearest level, "floor" = round down to level, "ceil" = round up to level, "round_random" = probabilistic round (coins flip for half-values) min_velocity: Floor for the quantized range (0.0-1.0) max_velocity: Ceiling for the quantized range (0.0-1.0) region_index: Specific region to process (-1 = all regions)

Returns: JSON with per-region stats: notes_processed, velocity distribution across levels, original avg, new avg, changes count.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNosnap
levelsNo
unit_indexYes
track_indexYes
max_velocityNo
min_velocityNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It transparently explains the quantizing behavior, modes (snap, floor, ceil, round_random), and parameter effects. It also describes the return format. It does not mention undo capability, but is otherwise thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear one-sentence headline, a short paragraph with analogy and use cases, then a clean argument list, and a return description. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 7 parameters and 2 required, the description covers all parameters and return values. It does not explicitly mention prerequisites (e.g., need a note track with velocities), but that is implied. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description fully documents each parameter with detailed explanations. For example, it defines levels values (2-128) with musical meanings, explains all four modes, and clarifies region_index = -1 means all regions. This adds significant semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Quantize note velocities to discrete stepped levels.' It uses specific verb ('Quantize') and resource ('note velocities'), and includes analogy to MPC 16-level mode, distinguishing it from siblings like scale_velocity or humanize_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides use cases: 'Great for creating uniform, robotic feel (techno, industrial) or restoring clean velocity tiers from humanized performance data.' While not explicitly stating when not to use, it implies appropriate contexts and the analogies help. Could be stronger with explicit exclusion of alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_query_loading_completeA

Check if all audio samples are loaded and ready for playback.

Returns: loaded: true if all samples have finished loading is_ready: true if engine is fully initialized

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description transparently indicates a read-only status check with no side effects, listing return values. Since annotations are absent, the description compensates well, though it could explicitly state non-destructive behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences and a return list, all front-loaded. Every part is useful and no space wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple query tool with an output schema, the description is complete: it explains the purpose and return values. No additional context is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters; the description adds no parameter information, but none is needed. Baseline for 0 parameters is 4, and this is met.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if all audio samples are loaded and ready for playback, and specifies return values. However, it does not distinguish this tool from siblings like get_engine_status or wait_for_condition, leaving potential confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It only states what it does, missing context about when it is appropriate to call or when other tools might be better suited.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_randomize_note_chanceA

Randomize note playback probability (chance) — generative variation.

Sets a random chance value (0-100%) for each note, controlling whether it plays on each run. This is the core of generative MIDI — patterns that are different every time while maintaining structure. Notes with chance=100 always play, chance=50 play half the time, chance=0 never play (silent ghost).

Perfect for:

  • Ghost notes that appear/disappear (drum variation)

  • Generative melodies where notes drop in/out

  • Call-and-response patterns with probabilistic responses

  • Evolving textures that change per iteration

mode: Distribution of chance values:

  • "uniform" — random between min_chance and max_chance, evenly distributed. Each note gets an independent random chance. Default mode.

  • "decreasing" — chance decreases linearly from max to min across the region. First notes are most likely, last notes least. Creates fade-out of probability — pattern dissolves.

  • "increasing" — chance increases from min to max. Pattern emerges from silence. Builds anticipation.

  • "sparse" — most notes get min_chance, but some get max_chance. Creates sparse texture with occasional hits. Good for ghost notes.

  • "binary" — each note gets either min_chance or max_chance (coin flip). Creates stark on/off patterns.

min_chance: Minimum chance value (0-100, default 50). max_chance: Maximum chance value (0-100, default 100). seed: Random seed for reproducibility.

Returns per-track note counts, chance range applied.

Example:

Ghost note variation — 30-80% chance

randomize_note_chance(unit_index=0, track_index=0, min_chance=30, max_chance=80)

Dissolving pattern — high to low

randomize_note_chance(unit_index=0, track_index=2, mode="decreasing", min_chance=0, max_chance=100)

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNouniform
seedNo
max_chanceNo
min_chanceNo
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains chance semantics (0-100%), mode behaviors, and return value (per-track note counts). However, it does not state whether the operation is destructive or reversible, nor if it overwrites or adds to existing chance values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a summary, mode details, parameter list, and examples. Every section adds value without unnecessary repetition. Front-loads the key concept and is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no annotations, and an output schema, the description covers the core functionality well. It explains chance, modes, parameters, return value, and provides examples. Missing explanation for index parameters is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (description does not replicate schema), but the description adds detailed meaning for 4 of 7 parameters (mode, min_chance, max_chance, seed) through explanations and examples. It does not explain unit_index, track_index, or region_index, which are common across tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Randomize note playback probability (chance) — generative variation' and elaborates with specific use cases (ghost notes, generative melodies, etc.). It distinguishes this tool from siblings like randomize_note_durations by focusing on chance/probability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists 'Perfect for:' scenarios (ghost notes, generative melodies, etc.) and details each mode with its intended effect (e.g., 'sparse' for ghost notes). While it lacks an explicit 'when not to use', the guidance is strong and contextual.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_randomize_note_durationsA

Randomize note durations with controllable distribution.

Adds generative variation to note lengths. Unlike humanize_notes (which adjusts timing+velocity), this focuses purely on duration with 5 distribution modes for different musical characters.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) variation: Amount of variation (0.0=no change, 0.3=moderate, 1.0=extreme). Applied as percentage of original duration. distribution: Distribution mode — "uniform" = equal probability across range, "increasing" = durations tend to get longer over time, "decreasing" = durations tend to get shorter over time, "bimodal" = clusters around short and long extremes, "jitter" = small perturbations around original values. min_duration_beats: Minimum duration in beats (0.0625=1/64th, 0.125=1/32nd, 0.25=1/16th). max_duration_beats: Maximum duration in beats (4=whole note, 8=two whole notes). preserve_total: If True, scale all durations so the total summed duration equals the original. Useful for maintaining phrase length. seed: PRNG seed for reproducibility.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNo
variationNo
unit_indexYes
track_indexYes
distributionNouniform
region_indexNo
preserve_totalNo
max_duration_beatsNo
min_duration_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Does not disclose side effects, state changes, reversibility, or error conditions. Only describes parameters and basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose statement, sibling contrast, and parameter block. Distribution mode descriptions are slightly verbose but overall efficient. Front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and existing output schema, the description covers tool function and parameters well. Missing behavioral context but otherwise complete for parameter and usage understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description provides extensive parameter documentation with explanations, defaults, and examples for variation, distribution, min/max durations, and preserve_total. Fully compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'randomize' and resource 'note durations' with explicit differentiation from 'humanize_notes' (which adjusts timing+velocity). Lists 5 distribution modes for musical character, making purpose specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States 'adds generative variation to note lengths' and contrasts with humanize_notes, providing context for when to use. However, does not mention other sibling tools like randomize_note_chance or explicitly state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_redoA

Redo the last undone operation.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It does not disclose behavior when no operation is available for redo, or any side effects. Transparency is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and presence of output schema, the description is complete enough but could elaborate on the redo stack behavior or whether multiple redos are supported.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 params), so schema coverage is 100%. Baseline is 4; description adds no param-related meaning, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool redoes the last undone operation. It uses a specific verb ('Redo') and resource ('last undone operation'). Among siblings like mcp_opendaw_undo, it is clearly distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives like undo. It implies usage after undo but lacks explicit context or when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_reharmonize_progressionA

Reharmonize a chord progression — substitute chords with functionally equivalent alternatives for richer harmony.

Reharmonization is the art of replacing chords while preserving (or enhancing) the harmonic function. This tool applies classical and jazz substitution techniques to transform a progression without changing its fundamental direction.

progression: Hyphen-separated chords (same format as create_chord_pads). "Am-F-C-G" = i-VI-III-VII in A minor. "C-Am-F-G" = I-vi-IV-V in C major.

technique: Substitution technique:

  • "tritone_sub" — Replace V7 with ♭II7 (Db7 for G7). Guide tones (3rd+7th) are shared, creates chromatic bass motion. Jazz standard.

  • "secondary_dominant" — Insert V7 of the target chord before it. e.g. before Am → insert E7 (V7 of Am). Adds forward motion.

  • "diatonic_sub" — Replace with functionally equivalent diatonic chord. I→iii or I→vi (submediant), IV→ii (supertonic). Shares tones.

  • "modal_interchange" — Borrow chords from parallel key (minor↔major). In major: ♭VI, ♭III, ♭VII from natural minor. In minor: IV, II from major. Adds color and emotional depth.

  • "passing_dim" — Insert diminished passing chord for chromatic bass motion between chords a whole step apart. Creates smooth bass lines.

intensity: How many chords to substitute:

  • "light" — substitute 1 chord (the most impactful)

  • "medium" — substitute ~30% of eligible chords

  • "heavy" — substitute all eligible chords

target_chord: Index of specific chord to substitute (0-based). -1 = auto select. Only used for tritone_sub and diatonic_sub.

Returns the reharmonized progression string + per-chord mapping + explanation of each substitution.

Example:

Tritone substitution on a ii-V-I

reharmonize_progression("Dm7-G7-Cmaj7", technique="tritone_sub")

→ "Dm7-Db7-Cmaj7" (G7→Db7, guide tones shared)

Modal interchange on pop progression

reharmonize_progression("C-G-Am-F", technique="modal_interchange")

→ "C-G-Am-Fm" (F→Fm, borrowed from C minor)

Secondary dominants for jazz

reharmonize_progression("C-Am-Dm-G7", technique="secondary_dominant")

→ "C-E7-Am-A7-Dm-G7" (E7 before Am, A7 before Dm)

ParametersJSON Schema
NameRequiredDescriptionDefault
intensityNomedium
techniqueNotritone_sub
progressionNoAm-F-C-G
target_chordNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It details the substitution techniques and return values (reharmonized string + mapping + explanation). However, it lacks information on side effects, error handling, or prerequisites (e.g., valid chord format). It is transparent enough for most use cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a summary sentence, then parameter breakdowns, followed by multiple practical examples. Every sentence adds value, and the examples illustrate usage. It is comprehensive without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple substitution techniques, parameter interactions), the description is highly complete. It covers concept, each technique, parameter meanings, and provides three realistic examples. The return value is described. It meets the high bar for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates. It explains each parameter in detail: progression format with examples, all five techniques with musical explanations, intensity levels with percentages, and target_chord indexing. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Reharmonize a chord progression — substitute chords with functionally equivalent alternatives for richer harmony.' The verb is distinct ('reharmonize'), the resource is specific ('chord progression'), and it differentiates from sibling tools like 'create_chord_progression' or 'modulate_progression' by focusing on substitution rather than creation or modulation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool ('to transform a progression without changing its fundamental direction') and provides context for reharmonization. However, it does not explicitly state when not to use it or compare it to alternatives like 'modulate_progression', leaving some ambiguity for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remix_trackA

Full Suno remix pipeline in one call — analyze → import → harmony → mix → master.

Takes any audio file (from download_audio or local) and creates a complete remix: detect BPM + key → set project tempo → import stems → auto-generate matching chord progression → harmonic arrangement → genre mix → mastering. One call replaces 8-10 individual tool calls.

Steps performed:

  1. analyze_track (BPM + key + mode + LUFS)

  2. set_bpm to detected tempo

  3. import_audio_to_tracks (with stem separation if stem_mode set)

  4. create_progression_from_key (diatonic, style-appropriate)

  5. create_harmonic_arrangement (arp + melody on top of stems)

  6. apply_genre_mix (genre-specific processing)

  7. add_mastering_chain (LUFS target)

After this call, the project is remix-ready — call render_full to export.

filename: Path to audio file (from download_audio or local path). genre: Genre for mix processing (synthwave, house, techno, dnb, trap, etc). style: Progression style (pop, jazz, rock, synthwave, folk, lofi). stem_mode: Stem separation mode ("bs2", "bs4", "bs6") or "" for simple import. master_lufs: Mastering target (-14 Spotify, -10 loud, -16 Apple). add_harmony: If True, generates harmonic layers (arp + melody). Default True. add_counter_melody: If True, adds counter-melody layer. Default False. bars: Arrangement length in bars. Default 8.

Returns: analysis results, tracks created, harmony layers, effects, mastering.

Example:

Full pipeline: Suno → download → remix

chirp_generate → audio_url download_audio(audio_url) → /tmp/track.wav remix_track("/tmp/track.wav", genre="synthwave", style="synthwave", stem_mode="bs6", add_counter_melody=True) render_full() → export

ParametersJSON Schema
NameRequiredDescriptionDefault
barsNo
genreNosynthwave
styleNopop
filenameYes
stem_modeNobs4
add_harmonyNo
master_lufsNo
add_counter_melodyNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It details all 7 steps performed, parameter effects, and return value overview. It does not mention potential side effects on project state or external dependencies (e.g., Suno API), but the level of detail is high and no contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a one-line summary, a numbered step list, parameter explanations, and an example. Each sentence serves a purpose, no redundancy, and the important information is front-loaded. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, pipeline nature), the description covers all necessary aspects: input requirements (audio file), optional parameters with defaults, step-by-step process, output summary, and a concrete usage example linking to sibling tools (download_audio, render_full). The output schema exists, so return values are adequately summarized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description fully compensates. Every parameter (filename, genre, style, stem_mode, master_lufs, add_harmony, add_counter_melody, bars) is explained with type, default, and functional role, adding semantic value beyond the schema's raw property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a 'Full Suno remix pipeline in one call' with a specific verb-resource pair, and distinguishes it from individual step tools by noting it 'replaces 8-10 individual tool calls.' The steps are enumerated, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit usage scenario with a complete example (chirp_generate → download_audio → remix_track → render_full), and mentions post-call action ('call render_full to export'). However, it lacks explicit when-not-to-use guidance or direct alternatives among the many sibling tools, though the pipeline nature implicitly covers this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remove_audio_busA

Remove an FX audio bus and its associated audio unit.

Provide either bus_index (from list_audio_buses) or fx_unit_index (from create_send). Cannot remove the primary output bus (index 0).

bus_index: Bus index to remove (must be > 0, i.e. not primary). fx_unit_index: Alternative — the FX AU index returned by create_send.

ParametersJSON Schema
NameRequiredDescriptionDefault
bus_indexYes
fx_unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool removes an audio unit and cannot remove the primary bus, but does not detail side effects like irreversibility, permissions required, or impact on other routing. This is insufficient for a destructive action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear first sentence stating purpose, followed by parameter details and a constraint. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two parameters, output schema exists), the description covers the key aspects: purpose, identification, and constraint. It could mention the irreversible nature or expected output but is largely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides clear guidance for both parameters: bus_index must be from list_audio_buses and >0, fx_unit_index from create_send. This compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it removes an FX audio bus and its associated audio unit, specifies two identification methods (bus_index or fx_unit_index), and includes a constraint (cannot remove primary bus index 0). It distinguishes from sibling tools like create_audio_bus or remove_send by being the only removal tool for buses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to remove an FX audio bus) and how to identify the bus (from list_audio_buses or create_send). However, it does not explicitly state when not to use it or compare to alternatives like remove_send for removing only the routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remove_effectA

Remove an audio effect from an audio unit's chain.

unit_index: Audio unit index. effect_index: Effect position to remove (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states 'Remove an audio effect' without disclosing behavioral traits like destructive nature, undoability, or chain shuffling. The parameter descriptions add no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences plus two parameter lines. Front-loaded with the main purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description tells what and how to remove, it lacks context about the effect chain behavior (e.g., effects shift), how to obtain indices (e.g., using list_effects), and differentiation from similar remove tools. The existing output schema may supplement return details, but the description is incomplete for a DAW removal operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions), but the description adds meaning by specifying that unit_index is 'Audio unit index' and effect_index is 'Effect position to remove (0-based)'. This clarifies indexing and scope beyond the basic integer type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Remove' and the resource 'audio effect from an audio unit's chain', which distinguishes it from sibling tools like remove_midi_effect (MIDI effects) and remove_audio_bus (buses). The verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as remove_midi_effect or remove_audio_bus. No prerequisites or context provided beyond parameter explanations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remove_midi_effectB

Remove a MIDI effect from an audio unit's MIDI chain.

unit_index: Audio unit index. effect_index: MIDI effect position to remove (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the basic operation. It does not disclose side effects, destructiveness, or what happens to the MIDI chain after removal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one functional sentence and two lines listing parameters. It is front-loaded, though the parameter listing is slightly redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 2 required parameters, both explained, but lacks information about the return value (output schema exists but not shown), prerequisites, and the fact that it is a destructive operation. It would benefit from cross-referencing sibling tools for obtaining indices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaningful explanations: 'Audio unit index' and 'MIDI effect position to remove (0-based)', which clarify the integer parameters beyond the schema's minimal titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Remove', the resource 'MIDI effect', and the context 'from an audio unit's MIDI chain'. It differentiates itself from sibling tools like 'remove_effect' and 'add_midi_effect'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., replace_effect or add_midi_effect), nor does it mention prerequisites like obtaining unit_index and effect_index.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remove_modular_moduleA

Remove a module from a Modular device.

au_index: Audio unit index. effect_index: Effect index within the AU. module_index: Module index to remove.

Returns success or error. All connections to/from this module are also removed.

ParametersJSON Schema
NameRequiredDescriptionDefault
au_indexYes
effect_indexYes
module_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Mentions side effect: 'All connections to/from this module are also removed.' No annotations provided, so description carries burden. Doesn't detail error cases, undoability, or impact on other modules.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise at 6 lines, front-loading purpose then parameters, return, side effect. Could be more structured (e.g., separate paragraphs), but no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and a key side effect. Output schema exists (not shown) but description mentions return. Lacks details on failure modes and preconditions, but adequate for a simple removal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and description provides brief explanations for all three parameters (au_index, effect_index, module_index), adding meaning beyond bare names and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Remove a module from a Modular device.' Uses specific verb (remove) and resource (module from Modular device), distinguishing it from sibling tools like add_modular_module and list_modular_modules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Does not explicitly state when to use or when not to use this tool. Implies usage when removal is desired but lacks alternatives or prerequisites like device existence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_remove_sendA

Remove an aux send from an audio unit.

unit_index: Source audio unit index. send_index: Send index to remove (from list_sends).

ParametersJSON Schema
NameRequiredDescriptionDefault
send_indexYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states the basic removal action without disclosing side effects, authorization needs, or error conditions. For a destructive tool, more context is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and to the point, with two lines separating purpose and parameter explanations. It is efficient but could benefit from a more structured format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose and parameters, but lacks information on error conditions, return values (though output schema exists), and how to use it in conjunction with list_sends. More completeness would be expected for a removal operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description adds value by explaining both parameters: 'unit_index: Source audio unit index' and 'send_index: Send index to remove (from list_sends)'. The note about list_sends is particularly helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Remove' and the resource 'aux send from an audio unit'. It distinguishes from sibling tools like 'create_send' and 'list_sends' by specifying the removal operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description hints at a prerequisite by stating 'send_index: Send index to remove (from list_sends)', implying one should use list_sends first, but does not explicitly provide when to use this tool vs alternatives or mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_rename_unitA

Rename an audio unit's instrument and optionally set its icon.

Instrument AUs have a label (display name) and icon (symbol) on their InstrumentBox. This sets both. The output AU (index 0) has no instrument and cannot be renamed.

unit_index: Audio unit index (must be >= 1, not the output AU). name: New display name (empty = skip). icon: New icon symbol (empty = skip, e.g. 'piano', 'guitar', 'drums').

Returns old and new name/icon.

ParametersJSON Schema
NameRequiredDescriptionDefault
iconYes
nameYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the basic action (renames instrument, optionally sets icon) and the return value (old and new name/icon). However, it does not reveal potential side effects (e.g., whether it triggers a re-render, requires saved state, or is reversible). Given no annotations, more depth would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a summary sentence, context about instrument AUs, parameter details, and return value. Every sentence adds value without redundancy. The use of bullet-like explanation for parameters is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with 3 parameters, the description adequately covers the purpose, constraints, and return value. It lacks discussion of error handling (e.g., invalid unit_index) or prerequisites, but overall is sufficient. The presence of output schema is not an issue since the description mentions the return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains each parameter: unit_index with constraints (must be >=1, not output AU), name and icon with the ability to skip (empty = skip), and provides icon examples. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Rename an audio unit's instrument and optionally set its icon.' It specifies that the output AU (index 0) has no instrument and cannot be renamed, distinguishing it from other similar tools like set_device_label or set_clip_label. The verb 'rename' and resource 'audio unit's instrument' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides constraints on usage (unit_index must be >=1 and not the output AU) and explains that name and icon can be empty to skip. However, it does not explicitly guide when to use this tool versus alternatives like set_device_label or other rename tools. The usage context is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_render_and_analyzeA

Render the current project and run full audio analysis in one call.

Combines export_audio + analyze_mix into a single tool — the feedback loop for iterative mixing. Agent renders, listens, and gets concrete numbers: LUFS, spectrum, stereo, dynamics, and prioritized suggestions.

This is the 'ears' tool. After making mix changes, call this to verify:

  1. Renders project to WAV via offline engine

  2. Runs full mix analysis (LUFS, spectrum, stereo, dynamics)

  3. Returns concrete numbers + prioritized suggestions

filename: Output filename (without .wav extension). sample_rate: Render sample rate (48000 recommended). analysis_depth: "full" (all analyses) or "quick" (LUFS + spectrum only).

Returns analysis JSON with mix_suggestions, master_check, and file path.

Example:

After adjusting mix

result = render_and_analyze("my_mix")

→ {lufs: -14.2, spectrum: {...}, suggestions: [...], file: "..."}

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNorender_analysis
sample_rateNo
analysis_depthNofull

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description outlines the three steps (render, analyze, return) and mentions offline engine, LUFS, spectrum, stereo, dynamics, and suggestions. With no annotations, it partially transparent but lacks disclosure on file persistence, permissions, or side effects of rendering to WAV.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, numbered list, parameter section, and example. It is front-loaded and clear, though slightly repetitive (e.g., 'feedback loop' appears twice) and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and lack of annotations, the description covers core functionality, parameters, and return structure. It lacks details on file location/persistence, error scenarios, and prerequisites, leaving gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds meaningful explanations for all three parameters: filename extension, recommended sample rate, and analysis depth options. It does not provide constraints or enums explicitly but compensates well through descriptive text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool renders the project and runs full audio analysis in one call. It distinguishes itself from siblings by explicitly combining export_audio and analyze_mix, making its purpose as a feedback loop for iterative mixing unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool is the 'ears' tool for verifying mix changes, implying usage after adjustments. It mentions it combines export and analysis, hinting that standalone tools exist for separate tasks. However, it does not provide explicit when-not-to-use scenarios or enumerate alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_render_fullA

Render the entire project as a single stereo WAV file (full mixdown).

filename: Output filename (without .wav extension). sample_rate: Export sample rate (default 48000).

Uses OfflineEngineRenderer with Option.None (no stems config = full mix). Renders from beat 0 to the end of the last region.

Returns the path to the exported WAV and audio metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNofull_mix
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the engine used, the absence of stems configuration, the full project range, and the return value (path and audio metadata). This is reasonably transparent for a render operation, though it does not mention potential side effects or errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short paragraphs. The first sentence clearly states the purpose, followed by parameter explanations and technical details. Every sentence adds value without unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (has_output_schema: true) and two simple parameters, the description is largely complete. It explains the rendering scope, engine, and return value. Minor details like error handling are absent but not critical for a straightforward render tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates by explaining both parameters: filename (without .wav extension) and sample_rate (with default 48000). This adds meaning beyond the schema's titles and defaults, making the tool easier to use correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renders the entire project as a single stereo WAV file (full mixdown). The verb 'render' and resource 'entire project' are specific, and it distinguishes from siblings like render_and_analyze or render_range by emphasizing full mix without stems.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the technical approach (OfflineEngineRenderer with Option.None) and the rendering range (beat 0 to end of last region), but does not explicitly state when to use this tool versus alternatives like render_full_song or render_full_format. Usage context is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_render_full_formatA

Render the entire project and convert to MP3 or FLAC in one step.

filename: Output filename (without extension). sample_rate: Export sample rate (default 48000). format: 'wav' (default), 'mp3', or 'flac'. MP3/FLAC uses system ffmpeg. bitrate: MP3 bitrate for CBR (default '320k'). Ignored for WAV/FLAC.

Combines render_full + convert_audio. Returns both WAV and converted file paths.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNowav
bitrateNo320k
filenameNofull_mix
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It notes that MP3/FLAC conversion uses system ffmpeg and that the tool returns both WAV and converted file paths. However, it does not mention potential side effects, prerequisites (e.g., engine running), or constraints (e.g., project must be fully loaded). Given these gaps, the transparency is moderate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a single-sentence header, a bullet-like param listing, and a summary line. Every sentence provides necessary information without redundancy. It is front-loaded with the core purpose and structured for easy parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and an output schema, the description covers the key aspects: purpose, parameter semantics, the combined operation, and ffmpeg dependency. It lacks mention of prerequisites (e.g., project state) and error handling, but these might be covered by the output schema. Overall, it is fairly complete for a tool of moderate complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain parameters. It does so effectively: clarifies that filename expects no extension, defines default sample_rate (48000), lists format options (wav/mp3/flac) with a note about ffmpeg dependency, and explains that bitrate is ignored for WAV/FLAC. This adds substantial value beyond the schema's default values alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Render the entire project and convert to MP3 or FLAC in one step.' It specifies a concrete action (render+convert) and the resource (entire project). This distinguishes it from sibling tools like mcp_opendaw_render_full and mcp_opendaw_convert_audio, which handle only part of this workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that it combines 'render_full + convert_audio' and lists parameter details, which implicitly guides when to use it (for one-step render and format conversion). However, it does not explicitly state when not to use it (e.g., if only WAV is needed, render_full may be sufficient) or provide alternatives. Guidance is adequate but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_render_full_songA

Render the entire project — auto-detects song length from all regions.

Scans all note and audio regions across all tracks to find the latest ending point, then renders from beat 0 to that point plus a configurable tail for reverb/delay tails. No manual beat counting needed.

This closes the pipeline gap: after create_song_with_variations (or any arrangement tool), call render_full_song to get the final WAV.

filename: Output filename (without .wav extension). sample_rate: Export sample rate (default 48000). tail_beats: Extra beats at the end for reverb/delay tails (default 4 = 1 bar).

Returns the path to the exported WAV, song duration in seconds, and audio metadata (peak, has_audio).

Example:

After building a song

create_song_with_variations("dnb") render_full_song(filename="my_dnb_track")

Shorter tail for tight electronic

render_full_song(filename="techno_mix", tail_beats=2)

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNofull_song
tail_beatsNo
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. It explains auto-detection of song length, scanning all regions, rendering from beat 0 to end plus configurable tail. Discloses return values (path, duration, metadata). Lacks details on empty project behavior, but overall transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured: what it does, how it works, pipeline usage, parameters, and examples. Front-loaded with purpose, no superfluous sentences. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 optional parameters and existence of output schema (inferred from context), description covers core functionality, usage, and return information. Does not mention error conditions or prerequisites like having a project loaded, but is still fairly complete for a render tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description provides clear explanations for all three parameters: filename (without .wav), sample rate, tail_beats (purpose and default). Adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it renders the entire project, auto-detects song length by scanning all regions. Differentiates from siblings like render_range by being the full render tool. Verb 'render' + resource 'full song' is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says it closes the pipeline gap after arrangement tools like create_song_with_variations, with examples showing different tail_beats for different genres. Does not explicitly mention alternatives for partial renders, but context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_render_rangeA

Render only a portion of the project (e.g. chorus only) for quick A/B comparison.

start_beat: Start position in beats (0 = project start). end_beat: End position in beats. filename: Output filename (without .wav extension). sample_rate: Export sample rate (default 48000).

Uses OfflineEngineRenderer with custom range. Faster than full export for checking specific sections during mixing.

Returns the path to the exported WAV and audio metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_beatYes
filenameYes
start_beatYes
sample_rateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that it uses 'OfflineEngineRenderer with custom range' and returns 'the path to the exported WAV and audio metadata'. This provides useful behavioral context, though it could mention if overwriting existing files is possible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: 6 lines covering purpose, parameters, and return value. It is front-loaded with the main use case and parameter list, with no wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (4 parameters, required 3, no enums) and the existence of an output schema, the description is complete. It explains the purpose, parameters, return value, and speed advantage. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description lists all parameters with brief explanations (e.g., start_beat: 'Start position in beats (0 = project start)', filename: 'without .wav extension'). This adds meaning beyond the schema, which only has titles, and compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'render', the resource 'portion of the project', and the purpose 'quick A/B comparison'. It differentiates from sibling tools like mcp_opendaw_render_full by specifying that it renders only a part, not the whole project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Faster than full export for checking specific sections during mixing', which provides clear usage context. It implies that full export is the alternative, although it doesn't directly name the sibling tool. The guidance is sufficient for an agent to decide when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_reorder_sectionsA

Reorder song sections — rearrange blocks on the timeline.

Takes a list of section boundaries and rearranges them into a new order. Each section is defined by its start and end beat. The tool collects all note content from each section, then places them in the specified new order, back-to-back, starting from the first section's original start position.

This is the full song structure editor: instead of swapping two sections (swap_sections), you can completely rearrange the form. Turn verse-chorus-verse-chorus-bridge-chorus into chorus-verse-bridge-chorus-verse-chorus in one call.

section_order: JSON array of section objects, each with "start" and "end" beat positions, listed in the NEW desired order. Example: '[{"start":0,"end":8},{"start":16,"end":24},{"start":8,"end":16}]' This takes sections at [0-8], [16-24], [8-16] and places them in that order, starting at beat 0.

Sections can overlap in the original but not in the output — they are placed sequentially. Section lengths are preserved.

unit_indices: Comma-separated unit indices to process ("" = all units).

Returns sections reordered, notes moved per unit, new section layout.

Example:

Move chorus to front

reorder_sections('[{"start":16,"end":32},{"start":0,"end":8},{"start":8,"end":16}]')

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indicesNo
section_orderYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details how sections are collected, placed sequentially, and that lengths are preserved. No annotations provided, so the description bears full burden and does it well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, explanation, contrast, parameter details, and example, though slightly lengthy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers parameters, return values, and example; missing error conditions or project impact details, but adequate given output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fully explains both parameters: section_order as a JSON array with start/end beats and example, unit_indices as comma-separated indices or empty for all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Reorder song sections — rearrange blocks on the timeline' and contrasts with swap_sections, making it distinct among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when to use this tool vs swap_sections with an explicit example, but does not cover all alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_repeat_notesA

Repeat existing notes in a region N times with per-repeat transformations.

Takes the notes already in the region and copies them repeats times, each copy offset in time, pitch, and velocity. Unlike create_midi_echo (which decays feedback repeats), this tool preserves note structure and applies a uniform transform per repeat cycle — ideal for sequences, ostinato patterns, and motivic development.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) repeats: Number of repeat cycles (1-16, each cycle = full copy of source notes) transpose_semitones: Semitones added per repeat cycle (0=same, 12=octave up, -12=octave down, 7=fifth up). Cumulative. velocity_decay: Velocity multiplier per repeat (0=fade out, 1=constant, 0.8=gradual fade). Applied cumulatively. time_gap_beats: Extra gap between repeats in beats (0=back-to-back, 0.5=half-beat rest between cycles) direction: Transpose direction — "up" or "down" (affects sign of transpose) dest_track_index: Destination track (-1 = same track)

ParametersJSON Schema
NameRequiredDescriptionDefault
repeatsNo
directionNoup
unit_indexYes
track_indexYes
region_indexNo
time_gap_beatsNo
velocity_decayNo
dest_track_indexNo
transpose_semitonesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses that notes are copied, transforms (time, pitch, velocity) are applied cumulatively per repeat, and structure is preserved. However, it does not explicitly state whether the source region is modified or if the operation is reversible, which would increase transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise summary paragraph followed by a clear Args list. Every sentence adds distinct value without redundancy. No fluff exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no annotations, and an output schema (so return values not needed), the description covers all parameters with examples, defaults, and cumulative behaviors. It also compares to a sibling tool, making the context complete for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates fully. Every parameter is explained with default values, valid ranges (e.g., repeats 1-16), cumulative effects (transpose_semitones, velocity_decay), and behavioral details (direction affects sign). The Arg block adds meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool repeats notes N times with per-repeat transformations, includes the specific verb 'repeat', identifies the resource as 'notes in a region', and distinguishes from create_midi_echo by highlighting differences in decay versus uniform transform. Use cases like sequences and ostinato patterns further clarify purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts this tool with create_midi_echo, indicating when to use it (preserving note structure, uniform transforms) versus alternatives (decaying feedback). It implies usage for sequences and motivic development but does not provide explicit when-not-to-use scenarios or prerequisites beyond the required parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_repeat_phraseA

Repeat a melodic phrase N times with transposition — melodic sequence.

A sequence is one of the most powerful development techniques in Western music: repeat a melodic idea at different pitch levels. Each repetition is transposed by a fixed interval, creating a chain of related but evolving phrases.

Unlike repeat_notes (which repeats individual notes), create_sequence copies an entire phrase — all notes in the source region — and places each copy after the previous one, transposed and optionally with velocity and timing transformations.

Diatonic transposition moves through the scale (preserving scale membership), while chromatic transposition shifts by exact semitones. Sequences can ascend or descend, accelerating or decelerating.

Bach fugues, jazz ii-V-I chains, pop chorus lifts, film score ostinato builds, and minimalistic pattern music all use sequences.

Args: unit_index: Audio unit index track_index: Note track index with source phrase region_index: Region index (-1 = first region) repetitions: Number of sequence copies (2-16, default 4). Each copy is placed after the previous one in time. transpose_semitones: Transposition interval per repetition (1-12, default 2 = step). Positive = ascending, negative = descending. Used as scale steps in diatonic mode, exact semitones in chromatic mode. transpose_mode: Transposition method — "diatonic": move through scale (preserves scale membership) "chromatic": shift by exact semitones (may leave scale) scale: Scale for diatonic transposition ("major", "minor", "dorian", "phrygian", "lydian", "mixolydian", "locrian", "harmonic_minor", "melodic_minor", "pentatonic", "blues", "chromatic") root: Root note for scale velocity_pattern: Velocity transformation across repetitions — "constant": same velocity as source "crescendo": linear ramp from velocity_start to velocity_end "decrescendo": linear ramp from velocity_end to velocity_start "fade_out": each repetition softer than previous "build": exponential increase, climax at last repetition velocity_start: Starting velocity (0-1, default 0.8) velocity_end: Ending velocity (0-1, default 0.8) time_stretch: Duration multiplier per repetition (0.5-2.0, default 1.0 = same duration). 0.5 = accelerating, 2.0 = slowing down. Creates rhythmic sequences. cross_track: If >= 0, place sequences on this track index instead of source track (preserves original phrase).

ParametersJSON Schema
NameRequiredDescriptionDefault
rootNoC
scaleNomajor
unit_indexYes
cross_trackNo
repetitionsNo
track_indexYes
region_indexNo
time_stretchNo
velocity_endNo
transpose_modeNodiatonic
velocity_startNo
velocity_patternNoconstant
transpose_semitonesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It thoroughly explains core behaviors: copying an entire phrase, transposing, placing copies sequentially, and details on velocity patterns, time stretch, and cross-track placement. It does not mention authentication or rate limits, but these are less critical for a DAW tool. The behavioral disclosure is comprehensive and clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a concise summary and well-structured. It includes a brief conceptual explanation, differentiation, parameter details, and musical context. While the historical references (Bach fugues, etc.) add depth, they could be trimmed. Overall, it is appropriately detailed without excessive verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 13 parameters and domain-specific concepts, the description provides nearly complete guidance. It covers all transformations and parameter effects. An output schema exists, so return values need not be detailed. Lacks details on error conditions or prerequisites (e.g., existence of source region), but these are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. The 'Args:' section explains all 13 parameters with defaults, allowed values, and contextual meaning. Each parameter's role and effect is clearly described, adding significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Repeat a melodic phrase N times with transposition — melodic sequence.' It specifies the verb (repeat), resource (melodic phrase), and key action (with transposition). It effectively distinguishes this tool from repeat_notes and create_sequence, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts this tool with repeat_notes ('Unlike repeat_notes...'), providing clear guidance on when to use it over that sibling. It also explains the difference between diatonic and chromatic transposition, helping users choose the appropriate mode. However, it does not provide explicit 'when not to use' scenarios or additional alternatives beyond the one comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_replace_from_presetA

Replace an audio unit's instrument/effects/timeline from a preset.

Uses PresetDecoder.replaceAudioUnit — swaps the instrument in an existing AU, optionally keeping the target's MIDI effects, audio effects, and/or timeline. The preset must contain a compatible instrument type (MIDI→MIDI, Audio→Audio).

unit_index: Target AU index to replace. preset_b64: Base64 preset bytes from export_preset. keep_midi_effects: If true, keep target's existing MIDI effects. keep_audio_effects: If true, keep target's existing audio effects. keep_timeline: If true, keep target's existing tracks/regions/notes.

Returns success or error with reason.

ParametersJSON Schema
NameRequiredDescriptionDefault
preset_b64Yes
unit_indexYes
keep_timelineNo
keep_midi_effectsNo
keep_audio_effectsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description alone must disclose behavior. It explains the swapping action and optional preservation of effects/timeline, but does not detail side effects (e.g., whether the preset is consumed, if the unit is modified in place) or error conditions beyond 'success or error'. The output is not described, though an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence summary, a technical reference, a precondition, and a clean parameter list. It is concise with no wasted words, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no annotations, many siblings), the description covers the essential: purpose, parameters, precondition. It is sufficient for an agent to invoke the tool correctly. However, it could provide more detail on the return value (though an output schema exists) and error scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It does so by providing clear, contextual explanations for each parameter: unit_index ('Target AU index'), preset_b64 ('Base64 preset bytes from export_preset'), and the three boolean keep flags with their effects. This adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Replace an audio unit's instrument/effects/timeline from a preset'), specifies the method (Uses PresetDecoder.replaceAudioUnit), and distinguishes from generic replace tools by emphasizing preset-based replacement. It also notes compatibility constraints (MIDI→MIDI, Audio→Audio).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: when replacing an audio unit's instrument from a preset while optionally keeping certain elements. It specifies a precondition (compatible instrument type), but does not explicitly mention alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_replace_instrumentA

Replace the instrument on an audio unit with a different MIDI instrument.

Uses ProjectApi.replaceMIDIInstrument — deletes the old instrument and creates a new one on the same AU. Only works for MIDI instruments (Nano, Vaporisateur, Soundfont, Apparat). Tape (audio player) cannot be replaced this way.

The AU must have a CaptureMidiBox (i.e. it was created as a synth/note instrument, not an audio track).

unit_index: Audio unit index (must be >= 1). new_instrument: Factory key — 'Vaporisateur', 'Nano', 'Soundfont', 'Apparat'.

Returns old and new instrument type.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
new_instrumentYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it deletes old instrument and creates new one, returns old/new types. Specifies preconditions (CaptureMidiBox) and limitations (not for tape). Lacks details on side effects like preservation of effects or automation, but given no annotations, this is thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is compact with no redundant sentences. Starts with action, then API, then constraints, then parameters. Could benefit from bullet points for parameters, but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, constraints, parameters, return value, and distinguishes from dozens of siblings. Despite no annotations, provides all information needed for an agent to decide and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Compensates for 0% schema coverage by explaining unit_index must be >=1 and listing exact factory keys for new_instrument. Provides valid values and constraints, enabling correct tool invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it replaces the instrument on an audio unit with a different MIDI instrument. Specifies the API used and constraints on instrument types (only MIDI, not tape), distinguishing it from create/manage instrument siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when to use (replace MIDI instrument) and constraints (only for specific instruments, AU must have CaptureMidiBox). Does not explicitly contrast with alternatives like replace_from_preset, but constraints effectively guide usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_reset_playfield_paramsA
Destructive

Reset all parameters of a Playfield drum sample to defaults.

Resets mute, solo, exclude, polyphone, pitch, attack, release, sampleStart, sampleEnd, gate to their default values.

unit_index: AU index containing the Playfield. sample_index: Sample slot index to reset.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
sample_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the list of parameters reset but does not elaborate on side effects or reversibility. It adds minimal extra context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the main action, and efficiently lists parameters. No redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description doesn't need to explain return values. It adequately covers what the tool does and the required parameters. It could be slightly improved by explicitly stating it resets all playfield parameters of the sample, but it is still clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description fully explains both parameters (unit_index and sample_index) with clear purpose. This compensates completely for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resets all parameters of a Playfield drum sample to defaults and lists the specific parameters affected (mute, solo, etc.). It distinguishes the tool from siblings by specifying the reset action on a sample's playfield.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like setting individual parameters. The description does not mention when a reset is appropriate or when to avoid it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_reset_projectA
Destructive

Reset the project to a fresh state — removes all audio units, tracks, regions, effects.

Useful for starting a new mix session without reloading the browser. The output audio unit is preserved (required for audio routing).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructiveHint annotation, it details exactly what is removed (audio units, tracks, regions, effects) and notes the output audio unit is preserved. This adds significant behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a note, all front-loaded with the main purpose. Every sentence adds value with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, annotations cover destructiveness, and description explains effects and use case, the information is complete. Output schema exists but description doesn't need to cover it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters, the description adds context about the tool's effect but doesn't need parameter details. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resets the project to a fresh state, removing all audio units, tracks, regions, and effects. The verb 'reset' and resource 'project' are specific, and the destructive nature distinguishes it from creation or loading tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Useful for starting a new mix session without reloading the browser,' providing clear context. However, it does not explicitly mention when not to use it or list alternatives like load_project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_reverse_notesB

Reverse the order of notes in a region — retrograde variation.

Swaps note positions so the last note becomes first and vice versa. Durations and velocities are preserved; only positions are mirrored.

unit_index: AU index. track_index: Note track index. region_index: Region index (-1 = all regions on the track).

Returns count of notes reversed.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully states that durations and velocities are preserved and that only positions are mirrored. It also notes the return value (count of notes reversed). However, it does not specify if the operation is destructive, reversible, or how it handles invalid inputs. Given the absence of annotations, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise: four sentences plus a parameter list. The first sentence restates the name, but the following sentences add essential behavioral info. The structure is clear, with the parameter definitions separated. Could be slightly tighter by merging redundant statements, but overall well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has three parameters and no annotations. The description explains the parameters' meanings and the return value. However, it does not address edge cases, error handling, or prerequisites (e.g., does the region need to contain notes?). The output schema exists but the description covers the return value. Overall, it is adequately complete for a tool of this simplicity but leaves some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (no descriptions in the schema itself), but the tool description provides meaningful explanations for all three parameters: unit_index, track_index, and region_index (with the special value -1 for all regions). This adds significant value beyond the raw schema, helping the agent understand the exact parameters and their roles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reverses note order in a region ('Reverse the order of notes in a region — retrograde variation'). It specifies what is swapped (positions) and what is preserved (durations, velocities). While it does not explicitly differentiate from sibling tools like shuffle_notes or rotate_notes, the purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but provides no guidance on when to use it versus alternatives. There is no mention of prerequisites, expected inputs, or scenarios where this tool is preferred over other note manipulation tools. The agent is left to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_rotate_notesA

Rotate notes in a region by N positions (cyclic shift).

Shifts notes cyclically — the first rotate_by notes move to the end, and the remaining notes shift left to fill the gap. This is a fundamental compositional technique used in serialism (rotational arrays — Berg, Webern), jazz melodic variation, and pattern transformation in electronic music.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) rotate_by: Number of positions to rotate (positive = left shift, negative = right shift). Wrapped modulo note count. axis: Rotation axis — "position" = rotate note order by position (notes keep pitch, positions are reassigned in rotated order), "pitch" = rotate pitches (positions stay, pitches shift cyclically among the notes), "both" = rotate both position and pitch together (true permutation — notes swap places entirely). preserve_pitch_contour: If True, after rotation adjust pitches to maintain the original melodic contour (interval sequence). Useful for melodic rotation that stays singable.

ParametersJSON Schema
NameRequiredDescriptionDefault
axisNoposition
rotate_byNo
unit_indexYes
track_indexYes
region_indexNo
preserve_pitch_contourNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explains cyclic shift behavior, direction (positive=left, negative=right), modulo wrapping, and the effect of each axis value. It also describes the preserve_pitch_contour option. However, it does not explicitly state whether the operation is in-place or returns a result, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence summary, a detailed explanation of the operation, usage contexts, and a clear Args list. It is longer than necessary but every sentence adds value. The front-loading is good, with the core operation immediately stated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no annotations), the description covers the tool's behavior and all parameters adequately. An output schema exists but is not described, which is acceptable because the schema provides that information. The description is complete enough for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: for each parameter (axis, rotate_by, unit_index, track_index, region_index, preserve_pitch_contour) it explains meaning, default values, and constraints (e.g., rotate_by wrapped modulo note count, region_index -1 meaning first region). This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool rotates notes in a region cyclically. It specifies the verb ('rotate'), resource ('notes in a region'), and operation ('cyclic shift'). The explanation of how the shift works (first rotate_by notes move to end) and the mention of compositional techniques distinguish it from siblings like shuffle_notes or reverse_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage contexts: serialism, jazz melodic variation, and electronic music pattern transformation. It gives practical guidance on when to use the tool but does not explicitly state when not to use it or suggest alternatives. This is sufficient for most agents.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_save_effect_presetA

Save an audio effect chain as a .opb preset file.

Encodes the specified effect (and its position in the chain) into an openDAW preset bundle (.opb) using PresetEncoder.encodeEffects(). The file can be shared, drag-and-dropped into openDAW, or loaded via mcp_opendaw_load_effect_preset.

unit_index: Audio unit index containing the effect. effect_index: Index of the effect within the unit's audio effect chain. name: Preset name (shown in preset browser). description: Optional description of what the preset does. output_path: Directory to save the .opb file. Defaults to OPENDAW_EXPORT_DIR or /tmp.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
unit_indexYes
descriptionNo
output_pathNo
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It explains encoding using PresetEncoder.encodeEffects() but does not disclose side effects, error conditions, or permission requirements. Adequate but could be more thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with main action, then encoding detail, usage, and parameter list. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, encoding, usage, and parameters. Lacks info on validation or format requirements (e.g., .opb extension), but output schema exists so return values are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds one-line explanations for all 5 parameters, clarifying their roles beyond the schema's type info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Save' and resource 'audio effect chain as .opb preset file'. It distinguishes from sibling tool mcp_opendaw_load_effect_preset which loads presets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context for usage: sharing, drag-and-drop, or loading via load_effect_preset. Lists required parameters but does not explicitly exclude alternative save tools like export_preset.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_save_projectA

Save the current project state to a binary file.

Serializes the boxGraph (all tracks, regions, effects, notes, settings) to an ArrayBuffer and saves it as a .odaw file in the exports directory. Use load_project to restore later.

filename: Name for the saved project (without extension). Returns: file path, size, and box count.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that it serializes all tracks, regions, effects, notes, settings to an ArrayBuffer and saves to exports directory. It also states the return values: file path, size, and box count. However, it does not specify overwrite behavior or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences: purpose, serialization details, companion tool reference, and parameter/returns note. It is concise and front-loaded, with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (saving entire project), the description covers: what is serialized (boxGraph), output format (.odaw), location (exports directory), parameter detail (no extension), return values (path, size, box count), and complementary restore tool. Even with an output schema present, the description provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'filename' is described as 'Name for the saved project (without extension).' This adds crucial meaning beyond the schema, which only provides a title and type string. Since schema coverage is 0%, the description fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Save the current project state to a binary file.' It specifies the verb 'Save', the resource 'project state', and the format '.odaw file'. It also distinguishes itself from sibling tool 'load_project' by mentioning it as the complementary load operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that it serializes the entire boxGraph and saves as .odaw file, and explicitly suggests using load_project to restore later. This gives clear when-to-use context and a sibling tool reference, but does not mention when not to use or alternatives like export_mix or export_stems.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_scale_durationsA

Scale the duration of all notes in a region — MIDI note length control.

Like scale_velocity but for note durations. Multiply, set, add, quantize, or snap to grid. Useful for changing articulation globally — make all notes shorter (staccato feel), longer (legato feel), or snap to a grid.

mode: How to scale durations:

  • "multiply" — multiply each note's duration by value (0.5 = half length, 2.0 = double). Clamped to min/max.

  • "add" — add value (in beats) to each duration. Clamped.

  • "set" — set all durations to value (in beats).

  • "quantize" — snap each duration to the nearest grid division. value = grid in beats (0.25 = 16th, 0.5 = 8th, 1.0 = quarter).

  • "legato" — extend each note to just before the next note's start. value = gap fraction (0.0 = touch next note, 0.1 = 10% gap before next).

value: The scaling parameter (meaning depends on mode). region_index: Region index (-1 = first region). min_duration / max_duration: Clamp range in beats. quantize: Grid for quantize mode ("16th", "8th", "quarter", "half") — overrides value if mode="quantize".

Returns count of notes modified, original and new duration stats.

Example:

Make everything half length (staccato feel)

scale_durations(0, 0, mode="multiply", value=0.5)

All notes to quarter note length

scale_durations(0, 3, mode="set", value=1.0)

Snap durations to 16th grid

scale_durations(0, 0, mode="quantize", quantize="16th")

Legato — extend to next note with small gap

scale_durations(0, 1, mode="legato", value=0.1)

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNomultiply
valueNo
quantizeNonone
unit_indexYes
track_indexYes
max_durationNo
min_durationNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It details transformation logic for each mode and mentions return values ('Returns count of notes modified, original and new duration stats'). However, it does not disclose if the operation is destructive or reversible, nor any prerequisites like region existence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headings and examples, front-loading the purpose. While it is relatively long, every sentence adds necessary detail for a complex tool. Minor redundancy could be trimmed, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 0% schema coverage, and no annotations, the description is remarkably comprehensive. It covers all parameter semantics, modes, and includes examples. The output schema exists and description mentions the return value, so no gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% parameter description coverage, so the description must compensate. It thoroughly explains all 8 parameters, including modes with 5 options, value semantics per mode, region_index, min/max_duration, quantize grid, and provides clear examples. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Scale the duration of all notes in a region — MIDI note length control.' It explicitly distinguishes from sibling tool scale_velocity by stating 'Like scale_velocity but for note durations,' making the action specific and differentiating it from nearby similar tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use the tool: 'Useful for changing articulation globally — make all notes shorter (staccato feel), longer (legato feel), or snap to a grid.' It doesn't explicitly state when not to use it, but the comparative mention with scale_velocity implies alternatives for velocity scaling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_scale_velocityA

Scale the velocity of all notes in a region — MIDI dynamics control.

Unlike create_crescendo (which creates a gradient from start to end), this uniformly scales all existing velocities. Think of it as gain for MIDI dynamics — boost, attenuate, normalize, or compress the velocity range of an entire track or region.

mode: How to scale velocities:

  • "multiply" — multiply each velocity by value (1.0 = no change, 0.8 = 20% quieter, 1.2 = 20% louder). Clamped to 0-1.

  • "add" — add value to each velocity (0.1 = louder, -0.1 = quieter). Clamped to 0-1.

  • "set" — set all velocities to value (0.8 = uniform velocity).

  • "normalize" — scale all velocities so the maximum equals value (0.95 = normalize to 95% max). Preserves relative dynamics.

  • "compress" — compress velocity range around midpoint. value = ratio (0.5 = halve the dynamic range, 1.0 = no change). Pulls extremes toward center — makes quiet notes louder, loud notes quieter.

value: The scaling parameter (meaning depends on mode). region_index: Region index (-1 = first region). min_velocity / max_velocity: Clamp range (0-1). Use to limit extremes.

Returns count of notes modified, original velocity range, new range.

Example:

Make drums 20% quieter

scale_velocity(0, 0, mode="multiply", value=0.8)

Normalize melody to 95% max velocity

scale_velocity(0, 3, mode="normalize", value=0.95)

Compress velocity range — reduce dynamics

scale_velocity(0, 0, mode="compress", value=0.6)

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNomultiply
valueNo
unit_indexYes
track_indexYes
max_velocityNo
min_velocityNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist. The description details the behavior for each mode, clamping to 0-1, and states return values (count, original range, new range). Missing permission or undo implications, but overall transparent for a velocity scaling tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary, contrast, mode explanations, parameter list, returns, and examples. It is slightly long but efficient; every sentence adds value. Could be more concise but front-loads purpose effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters and 5 modes, the description covers purpose, all mode semantics, parameter roles, return values, and examples. It lacks error conditions or edge cases, but for a velocity scaling tool it is comprehensive. Output schema exists but description adds value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains mode options (multiply, add, set, normalize, compress) with semantics, clarifies value depends on mode, describes region_index/ min/max_velocity clamp, and provides examples. This adds substantial meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scales velocity of all notes in a region, using specific verb and resource. It explicitly distinguishes from the sibling tool create_crescendo, making the unique purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contrasts with create_crescendo and explains the uniform scaling nature, but does not cover when to use alternatives like apply_velocity_curve or quantize_velocities. It provides mode explanations that guide usage, but lacks explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_schedule_clip_playB

Schedule clips to play in session view (live triggering).

Args: clip_ids: Comma-separated list of clip UUIDs to trigger

ParametersJSON Schema
NameRequiredDescriptionDefault
clip_idsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It states clips are scheduled to play but does not disclose whether playback is immediate, how scheduling works (e.g., at next bar), what happens to currently playing clips, or potential side effects. The tool's behavior remains vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two sentences, front-loading the core function. It avoids unnecessary details. A minor improvement could be structuring the parameter description more explicitly, but it is efficient for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and a straightforward action, the description covers the basics: what it does and what input it expects. However, it lacks information about return values (output schema exists but is not referenced) and error conditions. It is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add meaning. It specifies that clip_ids is a 'Comma-separated list of clip UUIDs to trigger', which clarifies format and purpose. However, it does not explain UUID format or error handling for invalid IDs, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('schedule clips to play'), the resource ('clips'), and the context ('session view (live triggering)'). It distinguishes the tool from siblings like 'schedule_clip_stop' and 'set_clip_playback' by specifying live triggering in session view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not mention when to use this tool over alternatives, prerequisites (e.g., clips must exist), or contexts where it is inappropriate. This leaves the agent without guidance on proper invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_schedule_clip_stopB

Schedule clips to stop on specified tracks (session view).

Args: track_ids: Comma-separated list of track UUIDs to stop clips on

ParametersJSON Schema
NameRequiredDescriptionDefault
track_idsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether scheduling a stop overrides existing schedules, whether clips must be already playing, or any side effects. The description is too minimal for an operation that involves scheduling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with two sentences. It front-loads the purpose and follows with parameter documentation. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a scheduling action with a single parameter and an output schema, the description covers the basics but is incomplete. It lacks explanation of the scheduling behavior (e.g., timing, overlap) and does not help the agent understand when to prioritize it over related tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It explains 'track_ids' as a 'Comma-separated list of track UUIDs to stop clips on', which adds meaning beyond the type. However, it lacks details like how to obtain UUIDs or whether the list is validated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Schedule clips to stop on specified tracks (session view)'. It includes the verb 'schedule', the resource 'clips to stop', and the context 'session view'. This distinguishes it from its sibling 'mcp_opendaw_schedule_clip_play'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the description indicates the basic use case (scheduling stops), it provides no guidance on when not to use this tool, such as for immediate stop, or alternatives like using transport controls. There are no exclusions or comparisons to other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_screenshot_dawA

Take a screenshot of the openDAW UI. Returns base64-encoded PNG image. Useful for visual debugging and verifying project state.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries full burden. It clearly states the action (screenshot) and output (base64 PNG), implying a read-only, non-destructive operation. It lacks details like potential performance impact or that it captures the current visible state, but is sufficient for understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two short, essential sentences. No extraneous words. Information is front-loaded: action, resource, output, use case. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, an output schema is provided, and the description covers purpose, output format, and use case. It is complete and sufficient for an agent to select and invoke the tool without additional clarification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so per guidelines baseline is 4. The description does not need to add parameter information as schema coverage is 100% and no parameters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Take a screenshot', the specific resource 'openDAW UI', and the output format 'base64-encoded PNG image'. This is distinct from all sibling tools, which are about editing, creating, or analyzing audio/DAW elements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context 'useful for visual debugging and verifying project state', which helps the agent understand when to use it. However, it does not explicitly state when not to use it or list alternatives, though no direct alternatives exist among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_seconds_to_beatsA

Convert a time in seconds to beats using the project's tempo map.

Accounts for tempo automation. Useful for aligning audio regions to the musical grid when tempo changes mid-song.

seconds: Time in seconds (float).

Returns beats (float) and PPQN position, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
secondsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully handles behavioral transparency. It explicitly states that the tool accounts for tempo automation and returns beats, PPQN position, or error. This is sufficient for a simple conversion tool, though additional details like precision or edge cases could be added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short, front-loaded sentences: a clear purpose, a use-case, and parameter/return info. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and a simple behavior, the description covers input, behavior (tempo map usage), and output (beats, PPQN, error). An output schema exists (though not shown), so the description doesn't need to detail return structure. Complete for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'seconds' is described as 'Time in seconds (float)', adding meaning beyond the schema (which has 0% coverage). It specifies type and unit. Could be improved by noting positive values or default behavior, but it provides solid semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Convert') and resource ('seconds to beats'), and distinguishes itself from siblings like ppqn_to_seconds by specifying it uses the project's tempo map and accounts for tempo automation, making its unique purpose explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: 'Useful for aligning audio regions to the musical grid when tempo changes mid-song.' It implies the context (tempo automation) but does not explicitly state when not to use it or provide direct alternatives, though the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_separate_stemsA

Separate audio into stems using SOTA AI models — SCNet, BS-Roformer, PolarFormer.

Uses the creative-studio stem-splitter pipeline (much better than Demucs alone). Models available:

  • "ensemble": Max quality — HTDemucs FT + PolarFormer vocals + BS-Roformer (3 passes)

  • "scnet": SCNet XL — best 4-stem (drums, bass, other, vocals), SDR 10.08

  • "bs6": BS-Roformer 6-stem (bass, drums, other, vocals, guitar, piano) — fast

  • "polarformer": Best vocal extraction (vocals + instrumental), SDR 11.00

  • "dereverb": Remove reverb from vocals (dry + reverb)

  • "drumsep": Separate drums into kick/snare/toms/cymbals

  • "denoise": Clean noise from low-quality audio (128kbps MP3)

input_file: Path to audio file (absolute or relative to cwd). model: Model name from the list above. output_dir: Output directory (default: /tmp/stems).

Returns paths to separated stem files.

Example: separate_stems("suno_track.wav", model="bs6")

→ {stems: {bass: "...", drums: "...", vocals: "...", ...}}

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNobs6
input_fileYes
output_dirNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It describes the pipeline, models, and output format, but does not disclose potential issues like file size limits, processing time, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (purpose, model list, parameters, example). Some redundancy but overall efficient for the detail provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but indicated), the description covers functionality well, including model specifics and return structure. Could mention expected file sizes or processing time.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description thoroughly documents all three parameters (input_file, model, output_dir), including model options with specific use-case details and defaults. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it separates audio into stems using SOTA AI models. Lists specific models and their outputs. However, it does not explicitly differentiate from the sibling 'split_stems' tool, which may have a related purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides model descriptions and use cases (e.g., 'best vocal extraction'), but lacks explicit guidance on when to use this tool versus alternatives like 'split_stems'. No when-not-to-use or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_serializeB

Serialize the current project state to JSON. Returns the serialized project data.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description should disclose behavioral traits. It only states 'serialize' but does not mention whether this is a read-only operation, if it modifies state, or any permissions required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short sentences with no redundancy. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With siblings like 'get_full_project_state' and 'get_project_state', the description should differentiate. It does not clarify the output structure or use cases, though output schema exists which partially compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. The description adds no additional semantic meaning beyond what the schema provides, which is acceptable given the simplicity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool serializes the project state to JSON and returns data. However, it does not differentiate from similar tools like 'get_full_project_state' or 'get_project_state', which may also return project state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'get_full_project_state' or 'get_project_state'. The description lacks context for appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_articulationA

Set articulation for notes — legato, staccato, or tenuto.

Articulation defines how notes connect to each other — the space or overlap between consecutive notes. This is what makes strings sound smooth (legato) or plucky (staccato), and it's separate from pitch and velocity.

Three articulations:

  • "legato" — each note extends to the start of the next note (minus a micro_gap in PPQN for articulation separation). Notes flow into each other seamlessly. Use for smooth string lines, vocal phrases, wind instruments, lead melodies.

  • "staccato" — each note is shortened to staccato_ratio of the distance to the next note. 0.5 = half the gap, 0.25 = very short and detached, 0.75 = portato (lightly separated). Creates space between notes.

  • "tenuto" — each note holds to its full available duration (up to the next note's start, no gap). Slightly longer than legato — full value with no separation. Use for sustained passages, horn sustains.

The last note in each region keeps its original duration (no next note to reference). Notes at the same position (chords) are treated as one unit — they all get the same treatment based on the next distinct position.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). articulation: "legato", "staccato", or "tenuto". staccato_ratio: For "staccato" — fraction of gap to fill (0.1-0.9, default 0.5 = half the available time). micro_gap: For "legato" — PPQN gap to leave between notes (default 20, ~1/48 of a beat). 0 = notes touch exactly. Higher = more separation.

Returns per-track notes adjusted, articulation type.

Example:

Smooth legato strings

set_articulation(unit_index=0, track_index=2, articulation="legato")

Crisp staccato — 30% of available time

set_articulation(unit_index=0, track_index=2, articulation="staccato", staccato_ratio=0.3)

Full tenuto — horns holding full value

set_articulation(unit_index=0, track_index=3, articulation="tenuto")

ParametersJSON Schema
NameRequiredDescriptionDefault
micro_gapNo
unit_indexNo
track_indexNo
articulationNolegato
region_indexNo
staccato_ratioNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains key behavioral traits: how each articulation affects note lengths, edge cases (last note, chords), and the return value. Since no annotations are provided, the description carries the full burden. It could benefit from noting irreversibility or undo availability, but overall is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: purpose statement, articulation explanations, parameter list, edge cases, and an example. Every sentence earns its place, and the structure is front-loaded and easy to scan. Length is justified by complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, 3 articulation modes, edge cases) and the existence of an output schema, the description is thorough. It covers all necessary aspects for an agent to use the tool correctly, including parameter semantics and behavioral caveats.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining each of the 6 parameters, including defaults, unit indices, and the meaning of staccato_ratio and micro_gap. It adds significant value beyond the schema's bare properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set articulation for notes — legato, staccato, or tenuto.' It specifies a verb ('set'), resource ('articulation for notes'), and enumerates the exact types, making it distinct from siblings like mcp_opendaw_apply_articulation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use each articulation (e.g., 'Use for smooth string lines...'), but does not explicitly differentiate from sibling tools or state when not to use this tool. It lacks alternatives, but the within-tool guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_audio_region_fadeA

Set fade in/out on an audio region.

Audio regions have a Fading object with four params:

  • in: fade-in duration in seconds (0 = no fade-in)

  • out: fade-out duration in seconds (0 = no fade-out)

  • inSlope: fade-in curve (0.5 = linear, 0.75 = fast start, 0.25 = slow start)

  • outSlope: fade-out curve (0.5 = linear, 0.25 = fast end, 0.75 = slow end)

Pass -1.0 for any parameter to skip changing it (keep current value).

unit_index: Audio unit index. track_index: Audio track index. region_index: Region index within the track. fade_in: Fade-in duration in seconds (-1 = skip). fade_out: Fade-out duration in seconds (-1 = skip). in_slope: Fade-in curve 0-1 (-1 = skip). out_slope: Fade-out curve 0-1 (-1 = skip).

Returns updated fade values.

ParametersJSON Schema
NameRequiredDescriptionDefault
fade_inYes
fade_outYes
in_slopeYes
out_slopeYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral transparency. It discloses the skip behavior, slope range, and return of updated fade values. It does not mention prerequisites (e.g., region existence) or confirm if it overwrites existing fades, which would be beneficial but not critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: a header sentence, a paragraph explaining the Fading object and skip value, then a bullet-like list of parameters with brief descriptions, and a sentence about the return. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 required parameters and an output schema, the description covers parameter details and return value. It lacks explicit error handling or prerequisites, but output schema exists to describe return structure. Adequately complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates fully. It explains each parameter: unit_index, track_index, region_index, fade_in/out (seconds, -1 to skip), in_slope/out_slope (0-1 curve). This adds significant meaning beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set fade in/out on an audio region' and explains the Fading object's four parameters, distinguishing it from other region operations like gain or time base. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to skip parameters with -1.0 and the slope curve values, but does not explicitly state when to use this tool versus alternatives (e.g., copy_region_fades or set_audio_region_gain). Usage context is implied but not guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_audio_region_gainA

Set gain (in dB) on an audio region.

Audio regions have a per-region gain control (Float32Field, decibel). Use this for trim automation or balancing clips within a track.

unit_index: Audio unit index. track_index: Audio track index. region_index: Region index within the track. gain_db: Gain in dB (0 = unity, -6 = half volume, +6 = double).

Returns updated gain value.

ParametersJSON Schema
NameRequiredDescriptionDefault
gain_dbYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description explains gain control type and return value, but lacks details on error handling, permissions, or side effects. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five focused sentences with no redundancy. Front-loads purpose, then use case, then parameter details. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all required parameters and use case. Mentions return value. Lacks potential error scenarios, but sufficient for a straightforward setter with output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. Description adds full parameter meanings, including unit indices and gain_db examples, significantly aiding agent understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set gain' on a specific resource 'audio region'. It provides examples of gain values and distinguishes from siblings by specifying gain control specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use cases: 'trim automation or balancing clips within a track.' Does not list alternatives or when-not-to-use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_audio_region_time_baseA

Set the time base of an audio region.

Controls how the region's duration is interpreted:

  • 'musical' — duration in PPQN (musical beats, follows tempo changes)

  • 'seconds' — duration in seconds (fixed wall-clock time, independent of tempo)

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. time_base: 'musical' or 'seconds'.

Returns old and new time base.

ParametersJSON Schema
NameRequiredDescriptionDefault
time_baseYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool controls duration interpretation, changes are reversible by re-setting, and it returns old and new time base. It adds valuable context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a purpose statement, then detailed explanation of time base modes, followed by parameter list. It is relatively concise with no redundant sentences, though it could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown) and the tool's straightforward nature, the description adequately covers purpose, parameters, return value, and semantics. It provides sufficient context for an agent to select and invoke the tool correctly without ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by providing clear, concise explanations for each parameter: unit_index, track_index, region_index, and time_base with valid values. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set the time base of an audio region' with specific verb and resource. It explicitly explains the two options and their effects, making it highly distinguishable from sibling tools, many of which are other set_* operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each time base value ('musical' vs 'seconds') with clear effects. However, it does not provide explicit guidance on when not to use this tool or mention alternatives, relying on implied usage from the parameter descriptions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_audio_region_waveform_offsetA

Set the waveform display offset of an audio region.

The waveform offset shifts the visual start of the waveform within the region, useful for aligning the waveform display with the actual audio content.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. offset: Waveform offset value (in seconds).

Returns old and new offset.

ParametersJSON Schema
NameRequiredDescriptionDefault
offsetYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool modifies the visual offset and returns old and new values. However, it does not detail side effects, permissions, or whether the change is reversible. The behavioral impact is moderately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no fluff: 6 lines covering purpose, parameter list, and return value. Every sentence adds value, with clear grouping and no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and the tool's simplicity, the description adequately explains the set operation, parameter roles, and return value. It does not explain the hierarchy (unit->track->region) but this is inferable from parameter names. It is mostly complete for a straightforward setter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It lists parameters with brief labels ('AU index', 'Offset value in seconds') but lacks constraints, ranges, or relationships. This adds basic meaning beyond the schema's titles but is insufficient for precise invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Set the waveform display offset of an audio region'. It explains the purpose: 'shifts the visual start of the waveform' and distinguishes itself from sibling tools like set_audio_region_fade or set_audio_region_gain by focusing on waveform offset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an implied usage context ('useful for aligning the waveform display with the actual audio content'), but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to sibling tools are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_automation_interpolationA

Set the interpolation type of an existing automation event.

Changes how the automation curve transitions from this event to the next.

unit_index: AU index. track_index: Value (automation) track index. region_index: Region index containing the event. event_index: Event index within the region's collection. interpolation: "none" (step/hold), "linear" (straight ramp), or "curve" (custom slope). curve_slope: Slope for curve interpolation (0.0-1.0). Only used if interpolation="curve".

Returns success, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
curve_slopeNo
event_indexYes
track_indexYes
region_indexYes
interpolationYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the purpose and effect but omits prerequisites (e.g., event must exist), side effects, error conditions, or reversibility. 'Returns success, or error' is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with brief purpose, effect explanation, and parameter list. Each sentence adds value, though 'Returns success, or error' is minimal. Could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose and parameters adequately, but lacks details on return value structure (though output schema exists), preconditions, and error handling. Missing information needed for safe use without annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 6 parameters are explained with meanings, indices, interpolation options, and conditional dependency. Schema coverage is 0%, so description fully compensates by adding essential context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Set' and the resource 'interpolation type of an existing automation event', and explains the effect on curve transitions. This distinguishes it from siblings like add_automation or update_automation_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Does not explicitly state when to use this tool versus alternatives like update_automation_event. The context implies it is for modifying an existing event's interpolation, but no when-not-to or alternative guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_bpmC

Set the project tempo in BPM.

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description does not disclose behavioral traits such as whether this changes global tempo, requires engine running, or affects existing tempo automation. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, which is concise but overly minimal for a mutative tool. Could include usage context without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex DAW domain, many sibling tools, and no annotations, the description is extremely incomplete. No side effects, prerequisites, or usage context are mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. Description does not explain the bpm parameter: no valid range, units assumed, or error handling. Parameter meaning is entirely left to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action 'Set the project tempo' and specifies the unit BPM. It distinguishes from siblings like detect_bpm and set_tempo_change.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like set_tempo_change or detect_bpm. Agent must infer usage from name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_bus_colorB

Set the color (hue 0-360) of an audio bus.

bus_index: Bus index. hue: Color hue 0-360 (HSL).

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
bus_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states 'Returns success or error' but does not disclose side effects, validation behavior (e.g., what happens if bus_index is invalid), or whether the change is immediately applied. The hue range is specified, but overall transparency is minimal for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise with three brief lines, front-loading the purpose and parameter definitions. There is no unnecessary text. However, it might be too minimal, missing some potentially helpful context for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter tool, the description covers the core action and return value. However, it lacks information about error handling, prerequisites (bus must exist), and whether the operation is undoable. With no annotations and a basic description, it is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description provides the only explanations: 'bus_index: Bus index' and 'hue: Color hue 0-360 (HSL).' While brief, it adds meaning beyond the schema's type-only definitions. However, it could be more precise (e.g., zero-based indexing, bus existence requirement).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Set the color (hue 0-360) of an audio bus.' This is a specific verb+resource pair and clearly distinguishes from sibling tools like set_clip_hue (which operates on clips) and set_region_color (which operates on regions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., set_clip_hue for clips). There is no mention of prerequisites (e.g., bus must exist) or contexts where this tool is inappropriate. The description only states the action without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_bus_enabledA

Enable or mute an audio bus (FX bus A/B comparison).

bus_index: Bus index from list_audio_buses (0 = primary output). enabled: True to enable, False to mute.

ParametersJSON Schema
NameRequiredDescriptionDefault
enabledYes
bus_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden of behavioral disclosure. It explains that bus_index comes from list_audio_buses and that 0=primary output, but does not mention side effects, error behavior, or if muting a bus affects audio routing. Basic but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded: first sentence states the purpose, followed by two clear parameter explanations. No extraneous text. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is fairly complete for a simple toggle tool: it explains the parameters and indicates that bus_index comes from list_audio_buses. Although it doesn't mention return values (output schema exists), it provides enough context for an agent to use the tool correctly. Minor gaps in error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the schema: it explains bus_index as derived from list_audio_buses and the meaning of enabled. This compensates for the 0% schema description coverage. Could be more precise about invalid indices.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (enable or mute) and the resource (audio bus), and adds context about FX bus A/B comparison. It effectively distinguishes the tool's purpose from sibling tools like set_bus_color.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention conditions under which it should or should not be used. It simply states the action without contextual prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_bus_labelA

Set the label (name) of an audio bus.

bus_index: Bus index from create_audio_bus. label: New name for the bus (e.g. "Reverb Bus", "Drum Bus").

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
bus_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It states 'Returns success or error' and describes the action, but does not disclose potential side effects (e.g., overwriting previous label, impact on mixer states). Behavior is not hidden but also not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 lines), front-loaded with the main purpose, and each sentence contributes without redundancy. It efficiently covers the action, parameters, and return behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter tool, the description covers the essentials: what it does, parameters, and return type. It could mention prerequisites (e.g., bus must exist) but overall is complete given the tool's simplicity. There is an output schema, but the description's mention of 'success or error' suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds significant meaning: it specifies the origin of 'bus_index' (from create_audio_bus) and gives examples for 'label'. This compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the label of an audio bus, using a specific verb ('Set') and resource ('label of audio bus'). It distinguishes from siblings like 'set_bus_color' or 'set_bus_enabled' by focusing on the naming aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (to rename a bus) but does not explicitly provide when-not-to-use or alternatives. It assumes the agent knows bus indices from a preceding call to 'create_audio_bus', which is helpful but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_clip_hueA

Set the color (hue) of a clip in the session view.

unit_index: AU index. track_index: Track index within the AU. clip_index: Clip index. hue: Color hue 0-360.

Returns success with old and new hue.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states that it 'sets' the hue, implying a mutation, and discloses that it returns 'old and new hue'. However, it lacks details on side effects (e.g., UI update, error handling for invalid indices or out-of-range hue), which would be expected given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and to the point. The first sentence states the purpose, followed by a compact parameter list, and a final sentence on return values. No extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter tool with all required parameters and a stated return value (old and new hue), the description is fairly complete. It could mention error conditions or indexing conventions, but given the tool's simplicity, it covers the essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides crucial semantics: it explains that unit_index is the 'AU index', track_index is 'Track index within the AU', clip_index is 'Clip index', and hue is 'Color hue 0-360'. This adds significant meaning beyond the schema's bare type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'clip in the session view', with a specific attribute 'color (hue)'. This distinguishes it from sibling tools like set_clip_label or set_clip_mute, which target different clip properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., other set_clip_* tools). The description only explains what it does, not the context or preconditions for its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_clip_labelA

Set the label (name) of a clip in the session view.

unit_index: AU index. track_index: Track index within the AU. clip_index: Clip index. label: New clip name.

Returns success with old and new label.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states it sets the label and returns old/new label, but with no annotations, it fails to disclose whether changes are destructive, if there are length limits, or any side effects. This is minimal for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the purpose. It lists parameters in a clear, scannable format without unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with 4 required parameters and an output schema. The description covers the return value (old/new label). It is sufficient for basic usage, though it could mention potential constraints or failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description explains each parameter's meaning ('AU index', 'Track index within the AU', etc.), providing essential context beyond the raw schema. This compensates well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Set), resource (label of a clip), and context (session view). It distinguishes from sibling tools like set_clip_hue or set_clip_mute by specifying the exact attribute being modified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like set_clip_properties or other clip mutation tools. There is no mention of prerequisites, exclusions, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_clip_muteA

Mute or unmute a clip in the session view.

unit_index: AU index. track_index: Track index within the AU. clip_index: Clip index. mute: True to mute, false to unmute.

Returns success with old and new mute state.

ParametersJSON Schema
NameRequiredDescriptionDefault
muteYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states that the tool returns old and new mute state, but does not mention potential side effects (e.g., affecting playback, or if the mute is independent of other muting mechanisms). It does not describe error handling for invalid indices. Transparency is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (3 sentences) and well-structured: first sentence states purpose, second explains parameters, third describes return value. No redundant information. It is appropriately concise for a simple parameter-setting tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple interface and an output schema (not shown), so the description need not explain return values in depth. It mentions returning old and new mute state, which is sufficient. However, it omits error handling, prerequisites (e.g., clip must exist), and context about session vs arrangement view. These gaps are minor for a simple mute toggle but could be improved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% parameter description coverage, so the description must compensate. It clearly defines each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'clip_index: Clip index', 'mute: True to mute, false to unmute.' This adds essential meaning beyond the schema titles and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Mute or unmute a clip in the session view.' It specifies the verb (mute/unmute), the resource (clip), and the context (session view). This distinguishes it from sibling tools like set_clip_hue or set_clip_label, which target other clip properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, what happens if indices are invalid, or how this tool relates to other mute controls in the DAW. While the purpose is straightforward, some usage context would improve AI decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_clip_playbackA

Set clip playback parameters (loop, reverse, speed) on a clip.

Clips have a ClipPlaybackFields (triggerMode) object with:

  • loop: Whether the clip loops (true/false)

  • reverse: Play in reverse (true/false)

  • speed: Playback speed multiplier (1 = normal)

  • quantise: Quantise value

  • trigger: Trigger mode

Pass None for any parameter to skip changing it.

unit_index: Audio unit index. track_index: Track index. clip_index: Clip index (from list_clips). loop: Enable looping (None = skip). reverse: Reverse playback (None = skip). speed: Speed multiplier (None = skip).

Returns updated playback values.

ParametersJSON Schema
NameRequiredDescriptionDefault
loopYes
speedYes
reverseYes
clip_indexYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It discloses the tool modifies clip state, allows skipping parameters, and returns updated values. This is sufficient for a setter, though it doesn't discuss error handling or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: an introductory sentence, explanation of ClipPlaybackFields, how to skip parameters, and a parameter list. It is succinct without being overly verbose, though it could be streamlined slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions returns of updated playback values, which helps with completeness. However, it lacks details on error conditions, such as invalid indices or clip not found. Given the tool has 6 required parameters and no output schema, the context is adequate but not fully robust.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage (the description does not echo schema titles verbatim), it adds meaning by explaining each parameter: unit_index as audio unit index, clip_index from list_clips, and the meaning of loop, reverse, speed. This goes beyond the schema's minimal titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets clip playback parameters (loop, reverse, speed) on a clip, using a specific verb-resource structure. It distinguishes from siblings like set_clip_mute or set_clip_hue by focusing on playback-specific fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to skip parameters by passing None and defines indices (unit_index, track_index, clip_index). While it doesn't explicitly compare to alternatives like schedule_clip_play, the context is clear enough for an agent to identify when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_clip_propertiesA

Set properties on a clip (session view): label, color, mute, duration.

Pass empty string for label to skip, -1 for hue/duration to skip, None for mute to skip.

unit_index: Audio unit index. track_index: Track index. clip_index: Clip index (from list_clips). label: New label (empty = skip). hue: New color hue 0-360 (-1 = skip). mute: Mute state (None = skip). duration_beats: New duration in beats (-1 = skip).

Returns updated clip properties.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
muteYes
labelYes
clip_indexYes
unit_indexYes
track_indexYes
duration_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses key behavioral details: skip values for each parameter (empty string, -1, None) and that it returns updated clip properties. This adds value beyond the schema, though it could mention that it modifies the clip in place.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose sentence, skip conventions, parameter list, and return statement. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameter meanings, skip behavior, and return value. It is complete for a compound setter, though it could note that this is an alternative to individual setters or mention that all parameters are required but skippable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description fully compensates by explaining each parameter's meaning and skip conventions. For example, 'clip_index: Clip index (from list_clips)' and skip values are clearly documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set properties on a clip (session view): label, color, mute, duration' and lists all parameters. It distinguishes from sibling tools by being a compound setter, and the title 'mcp_opendaw_set_clip_properties' aligns with this.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for setting multiple clip properties at once, but it does not explicitly state when to use this tool versus the individual set_clip_hue, set_clip_label, etc. For example, it could say 'Use this to set multiple properties in one call instead of individual setters.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_crusher_bitsA

Set the bit depth on a Crusher (bitcrusher) effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Crusher). bits: Bit depth (1-16, where 16=no crushing, 1=extreme).

ParametersJSON Schema
NameRequiredDescriptionDefault
bitsYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden. It notes that effect_index must refer to a Crusher, which is a key constraint. However, it does not disclose behavioral aspects such as permissions, side effects, or whether the change is immediate, leaving some uncertainty about the tool's operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence for purpose followed by three bullet-point parameter explanations. Every sentence is meaningful, with no filler. The purpose is front-loaded, and the parameter details are clearly separated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameter setter with an output schema (though unseen), the description is nearly complete. It explains all parameters and the constraint on effect_index. The only minor gap is that it doesn't state the tool modifies state or is a write operation, but this is implicit in 'set'. Overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning to all three parameters beyond the empty schema (0% coverage). It explains unit_index as 'AU index', effect_index as 'Effect index in the audio effect chain (must be a Crusher)', and bits as 'Bit depth (1-16, where 16=no crushing, 1=extreme)'. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Set the bit depth on a Crusher (bitcrusher) effect.' This is a specific verb+resource combination that correctly identifies a distinct parameter adjustment among many set_ tools, making it easy for an agent to select it for bit depth control.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives like 'set_crusher_crush' or other effect parameter setters. An agent would have no context about preferences or prerequisites beyond the implicit requirement of a Crusher effect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_crusher_crushA

Set the sample-rate reduction (crush) on a Crusher effect.

The crush value is inverted internally: 0.0=clean (20kHz), 0.15=retro lo-fi (~8kHz), 0.25=AM radio (~3.5kHz), 0.55=glitchy (~500Hz), 1.0=inaudible (20Hz).

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Crusher). crush: Sample rate reduction amount (0.0-1.0, 0=clean, 1=max destruction).

ParametersJSON Schema
NameRequiredDescriptionDefault
crushYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adds useful context: crush is inverted internally, and gives sound quality ranges. However, it does not disclose side effects, undo behavior, or permission requirements, leaving gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear main sentence, bullet points for parameters, and a value mapping. Every sentence is informative with no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simple parameter-setting nature and existence of an output schema, the description covers parameter semantics and behavioral quirk (inverted crush). It lacks only minor context about return values, but overall is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by explaining each parameter: unit_index, effect_index, and the crush mapping from 0.0 to 1.0 with concrete sonic examples. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets sample-rate reduction (crush) on a Crusher effect, specifying the effect type and the verb 'set' with a clear resource. It distinguishes from siblings like set_crusher_bits by focusing on crush specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description provides value mappings but does not discuss prerequisites, when not to use it, or alternative tools for similar effects.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_delay_syncB

Set the synced delay time on a Delay effect using a musical fraction string.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Delay). fraction: Musical fraction — one of: "off", "1/128", "1/96", "1/64", "1/48", "1/32", "1/24", "3/64", "1/16", "1/12", "3/32", "1/8", "1/6", "3/16", "1/4", "5/16", "1/3", "3/8", "7/16", "1/2", "1/1".

ParametersJSON Schema
NameRequiredDescriptionDefault
fractionYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits. It only states the syntactic constraint (effect must be a Delay) and lists fraction options. No mention of side effects, reversibility, or impact on project state. This is insufficient for complete transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise. The first sentence states the purpose, followed by bullet-list parameter explanations. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values are not needed. The description covers purpose and parameter semantics adequately but lacks behavioral transparency and usage guidelines. For a tool with 3 parameters and constrained values, it is minimally complete but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description adds meaning. It explains fraction with allowed values, effect_index with the 'must be a Delay' constraint. unit_index is briefly described as 'AU index' but could be clearer. Overall, it compensates for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it sets synced delay time on a Delay effect using a musical fraction. The description specifies the resource (Delay effect) and action (set synced delay time). It distinguishes from other set_* tools by targeting a specific effect type, though it does not explicitly compare to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage by requiring effect_index to be a Delay and listing allowed fraction values. However, no explicit guidance on when to use this versus alternatives (e.g., unsynced delay time setup), nor prerequisites like effect existence or state.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_device_labelB

Rename an effect or MIDI effect device.

unit_index: AU index. effect_index: Effect index in the chain. label: New label/name for the device. is_midi_effect: If true, target MIDI effects chain instead of audio effects.

Returns success, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
unit_indexYes
effect_indexYes
is_midi_effectNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It only states 'Returns success, or error' without elaborating side effects, reversibility, or permissions. The brief description is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a one-line summary followed by a brief parameter list. Every sentence adds information; no redundancy. Well-structured for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple rename operation with 4 parameters and an output schema, the description covers parameter semantics but lacks details on return value structure, error conditions, or prerequisites. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds context for each parameter: unit_index as 'AU index', effect_index as 'Effect index in the chain', label as 'New label/name', and is_midi_effect clarifies targeting. This adds moderate value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Rename' and the resource 'effect or MIDI effect device'. It distinguishes from sibling tools like rename_unit and set_clip_label by specifying the target as an effect device.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives (e.g., rename_unit). The description implies usage by listing parameters but lacks 'when not to use' or 'see also' references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_effect_enabledB

Enable or bypass an specific effect on an audio unit.

unit_index: Audio unit index. effect_index: Effect position in the chain. enabled: true to enable, false to bypass.

ParametersJSON Schema
NameRequiredDescriptionDefault
enabledYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states that the tool sets enabled to true or false, but does not mention return values, side effects (e.g., if indices are invalid), or whether the operation is undoable. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short sentences plus parameter explanations. Every sentence adds value without redundancy. Front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 3 required parameters and no annotations or output schema described, the description does not cover how to obtain the indices (unit_index, effect_index) or what the return value is. It lacks completeness for an agent to use this tool without additional context from other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the input schema by explaining each parameter: unit_index is 'Audio unit index', effect_index is 'Effect position in the chain', and enabled is 'true to enable, false to bypass'. This is valuable given that schema description coverage is 0%. However, value ranges or constraints are not specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Enable or bypass' and the resource 'specific effect on an audio unit'. It distinguishes from sibling tools like add_effect, remove_effect, and list_effects by specifying the exact action on an existing effect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., set_effect_parameter, remove_effect). No prerequisites mentioned, such as requiring the unit and effect to exist. The description does not provide context for when bypassing is preferred over enabling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_effect_parameterA

Set a parameter on an audio effect.

unit_index: Audio unit index. effect_index: Effect position in the chain (0-based). parameter_name: Parameter name from mcp_opendaw_list_effect_parameters (e.g. "inputGain", "mix", "equation"). value: Numeric value for float params. For string params (like Waveshaper equation), pass the string as parameter_name=value pair — use parameter_name="equation" and value as a special case.

Examples: set_effect_parameter(0, 0, "inputGain", 12.0) # Waveshaper +12dB input set_effect_parameter(0, 0, "mix", 1.0) # 100% wet set_effect_parameter(0, 0, "equation", 0) # Use string_value for equation

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
effect_indexYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description covers the write operation but does not mention error conditions, return value, or prerequisites (e.g., effect existence). With no annotations, more transparency is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear opening, parameter list, and examples. Could be slightly more concise but examples are helpful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input well but does not mention output or error handling. Output schema exists but not described. Lacks discussion of side effects or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description explains each parameter meaningfully, including examples and special cases for string values. Adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Set a parameter on an audio effect' and specifies indices and parameter names. Examples differentiate from typed siblings like set_effect_parameter_bool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains parameters, references list_effect_parameters for names, and provides examples. Includes special case for string params via parameter_name='equation'. Could be more explicit about when to use this vs typed variants.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_effect_parameter_boolA

Set a boolean parameter on an audio effect.

Covers device-specific boolean fields not exposed through the generic float setter:

  • Compressor: lookahead, automakeup, autoattack, autorelease

  • Gate: inverse

  • Maximizer: lookahead

  • StereoTool: invertL, invertR, swap

  • NeuralAmp: mono

  • Delay: freeTimeSync (if available)

unit_index: Audio unit index. effect_index: Effect position in the chain (0-based). parameter_name: Boolean field name (e.g. "lookahead", "automakeup", "inverse", "mono"). value: true or false.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
effect_indexYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. It explains that it sets boolean parameters but does not disclose side effects, permissions, or immediate audio processing impact. While straightforward, more detail on behavioral implications would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose and includes a bullet list of device fields and parameter explanations. It is reasonably concise, though the device list could be slightly condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool, the description covers purpose, usage, and parameters adequately. It has an output schema (content not shown) so return values are handled. Minor gaps like case-sensitivity of parameter_name, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description fully compensates. All 4 parameters are explained with examples, and parameter_name is enriched with a list of valid boolean fields per device type. This provides significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set a boolean parameter on an audio effect' and distinguishes from sibling tools by explicitly covering 'device-specific boolean fields not exposed through the generic float setter'. It provides specific examples per device type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use: for boolean fields not covered by the float setter. It implies alternatives (generic float setter) but does not explicitly state when not to use or list alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_effect_parameter_intA

Set an integer parameter on an audio effect.

Covers device-specific integer fields not exposed through the generic float setter:

  • Vocoder: bandCount

  • StereoTool: panningMixing

  • Fold: overSampling

  • Crusher: bits

  • Delay: version (internal)

Note: device-specific tools (set_vocoder_band_count, set_fold_oversampling, etc.) are preferred when available. This is a generic fallback for any Int32Field.

unit_index: Audio unit index. effect_index: Effect position in the chain (0-based). parameter_name: Integer field name (e.g. "bandCount", "bits", "overSampling"). value: Integer value.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
effect_indexYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains it's a fallback and lists known integer fields, providing some behavioral context. However, it does not disclose potential side effects (e.g., what happens if the parameter_name is invalid), permissions, or error behavior. While it covers the basics, it lacks depth for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a main sentence, a bulleted list of examples, and a usage note. It is reasonably concise, though the bullet list could be slightly trimmed. Overall, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity and presence of an output schema, the description covers the core functionality, usage guidance, and parameters. It could mention return behavior or errors, but it is fairly complete for a tool that sets integer parameters on effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema. Schema coverage is 0%, so it compensates by explaining each parameter (unit_index, effect_index, parameter_name with examples like 'bandCount', 'bits', and value). This makes the schema much more usable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set an integer parameter on an audio effect.' It specifically lists covered fields (Vocoder bandCount, StereoTool panningMixing, etc.) and distinguishes itself from the generic float setter and device-specific tools like set_vocoder_band_count. This leaves no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that device-specific tools are preferred when available, and this is a generic fallback. This provides clear guidance on when to use this tool vs alternatives, which is crucial for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_effect_parameter_stringB

Set a string parameter on an audio effect (e.g. Waveshaper equation).

unit_index: Audio unit index. effect_index: Effect position in the chain. parameter_name: Parameter name (e.g. "equation"). string_value: String value (e.g. "hardclip", "tanh", "cubicSoft", "sigmoid", "arctan", "asymmetric").

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes
string_valueYes
parameter_nameYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description gives no behavioral details beyond the action itself. It does not disclose whether the operation is destructive, requires specific permissions, or any potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single sentence followed by bullet-point parameter definitions. No redundant information, though the bullet points somewhat repeat the schema. Still efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter with 4 undocumented parameters, the description covers the basics and includes examples for the string_value. However, it lacks context about prerequisites (e.g., effect must exist) or any constraints. Output schema exists, so return values are not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description adds value by listing parameters and providing example values for 'string_value' (e.g., 'hardclip', 'tanh'). However, explanations for other parameters (unit_index, effect_index, parameter_name) are minimal, offering little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set a string parameter on an audio effect' and gives a concrete example (Waveshaper equation). The tool name also specifies 'string', distinguishing it from sibling tools like set_effect_parameter_int and set_effect_parameter_bool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for string parameters but does not explicitly state when to use this tool versus alternatives (e.g., set_effect_parameter_int, set_effect_parameter_bool). No guidance on prerequisites or conditions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_fold_oversamplingA

Set the oversampling level on a Fold (wavefolding) effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Fold). oversampling: 0=off, 1=2x, 2=4x.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes
oversamplingYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the parameter values and their meanings but omits potential side effects, reversibility, or error conditions. Adequate for a simple setter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences plus parameter list. Front-loaded with purpose, no filler words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter with 3 parameters and an output schema, the description is nearly complete. It covers what the tool does, parameter meanings, and accepted values. Minor lack of error handling info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates well by explaining each parameter: unit_index, effect_index, and oversampling with value mapping (0=off, 1=2x, 2=4x). Adds significant meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the oversampling level on a Fold (wavefolding) effect, using specific verb+resource. It distinguishes from sibling set_* tools by specifying the effect type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should only be used when the effect is a Fold, but lacks explicit guidance on when to use vs alternatives or when not to use. The constraint 'must be a Fold' provides some direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_groove_shuffleA

Set the groove/shuffle (swing) amount for the project.

amount: 0.0 = straight (no swing), 1.0 = full swing. Typical values: 0.15 = light swing, 0.25 = moderate, 0.5 = strong triplet feel.

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description explains parameter range and typical values but does not disclose behavioral traits like whether change is global, involves any destructive action, or requires specific permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, no redundant information. Parameter detail follows directly after action statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter setter, the description covers action and parameter adequately. No output schema, but not necessary. Minor gap: does not specify scope (project-wide).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage; description adds significant value by explaining amount range (0.0-1.0) and giving typical values (light, moderate, strong triplet). Compensates for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states set groove/shuffle amount for project. Verb and resource identified. Does not explicitly distinguish from sibling 'apply_swing' but implies project-level setting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. No mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_instrument_paramA

Set a parameter on the instrument connected to an audio unit.

unit_index: Audio unit index (-1 = auto-detect first non-master AU with an instrument). param_name: Field name (e.g. "cutoff", "resonance", "attack", "flutter", "volume", "channel"). value: New value for the parameter. param_index: Alternative — set by field index instead of name (-1 = use name).

Works with any instrument type. Returns old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
param_nameYes
unit_indexYes
param_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool 'Returns old and new values' and explains the unit_index and param_index behaviors. However, it does not mention side effects, error conditions (e.g., if param_name is invalid), or whether changes are immediate or require rendering. The disclosure is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single sentence stating the purpose, followed by a bullet-style list of parameter explanations. Every sentence adds value, and the structure is front-loaded with the main action. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 required parameters and an output schema (not shown), the description explains the purpose, parameter meanings, and that it returns old and new values. It could be more thorough about prerequisites (e.g., requiring an audio unit with an instrument) and error handling, but it is largely complete for common use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage (only parameter titles). The description compensates by explaining each parameter: unit_index's special value -1, param_name as field name with examples, value as a number, and param_index as an alternative. It adds meaning beyond the schema, though it does not list all possible param_names or value ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'parameter on the instrument connected to an audio unit.' It lists the parameters with explanations, and distinguishes from sibling tools like set_effect_parameter by specifying 'instrument' and 'audio unit.' The tool name also reinforces this purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the unit_index special value -1 for auto-detection and the alternative param_index versus param_name. However, it does not explicitly state when to use this tool versus alternative parameter-setting tools (e.g., set_effect_parameter, set_midi_effect_param). The context is implied but not formally contrasted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_loop_regionA

Set the playback loop region.

When enabled, playback loops between from_beat and to_beat. Set enabled=false to disable loop (region is kept but inactive).

from_beat: Loop start in beats. to_beat: Loop end in beats. enabled: Whether loop is active.

ParametersJSON Schema
NameRequiredDescriptionDefault
enabledYes
to_beatYes
from_beatYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It explains the basic behavior: enabling/disabling the loop and the meaning of from_beat and to_beat. It does not mention side effects like immediate application to playback or any destructive actions, but for a simple set operation this is adequate. The transparency is good for a non-destructive parameter change.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two short paragraphs. The first paragraph states the purpose and basic behavior. The second lists the parameters with one-line explanations. No redundant words. Every sentence adds value, making it easy to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 required parameters, all explained. The behavior is simple: set loop region with enable/disable. There is an output schema (not shown) which presumably documents the return value. Given the tool's simplicity, the description covers all necessary information for an agent to use it correctly. No missing aspects identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 3 parameters with only titles, and schema description coverage is 0%. The description fully compensates by explaining each parameter: 'from_beat: Loop start in beats.', 'to_beat: Loop end in beats.', 'enabled: Whether loop is active.' This adds the exact meaning needed for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set the playback loop region.' It explains that playback loops between from_beat and to_beat when enabled. This distinguishes it from sibling tools like set_region_* or transport controls. The verb 'Set' combined with the resource 'loop region' makes the action unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use the tool: to define a loop region. It explicitly explains how to disable the loop by setting enabled=false, stating the behavior that the region is kept but inactive. While it doesn't explicitly list alternatives, the context of DAW tools implies the user would know when looping is needed. The simple use case is well-covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_marker_labelA

Rename a timeline marker.

marker_index: Index from list_markers (0-based). label: New label text.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
marker_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only says 'Rename a timeline marker.' It lacks disclosure of behavioral traits such as whether the marker must exist, side effects, or success/failure feedback. This is insufficient for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences plus parameter explanations. Every sentence is meaningful, and the key action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (not shown), so return values are covered. However, the description is minimal and does not mention prerequisites or error conditions. It is adequate for a simple rename but lacks deeper context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds significant meaning: it specifies that marker_index is 0-based and derived from list_markers, and that label is new label text. This compensates for the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Rename a timeline marker.' which is a specific verb (rename) and resource (timeline marker), distinguishing it from sibling marker tools like add_marker, delete_marker, set_marker_position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives. Siblings include add_marker, delete_marker, set_marker_position, but the description does not explain the context for renaming versus other marker operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_marker_positionA

Move a timeline marker to a new position.

marker_index: Index from list_markers (0-based). position_beats: New position in beats.

ParametersJSON Schema
NameRequiredDescriptionDefault
marker_indexYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It states the tool 'moves' a marker (a mutation) but does not disclose side effects, return value, permissions, or error behavior (e.g., invalid index).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three lines: a sentence and two parameter explanations. No unnecessary words, information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (though not shown), the description covers the parameters but lacks error handling, prerequisites (e.g., marker must exist), or behavioral details. It is adequate for a simple setter but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must add value. It explains marker_index as 'Index from list_markers (0-based)' and position_beats as 'New position in beats', providing context beyond the schema titles. Could be more precise (e.g., valid range).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Move' and the resource 'timeline marker to a new position'. It distinguishes from sibling tools like set_marker_label or set_marker_repeat by focusing solely on position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description hints that marker_index comes from list_markers (0-based), implying a prerequisite, but does not explicitly state when to use this tool versus alternatives like add_marker or delete_marker, nor does it provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_marker_repeatA

Set the repeat count on a timeline marker.

marker_index: Index from list_markers (0-based). repeat_count: 0 = infinite repeat, 1-16 = N repeats.

ParametersJSON Schema
NameRequiredDescriptionDefault
marker_indexYes
repeat_countYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the valid range (0=infinite, 1-16=N repeats) but does not disclose side effects (e.g., overwriting existing values, undo capability, or if repeat count resets playback).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise with two brief sentences plus parameter details. It front-loads the action and avoids unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with 2 required parameters and an output schema exists (not shown). The description covers the functionality well but omits return value information, which is acceptable given the output schema presence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds crucial context beyond the schema: 'marker_index: Index from list_markers (0-based)' and 'repeat_count: 0 = infinite repeat, 1-16 = N repeats'. With 0% schema coverage, this fully compensates by explaining origin and valid values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set the repeat count on a timeline marker.' This verb+resource pattern is unambiguous and distinguishes from sibling tools like set_marker_label or set_marker_position.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (to set a marker's repeat count) but provides no guidance on when not to use it or alternatives. It lacks exclusion context compared to other marker modification tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_metronomeA

Configure the metronome settings.

Args: enabled: Toggle metronome on/off. None = leave unchanged. gain: Click volume 0.0-1.0 (default 0.5). None = leave unchanged. beat_subdivision: Beats per click (1=quarter, 2=eighths, 4=sixteenths, 8=thirty-seconds, default 4). None = leave unchanged.

ParametersJSON Schema
NameRequiredDescriptionDefault
gainNo
enabledNo
beat_subdivisionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially explains behavior via parameter details (e.g., 'None = leave unchanged'), but does not disclose whether changes are immediate, reversible, or global vs per-project. It provides some transparency beyond schema but lacks full behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one sentence for purpose, then parameter list. Front-loaded with 'Configure the metronome settings.' No superfluous words or repetition. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 optional parameters and an output schema (not shown), the description covers input semantics thoroughly. It could mention that metronome is a project-level setting, but not essential. The parameter descriptions make the tool usable without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description fully compensates. Each parameter is explained with type, range, default, and behavior when None. For example, 'gain: Click volume 0.0-1.0 (default 0.5)' and 'beat_subdivision: Beats per click (1=quarter, 2=eighths, ... default 4)'. This adds significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Configure the metronome settings' with specific verb and resource. Among sibling tools like set_bpm and set_time_signature, this is distinctly about metronome settings, differentiating it well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. It does not indicate prerequisites, context (e.g., before playback), or when not to use it. The description only states what it does.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_midi_effect_paramA

Set a parameter on a MIDI effect.

unit_index: Audio unit index. effect_index: MIDI effect position in the chain (0-based). param_name: Field name (e.g. "semiTones", "rateIndex", "gate"). value: New value for the parameter. param_index: Alternative — set by field index instead of name (-1 = use name).

Returns old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
param_nameYes
unit_indexYes
param_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns old and new values, which is helpful, but omits any other behavioral traits such as side effects, error handling, or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and directly organized as a bullet list of parameters. Every sentence provides necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 5 parameters, no schema descriptions, and the existence of an output schema, the description covers parameter semantics and return values well. It lacks prerequisite or error context, but is fairly complete for a setter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explicitly lists all 5 parameters with concise explanations, including examples for param_name and the -1 convention for param_index. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Set a parameter on a MIDI effect', which is a clear verb+resource combination. The name and description directly differentiate it from sibling tools like set_effect_parameter (for audio effects) and set_instrument_param.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for MIDI effects by naming the tool accordingly, but does not provide explicit guidance on when to use it versus alternatives (e.g., set_effect_parameter for audio effects) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_modular_module_paramA

Set a parameter on a module in a Modular device.

au_index: Audio unit index. effect_index: Effect index within the AU. module_index: Module index. param_name: Parameter name — "gain" for ModuleGain, "time" for ModuleDelay. value: New parameter value (in physical units: dB for gain, ms for delay).

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
au_indexYes
param_nameYes
effect_indexYes
module_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only states it sets a parameter and returns success or error, without disclosing side effects, reversibility, or validation behavior. For a mutation tool with zero annotations, more behavioral disclosure is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with each parameter listed on its own line for easy scanning. Every sentence adds value; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While parameters are well explained, the description lacks context on how to obtain the indices (e.g., using list_modular_devices, list_modular_modules) and does not cover error handling or prerequisites. It is adequate for a simple operation but incomplete given the nested structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains all five parameters in detail, including the meaning of au_index, effect_index, module_index, param_name with examples, and value units. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set a parameter') and the resource ('module in a Modular device'). It distinguishes from sibling tools like set_effect_parameter by specifying 'modular module', which helps differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives, such as set_effect_parameter or set_modular_module. It does not mention prerequisites like having a modular device or obtaining indices via list_modular_devices/list_modular_modules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_neuralamp_modelA

Load a Neural Amp Modeler (NAM/Tone3000) model JSON into a NeuralAmp effect.

Creates a NeuralAmpModelBox with the provided model JSON and links it to the NeuralAmp device. This bypasses the popup-based Tone3000 Select Flow, enabling headless model loading.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a NeuralAmp). model_json: Full NAM model JSON string (the model architecture + weights). label: Optional label for the model box (default "NAM Model"). pack_id: Optional pack identifier.

Returns success + model_size, or error if the effect is not a NeuralAmp.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNoNAM Model
pack_idNo
model_jsonYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it states the effect (creates a NeuralAmpModelBox, links to device), the bypass behavior, and the return value (success + model_size or error). It does not mention potential side effects like overwriting existing models, but overall it's transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main action. It then lists parameters in a clear list. It could be slightly more structured, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 params, 3 required, output schema exists), the description covers the core functionality, parameter roles, and return behavior. It doesn't mention prerequisites or detailed outcomes, but it's sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the tool description compensates excellently by explaining each parameter: unit_index (AU index), effect_index (must be a NeuralAmp), model_json (full NAM JSON), label (optional, default), pack_id (optional). This adds significant meaning beyond the property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb and resource: 'Load a Neural Amp Modeler (NAM/Tone3000) model JSON into a NeuralAmp effect.' It distinguishes the tool from siblings like 'get_neuralamp_model' by focusing on the loading action and mentioning that it bypasses the popup flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (headless model loading) and what it achieves (bypasses popup flow), but lacks explicit comparisons to alternatives or exclusions. Still, the context is clear enough for most use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_note_advancedA

Set advanced note properties — chance, cent, playCount, playCurve.

These properties are beyond basic position/duration/pitch/velocity:

  • chance: Probability of note playing (0-100%, 100 = always)

  • cent: Micro-tuning in cents (-50 to +50, 0 = exact pitch)

  • play_count: Number of repeats (1-16, 1 = single note)

  • play_curve: Repeat curve (-1 to +1, 0 = even spacing)

Pass -1 (or -999 for float fields) to skip a property (leave unchanged).

unit_index: AU index. track_index: Note track index. region_index: Note region index. note_index: Note index within the region.

Returns updated values, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
centNo
chanceNo
note_indexYes
play_countNo
play_curveNo
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the skip values for leaving properties unchanged and notes that the tool 'Returns updated values, or error.' This provides good transparency about behavior, though it does not detail potential side effects or permissions needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise summary line, bullet lists for properties and indices, a clear skip instruction, and a return statement. Every sentence adds value, and it is front-loaded with the most important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, 0% schema coverage, no annotations), the description covers all necessary context: parameter meanings, ranges, skip behavior, and return value. It is complete enough for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates by explaining all 8 parameters: the four advanced properties with ranges and defaults, the four index parameters, and the skip mechanism. This adds significant meaning beyond the minimal schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set advanced note properties' and lists specific properties (chance, cent, playCount, playCurve), distinguishing it from basic set_note_properties and other sibling tools. The title and first line make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that these properties are beyond basic ones and provides instructions on skipping properties with -1 or -999. However, it does not explicitly contrast with sibling tools like set_note_cents or set_note_properties, which could guide the agent's choice more directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_note_centsA

Set detune (cents) on notes — deterministic microtonal pitch control.

Unlike humanize_pitch (random cents), this tool applies SPECIFIC cent offsets to targeted notes. This enables:

  • Piano honky-tonk: detune alternate notes by +8/-8 cents

  • Quarter-tone scales: +50 cents on selected pitches

  • Sympathetic resonance: subtle +3 cents on sustained notes

  • Just intonation corrections: -2 cents on major thirds, +14 on fifths

  • Arabic maqam: quarter tones between semitones

  • Synth drift: gradual cent increase across a sequence

  • Chorus effect (MIDI): duplicate track detuned +7 cents

Modes:

  • "all": Apply to all notes in the region(s)

  • "pitch": Apply only to notes matching target_pitch (e.g. "60" or "C4")

  • "beats": Apply at specific beat positions (comma-separated, e.g. "0,4,8")

  • "indices": Apply to specific note indices (comma-separated, e.g. "0,2,4")

  • "alternating": Alternate +cents and -cents on consecutive notes

  • "gradient": Linearly increase cents from 0 to target across all notes

  • "scale_degree": Apply to notes on specific scale degrees (requires scale + root_note + target_pitch as degree numbers)

Args: unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks). region_index: Region index (-1 = all regions on track). cents: Cent offset to apply (-100 to +100). 100 cents = 1 semitone. mode: Targeting mode (see above). target_pitch: For "pitch" mode: MIDI note number (e.g. "60") or note name (e.g. "C4"). For "scale_degree" mode: comma-separated degree numbers (e.g. "3,7" = apply to 3rd and 7th degrees). beat_positions: For "beats" mode: comma-separated beat positions. note_indices: For "indices" mode: comma-separated note indices. direction: "up" (positive cents) or "down" (negative cents). For alternating mode, this sets the first note's direction. scale: For "scale_degree" mode: scale name (major, minor, dorian, etc.). root_note: For "scale_degree" mode: root note name.

Returns notes modified, per-mode details, and average cents applied.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoall
centsNo
scaleNo
directionNoup
root_noteNoC
unit_indexNo
track_indexNo
note_indicesNo
region_indexNo
target_pitchNo
beat_positionsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains that the tool applies specific cent offsets, describes modes, and mentions the cent range (-100 to +100). It also notes that it returns 'notes modified, per-mode details, and average cents applied'. However, it does not disclose potential side effects or destructive actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately lengthy but well-structured with bullet points for modes and dashes for examples. It front-loads the core purpose and differentiates from siblings. However, some redundancy exists (e.g., repeating allowed values in the examples could be trimmed). Still, it earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 parameters, no annotations, and an output schema existing (so return values need not be described in detail), the description is quite complete. It covers the main behavior, all modes, and parameter explanations. The examples provide rich context for usage. Minor gaps: no description of error conditions or edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains 8 out of 11 parameters in detail (mode, cents, target_pitch, beat_positions, note_indices, direction, scale, root_note), providing examples and context. The remaining three (unit_index, track_index, region_index) are briefly mentioned with defaults. This adds significant value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: setting deterministic cent offsets on notes for microtonal pitch control. It distinguishes itself from the sibling tool 'humanize_pitch' by explicitly contrasting random vs deterministic behavior. The verb+resource is specific: 'Set detune (cents) on notes'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool, explicitly contrasting with humanize_pitch (random cents). It lists multiple modes and example use cases, helping the agent understand applicability. However, it does not explicitly state when NOT to use it or provide alternative tools beyond humanize_pitch.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_note_propertiesA

Edit properties of a single note within a region.

Pass -1 for any parameter to skip changing it (keep current value). Use list_notes first to find the note_index.

note_index: Index of the note in the region (0-based, sorted by position). unit_index: Audio unit index (-1 = search all AUs). track_index: Note track index within the AU. region_index: Region containing the note (0-based). position_beats: New position in beats (-1 = skip). duration_beats: New duration in beats (-1 = skip). pitch: New MIDI pitch 0-127 (-1 = skip). velocity: New velocity 0-1 (-1 = skip). cent: New cent offset in cents (-1 = skip). chance: New chance 0-100 (-1 = skip).

Returns updated note properties.

ParametersJSON Schema
NameRequiredDescriptionDefault
centYes
pitchYes
chanceYes
velocityYes
note_indexYes
unit_indexYes
track_indexYes
region_indexYes
duration_beatsYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explains the skip behavior (-1) but does not disclose side effects, undo capability, or permissions. For a mutation tool, more behavioral context would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the key usage tip and prerequisite, followed by a structured parameter list. Every sentence adds value, and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with no annotations, the description covers core usage, parameter semantics, and output. It does not address error conditions or validation, but output schema likely fills gaps. Overall complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description fully compensates by listing each parameter with its meaning, valid range (e.g., pitch 0-127), and behavior (-1 skip). This adds significant value beyond the schema's type-only definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Edit') and clearly identifies the resource ('properties of a single note within a region'). It distinguishes from sibling tools like mcp_opendaw_set_note_cents by focusing on multiple properties at once.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: passing -1 to skip parameters and using list_notes first to find the note_index. It lacks explicit when-not-to-use or alternatives, but the prerequisite tip is valuable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_piano_keyboardA

Set the piano roll keyboard type.

keyboard_type: One of 88 (full piano), 76 (stage), 61 (compact), 49 (controller).

Returns success with old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
keyboard_typeYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adequately discloses that the tool is a setter and returns success along with old and new values. This adds necessary behavioral context, though it could mention any side effects on the displayed keyboard range.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three crisp sentences: purpose, parameter mapping, and return info. Every sentence adds value with no redundancy. It is well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers the essential aspects. It could be improved by mentioning that this affects the visual keyboard range in the piano roll, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description fully enumerates the allowed integer values and their meanings ('88 (full piano)', etc.), which significantly compensates and allows correct parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: setting the piano roll keyboard type. It lists the allowed integer values with descriptive labels (88='full piano', etc.), which is precise and distinct from sibling set_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to change keyboard type), but does not explicitly contrast it with alternatives like set_piano_note_labels or set_piano_note_scale. No guidance on when not to use it is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_piano_note_labelsB

Toggle note labels (C, C#, D, etc.) in the piano roll.

show: True to show note labels, false to hide.

Returns success with old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
showYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the return value (old and new values) and the toggle nature, but with no annotations, it misses potential side effects or prerequisites. For a simple toggle, it is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, parameter explanation, and return description. No redundancy, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple toggle with one parameter and output schema present, the description is adequate but could mention the scope (e.g., selected track). Overall, meets minimum viability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Given 0% schema description coverage, the description adds meaningful explanation of the boolean parameter 'show', specifying its effect. This compensates well for the schema's lack of text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool toggles note labels in the piano roll, specifying the resource (note labels) and action. However, it does not explicitly distinguish from sibling tools like set_piano_keyboard, but the purpose is specific enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to show vs hide labels or alternatives. The description lacks context for when to use this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_piano_note_scaleA

Set the piano roll note scale (vertical zoom).

scale: Note scale factor (0.5 to 2.0). 1.0 = default, 2.0 = maximum zoom in, 0.5 = maximum zoom out.

Returns success with old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
scaleYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the parameter range and that it 'Returns success with old and new values', but does not mention side effects, persistence, or scope (global vs per-track).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. It front-loads the action and includes only essential information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter tool with an output schema, the description is fairly complete. It explains the parameter and return value. However, it could mention whether the zoom is global or per-track, or if any visual feedback occurs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'scale' is fully explained in the description with its range (0.5 to 2.0) and meaning of default and extremes. This compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Set the piano roll note scale (vertical zoom)'. It uses a specific verb-resource pair and distinguishes from siblings like set_piano_keyboard and set_piano_note_labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adjusting zoom but does not explicitly state when to use this tool versus alternatives (e.g., other piano roll settings). No exclusion criteria or context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_piano_time_rangeA

Set the piano roll time range (horizontal view width in quarter notes).

quarters: Time range in quarter notes (1.0 to 64.0). Smaller = more zoomed in.

Returns success with old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
quartersYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the burden. It specifies the return (old and new values) and parameter range (1.0 to 64.0). It could mention if it affects playback or is safe, but it is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus a brief parameter explanation. No redundant information. Front-loaded with purpose. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter setter, the description is complete: states action, parameter semantics, and return values. Output schema exists to detail return structure. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but the description adds meaning: units (quarter notes), range (1.0 to 64.0), and effect (smaller = more zoomed in). This compensates well for the lack of schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sets the piano roll time range (horizontal view width in quarter notes). The tool name and description are specific and distinct from sibling tools like set_piano_keyboard or set_piano_note_labels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates when to use (to change horizontal zoom) but does not explicitly state when not to use or provide alternatives. However, the tool's purpose is self-evident given the sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_playfield_sample_enabledA

Enable/disable a drum pad on a Playfield drum machine.

sample_index: Pad index (0-based). enabled: true to enable, false to mute the pad. unit_index: Audio unit index (-1 = auto-detect Playfield).

ParametersJSON Schema
NameRequiredDescriptionDefault
enabledYes
unit_indexYes
sample_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states the basic operation (enable/disable) without disclosing side effects, whether changes are immediate, or if it affects playback. The description is too minimal for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: a single sentence plus parameter definitions. It front-loads the main purpose and presents parameters clearly. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 required parameters, no enums, has output schema), the description is sufficiently complete. It covers the core operation and parameter roles. However, missing output schema details prevent full completeness, but the output schema likely handles that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains each parameter: sample_index (0-based pad index), enabled (boolean), and unit_index (integer, -1 for auto-detect). This adds meaning beyond the schema's titles, though it lacks details like value ranges or behavior of unit_index.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Enable/disable) and resource (drum pad on Playfield drum machine). It also briefly explains the parameters, making the purpose unambiguous. The name aligns with the description and distinguishes it from other set_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like copy_playfield_sample or list_playfield_samples. The description lacks context for selection, such as prerequisites or when to prefer one tool over another.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_positionC

Set the playback position in beats.

ParametersJSON Schema
NameRequiredDescriptionDefault
positionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It does not disclose behavioral traits such as whether the tool can be called during playback, what happens to the transport state, or if there are any side effects. It only states the action without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, making it concise. However, it lacks structure or front-loading of critical information. For a one-sentence description, it is efficient but could be more informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description is minimal. It does not mention prerequisites (e.g., engine running), edge cases, or the format of the position value (e.g., integer beats from start). The output schema exists but is not visible; still, the description could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds the unit 'beats' but does not clarify whether position is absolute from start, relative, or the expected range. The parameter 'position' remains underdescribed beyond its schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'playback position' with the unit 'beats'. It distinguishes from siblings like 'transport' (which controls play/stop) and 'set_loop_region' (which sets loop points). The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention whether it should be used during playback or stopped state, nor does it compare to 'transport' or 'seek' tools. The description lacks context for appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_colorA

Set the color (hue) of a region or clip.

Regions and clips use an Int32Field 'hue' for color. The hue is an integer that maps to a color in the HSL spectrum (0-360). Use this to visually distinguish sections (e.g. red for choruses, blue for verses).

track_index: Track index within the AU. region_index: Region/clip to color (0-based). hue: Color hue (0-360, e.g. 0=red, 120=green, 240=blue). unit_index: Audio unit index (-1 = search all AUs).

Returns old and new hue values.

ParametersJSON Schema
NameRequiredDescriptionDefault
hueYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description effectively discloses behavior: it sets hue, returns old/new values, and explains parameters including special value for unit_index. Does not mention side effects beyond mutation, but covers core behavior well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two clear paragraphs: purpose/example first, then parameter details. No redundancy, every sentence is informative and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input semantics, special values, returns old/new hue. Output schema exists, so last line suffices. Complete for a simple setter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All four parameters are explained with meaning: track_index, region_index (0-based), hue (0-360 with color mapping), unit_index (-1 searches all AUs). Schema has 0% description coverage, so description adds significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it sets the hue of a region/clip, explains hue as HSL 0-360, and gives color examples. However, it does not explicitly differentiate from sibling tools like set_clip_hue or set_bus_color, though the name is self-explanatory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides usage example ('red for choruses, blue for verses'), but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. Sibling set_clip_hue exists but is not contrasted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_durationC

Set the duration of a region.

duration_beats: New duration in beats (e.g. 4.0 = 1 bar in 4/4).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexNo
track_indexYes
region_indexYes
duration_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It does not mention effects on existing notes (truncation, stretching, etc.), constraints (min/max), or whether the operation is reversible. The schema type mismatch (integer vs float example) adds confusion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short, which is beneficial for readability, but it omits critical information about parameters and behavior. It is concise but at the expense of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (set duration) and the presence of an output schema, the agent might infer basic returns, but the description lacks details on region content handling, constraints, and error conditions. It is insufficient for safe and correct invocation without additional knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain all parameters. It only explains duration_beats, and with an inconsistency (integer vs float example). The other three parameters (unit_index, track_index, region_index) are not explained at all, leaving the agent to guess their meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action (Set) and the target (duration of a region). The example clarifies the unit (beats). This distinguishes it from other set_region_* tools which target different properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no context about selecting the correct region or track. The description is purely declarative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_labelB

Rename a region's label (display name).

label: New label text. unit_index: Audio unit index (-1 = search all AUs). track_index: Track index within the AU. region_index: Region to rename (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only states 'rename' without any behavioral details such as whether the label is overwritten, if the tool is destructive, or what the output schema contains. No annotations are present to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with only a two-line purpose statement and a bullet list of parameters. No superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and a hidden output schema, the description does not explain how to obtain indices (unit_index, track_index, region_index) or the overall project hierarchy. Missing context about what the tool returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides brief explanations for each parameter (e.g., unit_index: search all AUs with -1). This adds meaning beyond the schema's bare titles, though not deeply detailed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'rename' and the resource 'region label' clearly. However, it does not differentiate from sibling tools like set_region_color or set_region_mute, which are also about modifying region properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus other region-modification tools. No prerequisites or context for selecting this tool are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_loopA

Set loop parameters for a note region.

Looping repeats the note pattern within the region. The region duration can be longer than the loop, causing the notes to repeat.

loop_beats: Loop length in beats (e.g. 4.0 = 1 bar in 4/4). Set to 0 to disable loop. loop_offset_beats: Offset within the event collection where the loop starts. event_offset_beats: Offset added to all note positions. unit_index: Audio unit index (-1 = search all AUs). track_index: Track index within the AU. region_index: Region to modify (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
loop_beatsYes
unit_indexYes
track_indexYes
region_indexYes
loop_offset_beatsYes
event_offset_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Explains basic effect (looping, disable with 0) but omits side effects, error conditions, or destructiveness. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, with a clear logical flow: purpose, concept explanation, then parameter list. No wasted words, though more structured formatting could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values are covered. Lacks information on prerequisites (e.g., region must exist), error handling, or success criteria. Adequate for typical use but incomplete for edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 6 parameters are explained with clear examples and constraints (e.g., loop_beats = 0 disables loop, unit_index = -1 searches all AUs). Since schema descriptions are absent, this fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Set loop parameters for a note region', distinguishing it from the sibling 'set_loop_region' which likely handles global project loops. The verb+resource is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context on looping behavior but lacks explicit when-to-use or when-not-to-use compared to siblings like 'set_loop_region'. No guidance on prerequisites or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_muteB

Mute or unmute a specific region without deleting it.

mute: true to mute, false to unmute.

ParametersJSON Schema
NameRequiredDescriptionDefault
muteYes
unit_indexNo
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It mentions 'without deleting it' implying non-destructiveness, but lacks details on reversibility, side effects, or prerequisites (e.g., region must exist). The behavioral disclosure is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. The first states the purpose, the second documents the key parameter. No extraneous information, every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple boolean operation, the description is adequate. However, it omits parameter details for indices and does not reference the output schema. Given the presence of an output schema, the description could have been slightly more complete to fully guide the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for the 'mute' parameter ('true to mute, false to unmute'), which is helpful given 0% schema coverage. However, it does not explain track_index, region_index, or unit_index, leaving gaps for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: mute or unmute a specific region without deleting it. The tool name reinforces this purpose. However, it does not distinguish from sibling tools like set_clip_mute or set_track_mute.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only states what it does, without context on prerequisites, typical use cases, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_region_positionA

Move a region to a new position on the timeline.

position_beats: New position in beats (e.g. 4.0 = start of bar 2 in 4/4). region_type: 'note' or 'audio'. unit_index: Audio unit index (-1 = search all AUs). track_index: Track index within the AU. region_index: Region to move (0-based).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
region_typeYes
track_indexYes
region_indexYes
position_beatsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It explains parameters but does not disclose side effects (e.g., overwriting previous position, potential conflicts with other regions), required permissions, or if the operation is undoable. The term 'move' implies mutation but lacks detail on what changes occur beyond position.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise two-paragraph structure: purpose sentence followed by parameter explanations. Each parameter gets its own line with clear formatting. Could be slightly more terse, but overall efficient and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all parameters and action. Output schema exists (not shown) so return values are not needed. Does not mention how to locate the region (e.g., needing prior list calls), but for a move operation this is acceptable. Minor gap: no explanation of what happens if the target position is occupied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides clear, actionable semantics for all 5 parameters: explains units for position_beats (e.g., '4.0 = start of bar 2'), enum values for region_type, and the meaning of unit_index (-1 = search all AUs). This adds significant value beyond the raw schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action 'Move a region to a new position on the timeline.' The verb 'move' and resource 'region' are explicit, and the description distinguishes this from sibling tools like 'move_region_to_track' or 'set_region_duration' by focusing on timeline positioning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'move_region_to_track' or 'set_region_duration'. Does not mention prerequisites (e.g., region must exist) or context (e.g., undo behavior). This lack of usage direction makes it harder for an agent to decide when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_revamp_filterB

Configure a filter section on a Revamp (parametric EQ) effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Revamp). section: One of: "highpass", "lowshelf", "lowbell", "midbell", "highbell", "highshelf", "lowpass". enabled: Enable/disable this filter section. frequency: Center/cutoff frequency in Hz (20-20000, exponential). gain: Boost/cut in dB (-24 to 24, for shelves and bells only). q: Bandwidth/resonance (0.01-10, for bells and LPF). order: Filter steepness 1-4 (for HPF/LPF only).

ParametersJSON Schema
NameRequiredDescriptionDefault
qNo
gainNo
orderNo
enabledYes
sectionYes
frequencyNo
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits but fails to mention whether the tool is destructive, if it overwrites existing settings, or what happens on invalid input (e.g., effect index not pointing to a Revamp). It only lists parameters without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear first sentence followed by line-by-line parameter explanations. Each sentence serves a purpose, though the parameter details could potentially be integrated into the schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While parameter semantics are well-covered, the description lacks overall context such as what the tool returns (output schema exists but is not referenced), prerequisites (effect must be a Revamp), and behavior on success/failure. This is adequate but not fully complete given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning to the schema parameters, including ranges (e.g., frequency 20-20000 Hz exponential, gain -24 to 24 dB) and conditional applicability (e.g., gain for shelves/bells only, q for bells and LPF). This compensates for the 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool configures a filter section on a Revamp (parametric EQ) effect, specifying the verb 'configure' and the resource 'filter section' on a specific effect type. This distinguishes it from other set_* tools that operate on different parameters or effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives like set_effect_parameter. It does not specify prerequisites (e.g., the effect must be a Revamp) or when not to use it, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_script_device_codeA

Set the user JavaScript code on a scriptable device (Apparat/Werkstatt/Spielwerk).

Compiles the code using the official OpenDAW ScriptCompiler, which:

  • Parses @param declarations and creates WerkstattParameterBox children

  • Parses @sample declarations and creates WerkstattSampleBox children

  • Validates the JavaScript (new Function check)

  • Registers the worklet module on the AudioContext

  • Writes the code with proper // @ header back to the device

The code defines a Processor class that the host instantiates in the audio worklet. @param declarations: // @param [type] [unit] @sample declarations: // @sample See the openDAW plans/apparat.md, plans/spielwerk.md for the full API.

device_type: "apparat" (instrument), "werkstatt" (audio effect), "spielwerk" (MIDI effect)

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYes
unit_indexYes
device_typeYes
device_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the burden. It details compilation steps (parsing, validation, worklet registration, writing code). It does not mention destructive side effects or permissions, but provides substantial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately lengthy but well-structured with a clear core purpose and bullet-pointed steps. It is front-loaded and each sentence adds value, though could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists (not shown), description covers main aspects: purpose, compilation process, device types, and code syntax. It lacks prerequisites or error conditions, but is largely complete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds significant meaning for 'code' (syntax with @param/@sample) and 'device_type' (lists exact values). It does not detail 'unit_index' or 'device_index', but overall compensates well for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets user JavaScript code on a scriptable device, specifying the verb 'Set', the resource 'script device code', and the scope (Apparat/Werkstatt/Spielwerk). It distinguishes from siblings like get_script_device_code and other set_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the compilation process and lists device types with their roles, implying usage when programming a scriptable device. It lacks explicit when-to-use or alternatives but is clear enough for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_script_paramA

Set a parameter value on a scriptable device by label.

The parameter must exist (created from a // @param declaration in the code). The value is validated against the declaration's range (min/max) and mapping type:

  • bool: snaps to 0 or 1

  • int: rounds to nearest integer within [min, max]

  • linear/exp/unipolar: clamps to [min, max] Response includes clamped flag and range info if the value was adjusted.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
device_typeYes
param_labelYes
device_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description fully covers behavior: value validation against declaration's range, snapping/clamping per type (bool, int, linear/exp/unipolar), and response includes clamped flag and range info. This is highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with the purpose at the start, followed by necessary details on validation. It is slightly lengthy but each sentence serves a purpose; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of schema descriptions and annotations, the description covers the core behavior and response content ('clamped flag and range info'). It does not explain all parameters but is sufficient for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameter explanations in the schema. The description adds value by explaining the value parameter's validation rules, but does not explain device_type, unit_index, device_index, or param_label. It partially compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and resource 'parameter value on a scriptable device by label'. It is specific and distinguishes from other set_* tools by focusing on scriptable device parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the parameter must exist from a @param declaration and details validation behavior per type. However, it does not explicitly state when not to use this tool or provide direct comparisons to alternatives, though the context implies it is for scriptable devices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_send_levelA

Set the send level for an existing aux send.

src_unit: Source audio unit index. send_index: Send index on the source AU (from create_send return). level_db: Send level in dB.

ParametersJSON Schema
NameRequiredDescriptionDefault
level_dbYes
src_unitYes
send_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must bear behavioral disclosure. It states the mutation action but does not mention side effects, error conditions, or required permissions. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences: one for purpose, then each parameter on its own line. Front-loaded and no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return values need not be described. For a simple setter, the description covers core operation. Could add error handling notes but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds semantic context by listing parameters with brief explanations (e.g., 'src_unit: Source audio unit index'). However, lacks details like valid ranges or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Set the send level for an existing aux send', specifying the verb (Set) and resource (send level). It distinguishes from sibling tools like create_send, list_sends, and set_send_pan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use after send creation (references 'existing aux send' and 'send_index from create_send return'), but lacks explicit when/when-not guidance or alternative tool suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_send_panA

Set the stereo pan for an aux send (-1.0 = full left, 0.0 = center, 1.0 = full right).

unit_index: Source audio unit index. send_index: Send index on the source AU. pan: Pan value from -1.0 (left) to 1.0 (right).

ParametersJSON Schema
NameRequiredDescriptionDefault
panYes
send_indexYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, yet the description does not disclose behavioral traits such as whether the operation is destructive, requires existing sends, or returns a result. The tool has an output schema, but its content is not mentioned. This is insufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for the action followed by a bullet list for parameters. It is front-loaded with the primary purpose and wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks information about prerequisites (e.g., send must exist), potential side effects, and the return value (despite an output schema). Compared to sibling tools like set_send_level, it does not provide enough context for safe and correct use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Each parameter is described in plain language: unit_index as source AU index, send_index as index on source AU, and pan with allowed range. This adds meaning beyond the schema's type-only information, though it could specify zero-based indexing and error conditions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action ('Set the stereo pan for an aux send') and provides the range of the pan value. It distinguishes itself from sibling tools like set_send_level and set_send_routing by specifying 'pan' and 'stereo pan'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there are no when-to-use or when-not-to-use instructions, leaving the agent to infer from the name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_send_routingA

Set the routing mode for an aux send (pre-fader or post-fader).

unit_index: Source audio unit index. send_index: Send index on the source AU. routing: 'pre' (pre-fader, before volume/pan) or 'post' (post-fader, default).

ParametersJSON Schema
NameRequiredDescriptionDefault
routingYes
send_indexYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description minimally discloses behavior: sets routing mode with two possible values and a default. Does not mention side effects, permissions, or safety implications of changing routing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence plus a concise parameter list. Purpose is front-loaded. No redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers the tool's operation and parameter meanings for a simple setter. Output schema exists, so return values are not needed in description. Could mention error conditions or prerequisites but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains each parameter: unit_index as source audio unit, send_index as index on source AU, and routing as 'pre' or 'post' with default. This adds meaning beyond the schema's titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'routing mode for an aux send', specifying pre-fader or post-fader. It distinguishes from sibling tools like set_send_level and set_send_pan by focusing on routing mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, or prerequisites (e.g., send must exist). The description lacks context about when pre vs post routing is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_stereo_tool_panningA

Set the panning mixing mode on a StereoTool effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a StereoTool). panning_mixing: Panning law (0=linear, 1=equal-power, or other supported values).

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
effect_indexYes
panning_mixingYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral burden. It explains parameter meanings but lacks details on side effects, error handling (e.g., if effect_index is not a StereoTool), or whether the change is immediate or reversible. The output is not described, though an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: one sentence for the purpose followed by three lines for parameters, each on its own line. It is front-loaded with the action and avoids extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains parameter semantics but lacks context on prerequisites (e.g., ensuring the unit has a StereoTool effect on the given effect_index) and error conditions. Given the tool has 3 required parameters and an output schema, the description is minimally adequate but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does so by explicitly defining each parameter: unit_index, effect_index, and panning_mixing with possible values (0=linear, 1=equal-power, or other supported values). This adds significant meaning beyond the schema's bare titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set the panning mixing mode') and the resource ('on a StereoTool effect'). It distinguishes this tool from sibling tools like set_track_panning, set_send_pan, etc., by specifying the target effect type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by specifying the condition 'must be a StereoTool', but does not explicitly state when to use this tool versus alternatives like set_track_panning or set_send_pan. No exclusion criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_studio_settingA

Set a studio preference setting.

Args: category: Settings category — one of: 'engine', 'visibility', 'editing', 'debug', 'storage', 'time-display', 'pointer' key: Setting key within the category (e.g. 'auto-create-output-maximizer', 'overlapping-regions-behaviour', 'enable-beta-features') value: New value as string — 'true'/'false' for booleans, or string values for enums

Common settings: engine.auto-create-output-maximizer (bool): auto-create Maximizer on Output unit engine.note-audition-while-editing (bool): play notes when editing engine.stop-playback-when-overloading (bool): stop playback on CPU overload editing.overlapping-regions-behaviour ('clip'|'push-existing'|'keep-existing'): how overlapping regions interact editing.show-clipboard-menu (bool): show clipboard menu debug.enable-beta-features (bool): enable beta features debug.enable-debug-menu (bool): enable debug menu debug.show-cpu-stats (bool): show CPU stats storage.auto-delete-orphaned-samples (bool): auto-delete unused samples visibility.auto-open-clips (bool): auto-open clips visibility.base-frequency (bool): show base frequency

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYes
valueYes
categoryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description provides moderate transparency by detailing argument types and common settings. However, it does not disclose side effects, persistence, or error handling behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and structured into args and common settings. While the list of common settings is lengthy, it is well-organized and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return values are covered. However, the description lacks preconditions (e.g., valid key for category) and postconditions (e.g., immediate effect, persistence). It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), so the description carries the full burden. It explains the 'category' enum, gives example 'key' values, and specifies 'value' format. The list of common settings adds substantial meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set a studio preference setting' with a specific verb and resource. It lists examples of categories and common settings, distinguishing it from the sibling 'get_studio_settings' for reading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (to change settings) but lacks explicit guidance on when not to use or alternatives. It does not mention that 'get_studio_settings' should be used to read current values.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_tidal_rateA

Set the LFO rate on a Tidal effect using a musical fraction string.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Tidal). rate: Musical fraction — one of: "1/1", "1/2", "1/3", "3/16", "1/6", "1/8", "3/32", "1/12", "1/16", "3/64", "1/24", "1/32", "1/48", "1/64", "1/96", "1/128".

ParametersJSON Schema
NameRequiredDescriptionDefault
rateYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden for behavioral context. It only states the action ('set') and valid rate values, but omits side effects, permissions, error conditions, or what happens with invalid indices.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence plus a bullet list; no waste. Front-loads the purpose and then details parameters concisely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input parameters well but lacks output behavior, error handling, and side effects. With no annotations, more behavioral context would be needed for completeness. Output schema exists but is not provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, description adds meaningful context: clarifies unit_index, effect_index (must be Tidal), and lists all valid rate strings. Supplements the bare schema effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (set), resource (LFO rate on a Tidal effect), and method (using a musical fraction string). Distinct from siblings by specifying a particular effect parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., effect must be Tidal, indices must exist), and no comparison to other setter tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_time_signatureA

Set the project time signature (e.g. 4/4, 3/4, 6/8, 7/8).

numerator: Number of beats per bar (top number, e.g. 4, 3, 6, 7). denominator: Note value per beat (bottom number: 4=quarter, 8=eighth).

ParametersJSON Schema
NameRequiredDescriptionDefault
numeratorYes
denominatorYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states it sets the time signature, without mentioning side effects (e.g., whether existing notes are moved, if it applies to all tracks, if it requires project to be open). This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: one introductory sentence followed by two clear parameter explanations. No extra words, front-loaded with the action, and well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 required params, no nested objects, output schema exists), the description explains the parameters adequately. However, it omits what the tool returns or any constraints on valid values, but for a straightforward setter, this is almost complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains numerator as 'number of beats per bar' and denominator as 'note value per beat' with examples (4=quarter, 8=eighth), adding meaning beyond the integer type and title in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Set the project time signature' with concrete examples (4/4, 3/4, 6/8, 7/8), differentiating it from siblings like add_signature_change or create_balkan_meter by focusing on the global project setting. It explicitly defines numerator and denominator roles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool sets the overall project time signature, but does not explicitly contrast with siblings like mcp_opendaw_add_signature_change (which likely adds a local change). No guidance on when to use each, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_time_stretch_centsA

Set the pitch shift (in cents) on a time-stretched audio region.

100 cents = 1 semitone. Range: -1200 to +1200 cents (clamped). Only works on time-stretched regions (created with create_time_stretched_region).

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. cents: Pitch shift in cents (-1200 to +1200).

Returns new playback rate and cents, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
centsYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral traits. It discloses that the tool sets pitch shift with clamping, returns new playback rate and cents or error, and only works on specific regions. It does not explicitly mention that it modifies the region's playback rate (implied by return value) or discuss side effects, undo capability, or authorization needs, but is still fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using short paragraphs and bullet-style lines for parameters. The first line clearly states the tool's purpose. Every sentence adds value: range, prerequisite, parameter explanations, return value. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema likely exists and the description mentions return values, it covers the essential behavior. It could mention that the region must exist or error scenarios, but for a simple setter, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain each parameter. It does so for all four parameters: unit_index, track_index, region_index, and cents, including the range and meaning of cents. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the pitch shift in cents on a time-stretched audio region, specifying the action ('set'), the domain ('time-stretched audio region'), and the unit ('cents'). It implicitly distinguishes from sibling tools like set_note_cents (MIDI) or set_transpose (general) by focusing on time-stretched regions, but does not explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the prerequisite: 'Only works on time-stretched regions (created with create_time_stretched_region).' This tells the agent when not to use it. It also provides the valid range and clamping behavior. However, it does not mention alternative tools for non-time-stretched regions, but the sibling list provides context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_track_enabledB

Enable or disable a track (equivalent to track mute in the UI).

unit_index: AU index. track_index: Track index within the AU. enabled: True to enable, false to mute/disable.

Returns success with old and new enabled state.

ParametersJSON Schema
NameRequiredDescriptionDefault
enabledYes
unit_indexYes
track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full burden. It mentions returning old and new state, providing some return behavior context, but lacks details on side effects, permissions, or destructive nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear one-line purpose, parameter explanations, and a return statement. No superfluous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basics but omits context about indexing scheme, prerequisites, or how it relates to other mute/enable tools. The output schema exists, so return detail is adequate but incomplete overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning by explaining each parameter (unit_index, track_index, enabled) in plain terms, compensating for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool enables or disables a track, using specific verb and resource. However, it claims equivalence to track mute, which could cause confusion given the sibling tool 'set_track_mute' exists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'set_track_mute'. The sibling list contains both tools, but the description does not differentiate them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_track_muteC

Mute or unmute an audio unit.

ParametersJSON Schema
NameRequiredDescriptionDefault
muteYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only states the action (mute/unmute) without any behavioral details such as effects on playback, undo support, or prerequisites. No annotations are provided to supplement this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence), which is efficient but lacks necessary detail for safe tool usage. It balances brevity and completeness poorly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, low schema coverage, and a minimal description, the tool is under-specified. Context like track identification and mute semantics are missing, making it hard for an agent to use correctly without prior knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain the parameters. The boolean 'mute' and integer 'unit_index' are self-explanatory but the agent needs to know that unit_index refers to a track index and that true/false maps to mute/unmute.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool mutes or unmutes an audio unit, aligning with the tool name that includes 'set_track_mute'. However, it uses 'audio unit' instead of 'track', causing slight ambiguity. Overall, verb and resource are clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like set_track_solo, set_track_enabled, or set_clip_mute. The agent must infer context from the tool name and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_track_panningC

Set panning of an audio unit. -1.0 = full left, 0.0 = center, 1.0 = full right.

ParametersJSON Schema
NameRequiredDescriptionDefault
panningYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description does not disclose behavioral traits such as whether it is destructive, real-time, or has side effects. Only the panning range is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. Front-loaded with the action and range. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple schema and no annotations, the description is incomplete. It does not explain what unit_index refers to, nor does it mention output or behavior. The existing explanation of panning range is helpful but insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. The description explains the panning parameter range but does not describe the unit_index parameter at all, leaving its purpose unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'set panning' and the resource 'audio unit'. It also explains the panning range. However, it does not differentiate from sibling tools like mcp_opendaw_set_stereo_tool_panning, which also sets panning. The mention of 'audio unit' might be slightly inconsistent with the tool name's 'track'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No prerequisites, conditions, or when-not-to-use are provided. The description only explains the function and range.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_track_soloC

Solo or unsolo an audio unit.

ParametersJSON Schema
NameRequiredDescriptionDefault
soloYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description does not explain behavioral consequences such as whether other tracks become muted, how existing solo states are affected, or what the default state is. The boolean parameter implicitly indicates setting or unsetting solo, but no further context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise—one sentence—with no wasted words. However, it could benefit from slight expansion to clarify key terms. It is not verbose, but brevity comes at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (though not detailed here), the description should at least clarify what the unit_index represents and any side effects. It lacks essential context for an agent to use correctly, especially in a project with many tracks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description adds no information about the parameters: 'unit_index' is not explained (e.g., what it refers to, what range is valid) and 'solo' is minimally described as a boolean. The tool fails to clarify the relationship between unit_index and tracks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Solo or unsolo an audio unit' clearly states the action (solo/unsolo) on a resource (audio unit). However, 'audio unit' is ambiguous; from the tool name it likely refers to a track, but it's not explicitly stated, and no differentiation from sibling tools like set_track_mute or set_solo_automation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention when soloing is appropriate, how it interacts with other tools, or when to use set_solo_automation instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_track_volumeB

Set volume of an audio unit in dB.

Uses VolumeMapper.decibel(-96, -9, +6) powerByCenter mapping. Range: -96 dB (mute) to +6 dB. 0 dB = raw 0.768.

ParametersJSON Schema
NameRequiredDescriptionDefault
volume_dbYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite lacking annotations, the description discloses the mapping function (powerByCenter), range (-96 to +6 dB), and the 0 dB mapping to 0.768. This adds some behavioral awareness, but does not address side effects, permissions, or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each adding distinct information: action, mapping, range and 0 dB reference. No filler, but could be more concise by merging technical details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return value details are covered. However, with no annotations, the description misses prerequisites (e.g., does the unit need to exist?) and behavioral constraints, leaving gaps for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description should explain both parameters. It implicitly describes volume_db (dB value) but does not explicitly mention unit_index's role. The mapping details add context for volume_db but not enough for completely clear parameter use.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set volume of an audio unit in dB') and provides technical details like range and mapping, but the term 'audio unit' slightly diverges from the tool name's 'track', and it doesn't explicitly distinguish from sibling set tools (e.g., set_track_mute).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like set_track_panning or set_track_mute. The description only provides internal implementation details (VolumeMapper), not usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_transposeB

Set global transpose for the piano roll view (does not affect audio playback).

semitones: Number of semitones to transpose (-48 to +48).

Returns success with old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
semitonesYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It discloses that the operation is a view-only global transpose (no audio effect) and returns old/new values. However, it omits details like scope (affects all tracks?), reversibility, prerequisites, or side effects. This is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, parameter explanation, return value. It is front-loaded and efficient. Every sentence adds value, though it could be slightly more concise by combining the return info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter with one parameter and an existing output schema, this description covers the basics. However, it lacks context about the scope of the global setting (e.g., does it apply to the entire project or only the current track?), which would be helpful for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only the parameter name and type with no description. The tool description adds the valid range (-48 to +48) and explains the purpose ('Number of semitones to transpose'). This significantly enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and resource 'global transpose for the piano roll view', and adds a clarifying note ('does not affect audio playback'). However, it does not distinguish from similar sibling tools like transpose_notes or diatonic_transpose_notes, which would help an agent choose the correct tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't explain that this is a global view setting, contrasting with per-note transposition. The agent is left to infer usage context from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_tuningA

Set the A4 base frequency (concert pitch tuning).

frequency: A4 frequency in Hz. Default 440. Common alternatives: 432 (verdi), 415 (baroque), 466 (baroque organ).

ParametersJSON Schema
NameRequiredDescriptionDefault
frequencyYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose effects on the project, whether operation is destructive, or if it affects global vs. per-track tuning. Only mentions parameter range.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two lines, no wasted words. Purpose stated first, then parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given single parameter and presence of output schema, description is mostly complete. Could mention if tuning affects global or per-project, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds meaning beyond schema: explains frequency unit (Hz), default value (440), and common alternatives with historical context. Schema has 0% coverage, so this is essential.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool sets the A4 base frequency for concert pitch tuning. Distinct from sibling tools like set_bpm or set_transpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. It only describes the parameter but doesn't explain contexts where tuning adjustment is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_unit_minimizedA

Minimize or expand an audio unit in the mixer view.

Minimized AUs take less space in the mixer — useful for decluttering when working with many tracks.

unit_index: AU index. minimized: True to minimize, False to expand.

Returns success with old and new minimized state.

ParametersJSON Schema
NameRequiredDescriptionDefault
minimizedYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that the tool returns 'old and new minimized state', which is helpful. However, it does not mention any potential side effects (e.g., whether minimizing affects audio processing) or prerequisites (e.g., unit must exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: a one-line purpose, a brief use case, parameter explanations, and return value. Every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (not shown) and the description mentions the return values. For a simple toggle operation, this is sufficient. It could mention that the unit must exist, but that is likely implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaningful explanations for both parameters: 'unit_index: AU index' and 'minimized: True to minimize, False to expand'. This goes beyond the bare schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Minimize or expand an audio unit in the mixer view') and the resource (audio unit). It distinguishes from sibling tools like freeze_audiounit or move_audio_unit by focusing on the visual minimized state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool ('useful for decluttering when working with many tracks'). It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_vaporisateur_osc_paramA

Set a parameter on a Vaporisateur oscillator.

osc_index: Oscillator index (0, 1). param_name: One of: waveform, volume, octave, tune. waveform: 0=Sine, 1=Triangle, 2=Saw, 3=Square volume: dB (-Infinity to +6) octave: integer offset tune: semitone offset (float) value: New value. unit_index: Audio unit index (-1 = auto-detect).

Returns old and new values.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueYes
osc_indexYes
param_nameYes
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially compensates by documenting valid parameter values and ranges (e.g., waveform enum, volume in dB). However, it does not disclose behavioral aspects like immediate application, undoability, or side effects. The mention of returning old and new values adds some transparency, but the absence of broader behavioral context leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise, with a clear opening sentence followed by a structured list of parameters. The bullet-point format for param_name details is efficient. Minor improvement could be made by separating the parameter list more distinctly, but overall it is well-organized and not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core functionality and parameter details adequately for a setter tool. Given that an output schema exists, the mention of return values is helpful. However, it lacks contextual completeness by omitting prerequisites (e.g., Vaporisateur must be in the chain), potential errors, or usage examples. It is minimally viable but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage (no descriptions on properties), so the description fully compensates. It provides detailed semantics for each parameter: osc_index range, param_name with valid values and their meanings, value with units and range, and unit_index with auto-detect hint. This goes well beyond the schema's bare type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set a parameter on a Vaporisateur oscillator.' It specifies the exact resource (Vaporisateur oscillator) and action (set parameter), and distinguishes from sibling tools like set_effect_parameter or set_instrument_param by focusing on a specific device. The listing of valid param_names and their meanings further clarifies its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., Vaporisateur must be loaded), when not to use it, or compare with other set_* tools. This lack of contextual usage information makes it harder for an AI agent to decide when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_vocoder_band_countA

Set the band count on a Vocoder effect (number of filter bands, typically 8-32).

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Vocoder). band_count: Number of bands (8, 16, 24, 32 are common values).

ParametersJSON Schema
NameRequiredDescriptionDefault
band_countYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that effect_index must point to a Vocoder effect but does not mention immediate effects, reversibility, or return values. Partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short: two sentences plus a list of three parameters. It is front-loaded with the purpose and contains no unnecessary information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple setter, it covers purpose, parameters, and typical values. It does not discuss error conditions or validation, but output schema exists so return values are handled. Minor gap: band_count values are not enforced by schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates well. It explains each parameter: unit_index as AU index, effect_index as effect index (must be Vocoder), and band_count with typical values (8,16,24,32). This adds meaning beyond the integer type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Set the band count on a Vocoder effect' and specifies the resource (Vocoder effect) and attribute (band count). It gives a typical range (8-32) and distinguishes from siblings like set_vocoder_modulator_source, which sets a different parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by requiring a Vocoder effect but does not explicitly state when to use this tool versus alternatives. It lacks guidance on conditions or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_vocoder_modulator_sourceB

Set the modulator source on a Vocoder effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Vocoder). source: One of "noise-white", "noise-pink", "noise-brown", "self", "external".

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It indicates a mutation operation ('Set') but does not disclose side effects, permissions, or constraints beyond the effect type. The behavioral impact of changing the source is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main action. However, it repeats parameter names as mere labels, which could be trimmed. Overall, it is efficient and reasonably structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists (not shown), so return values need not be explained. However, for a mutation tool, the description lacks context about expected outcome (e.g., immediate change) and fallback behavior. It is minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaning by explaining each parameter: unit_index as 'AU index', effect_index as effect index in chain (must be Vocoder), source with five explicit enum values. This goes beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set the modulator source on a Vocoder effect', using a specific verb and resource. It distinguishes itself from sibling 'set_' tools by targeting a specific effect type and parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not provide prerequisites (e.g., existence of a Vocoder effect) or when not to use it. The description only lists parameters without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_set_waveshaper_equationA

Set the transfer function equation on a Waveshaper effect.

unit_index: AU index. effect_index: Effect index in the audio effect chain (must be a Waveshaper). equation: One of: "hardclip", "cubicSoft", "tanh", "sigmoid", "arctan", "asymmetric". - hardclip: harsh digital clipping - cubicSoft: warm soft clipping, odd harmonics - tanh: classic smooth saturation - sigmoid: exponential saturation - arctan: gentlest symmetric saturation - asymmetric: tube-like, even harmonics from asymmetry

ParametersJSON Schema
NameRequiredDescriptionDefault
equationYes
unit_indexYes
effect_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It explains that this sets a transfer function (a mutation) and enumerates equation options with brief descriptions. However, it does not disclose side effects (e.g., whether it replaces the current equation), error conditions (e.g., invalid effect_index), or permission requirements. More transparency is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a brief first line summarizing purpose, followed by parameter listings and equation details. It is reasonably concise, with each sentence adding value. Minor redundancy (e.g., repeating equation in list) could be trimmed, but overall effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, return values are not needed. The description covers the core functionality and parameters but lacks prerequisites (e.g., need a Waveshaper effect added first) and error handling. For a mutation tool among many siblings, additional contextual guidance would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters: unit_index (AU index), effect_index (must be a Waveshaper), and equation (lists all valid values with descriptions). This adds significant value beyond the raw schema, though it could elaborate on constraints like valid ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Set the transfer function equation on a Waveshaper effect' with a specific verb and resource. It distinguishes itself from sibling 'set_' tools by explicitly targeting a Waveshaper effect, which is unique among the many set tools listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by requiring effect_index to be a Waveshaper but does not explicitly state when to use this tool versus alternatives. It lacks exclusion criteria or context about prerequisite steps (e.g., adding a Waveshaper first). The equation options are listed but without guidance on selecting based on desired sonic outcome.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_shift_modeA

Transform notes from one scale/mode to another, keeping the tonic.

Finds which scale degrees differ between from_scale and to_scale, then shifts ONLY the notes on those degrees by the interval difference. The tonic (degree 1) and unchanged degrees stay put — the transformation is surgical, not a blanket snap.

Examples: shift_mode(root_note="A", from_scale="minor", to_scale="dorian") → minor 6th (Ab) becomes major 6th (F#). A minor → A dorian. Only notes on degree 6 shift (+1 semitone). Everything else stays. shift_mode(root_note="E", from_scale="minor", to_scale="phrygian") → degree 2 (F#) becomes F natural (-1 semitone). E minor → E phrygian. shift_mode(root_note="D", from_scale="major", to_scale="mixolydian") → degree 7 (C#) becomes C natural (-1 semitone). D major → D mixolydian. shift_mode(root_note="C", from_scale="minor", to_scale="harmonic_minor") → degree 7 (Bb) becomes B natural (+1 semitone). C minor → C harmonic minor.

Unlike force_scale_notes (snaps to nearest scale tone — can change the melodic shape), shift_mode preserves the contour: notes that are already in the target scale don't move. Only the specific degrees that differ between the two scales are shifted.

Unlike reharmonize_progression (works on chord symbols), shift_mode works on individual notes in a region.

Args: unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks). region_index: Region index (-1 = all regions on track). root_note: Tonic note (C, C#, D, ...). Stays the same for both scales. from_scale: Source scale name. to_scale: Target scale name. preserve_root: If True (default), never shift the tonic pitch class. If False, allow tonic to shift (rare, only for non-modal transformations).

Returns per-note shift details: which pitch classes moved, by how much, and total notes affected.

ParametersJSON Schema
NameRequiredDescriptionDefault
to_scaleNodorian
root_noteNoC
from_scaleNominor
unit_indexNo
track_indexNo
region_indexNo
preserve_rootNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full disclosure burden. It explains the surgical behavior, tonic preservation, and per-note shift logic. While it doesn't explicitly mention edge cases (e.g., notes outside from_scale), the detailed examples and parameter descriptions provide sufficient behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with summary, behavior explanation, examples, comparisons, and args. However, it is somewhat verbose—some sentences could be trimmed without losing value, but the overall organization aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description adequately covers the tool's complexity: 7 parameters explained, behavior contrasted with siblings, and return value mentioned. No missing critical information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes an 'Args' section that explains every parameter, including defaults and special values like -1. This adds substantial meaning beyond the bare schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource ('Transform notes from one scale/mode to another, keeping the tonic') and explicitly distinguishes itself from sibling tools like force_scale_notes and reharmonize_progression, making its unique function unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when-not guidance by contrasting with force_scale_notes (snaps to nearest scale tone) and reharmonize_progression (works on chord symbols), and includes multiple examples illustrating typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_shuffle_notesA

Shuffle note data randomly within a region.

Random permutation of notes — unlike rotate_notes (deterministic cyclic shift), this creates non-repeating orderings. Seeded for reproducibility: same seed = same shuffle.

Modes:

  • "pitches": shuffle which pitch goes to which position (keeps rhythm, changes melody). Most musical — generates melodic variations from existing note set.

  • "rhythm": shuffle which position+duration goes to which pitch (keeps pitches, changes rhythm). Reassigns onset times among existing pitch values.

  • "full": shuffle pitch + position + duration + velocity together (complete randomization of all note attributes).

  • "within_groups": shuffle pitches within groups of group_beats beats. Notes stay in their time window but pitches get randomized within each group. Creates localized variation.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) mode: Shuffle mode — "pitches", "rhythm", "full", "within_groups" seed: PRNG seed (0 = random each call, >0 = reproducible) shuffle_amount: 0.0-1.0, fraction of notes to shuffle (0=no change, 1=full shuffle, 0.5=shuffle half) preserve_first: Keep first note unchanged (anchor point) preserve_last: Keep last note unchanged (resolution point) group_beats: Group size in beats for within_groups mode (e.g. 4 = shuffle within each bar, 2 = within half bars)

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNopitches
seedNo
unit_indexYes
group_beatsNo
track_indexYes
region_indexNo
preserve_lastNo
preserve_firstNo
shuffle_amountNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains shuffle behavior and parameter effects but does not disclose that it modifies the region in place, whether it's undoable, or other side effects. The description adds value but lacks full behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose statement, mode explanations, and an Args list. It is front-loaded and efficient, though the Args section could be slightly more concise by avoiding repetition of defaults. Overall clear and not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no annotations), the description covers all relevant aspects. It mentions reproducibility and differentiates from a key sibling. The existence of an output schema means return values need not be explained. Could be slightly more complete by noting that the shuffle modifies the region directly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates thoroughly by explaining all 9 parameters, including mode options and their musical implications, seed reproducibility, and the meaning of shuffle_amount and preserve flags. This exceeds the baseline of 4 for no schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Shuffle note data randomly within a region' and contrasts with rotate_notes, making the purpose and differentiation explicit. It uses a specific verb (shuffle) and resource (note data in a region), and distinguishes from a sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context on when to use different modes (e.g., 'Most musical — generates melodic variations' for pitches) and mentions reproducibility with seeds. However, it does not explicitly state when not to use or compare with other randomization siblings like humanize_notes or randomize_note_chance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_split_note_regionA

Split a note region into two at a given beat position.

Creates a new region starting at split_beat containing all notes from that position onward. The original region's duration is trimmed to split_beat. Notes that straddle the split point are kept in the original region (they will play their full duration even if they extend past the trimmed region boundary — this matches DAW behaviour).

Use cases:

  • Divide a long region into sections (e.g. split at bar 8 for verse/chorus)

  • Cut silence off the end of a region

  • Create variations: split, then modify one half

  • Prepare for arrangement edits (move one half elsewhere)

unit_index: AU index. track_index: Note track index. region_index: Region to split (0-based). split_beat: Absolute beat position to split at (must be within region range).

Returns original and new region details.

Example:

Split region 0 at bar 8 (beat 32 in 4/4)

split_note_region(0, 0, 0, 32)

ParametersJSON Schema
NameRequiredDescriptionDefault
split_beatYes
unit_indexYes
track_indexYes
region_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It details behavior: original trimmed, new region created, straddling notes kept. It does not mention undo or side effects, but the behavior is transparent enough for a split operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, behavior, use cases, parameter list, returns, example. Each section is concise and useful, no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, no need to explain return values. The description covers all necessary aspects: behavior, use cases, parameters, and example, making it fully complete for a split tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description compensates fully. It explains all 4 parameters (unit_index, track_index, region_index, split_beat) with purpose and constraints (split_beat must be within region range), plus an example. Adds significant meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: split a note region into two at a given beat position. It explains the behavior (trim original, create new region, handle straddling notes) and distinguishes from sibling tools like merge or delete by the specific splitting action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases (e.g., divide long region, cut silence, create variations) and an example, guiding when to use. It lacks explicit when-not or alternative tools, but the context and use cases sufficiently indicate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_split_stemsA

Split an audio file into stems using SOTA open-source separation models.

Runs locally on GPU (GTX 1650 4GB, ~4.5 min for 4-min track). All models trained at 44100Hz — auto-resampling handled internally.

input_path: Absolute path to input audio file (WAV/MP3/FLAC/OGG). mode: Separation mode (default "bs6"): - "ensemble": Max quality, 4 passes (bass/drums/vocals/other). Slowest, best SDR. - "scnet": 4-stem (drums/bass/other/vocals). Best single-pass multi-stem. - "bs6": 6-stem (bass/drums/other/vocals/guitar/piano). Fast, low bleeding. - "polarformer": Vocal extraction only (vocals/instrumental). - "dereverb": Remove reverb from vocals (dry/reverb). - "drumsep": Drum separation (kick/snare/cymbals/toms). - "denoise": Noise cleanup for low-quality sources (clean/noise). output_dir: Directory for stem files (default: /tmp/stems_). import_to_daw: If True, load each stem into the DAW and return sample IDs for use with place_audio_region. Requires DAW bridge running.

Returns list of stem file paths (and sample IDs if import_to_daw=True).

Workflow: split_stems("track.wav", "bs6") → 6 stem WAVs split_stems("track.wav", "ensemble", import_to_daw=True) → 4 stems loaded into DAW

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNobs6
input_pathYes
output_dirNo
import_to_dawNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It reveals performance (GPU, time estimate), resampling behavior, and return value format. It does not mention destructiveness or auth requirements, but the mutation aspect (creating files) is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear hierarchy: purpose, hardware notes, parameter list, return value, and workflow examples. It is moderately long but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no schema descriptions, and an output schema, the description covers all parameters, return values, and provides workflow examples. It is comprehensive for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description explains each parameter thoroughly: input_path (format), mode (all options with descriptions), output_dir (default format), and import_to_daw (behavior and return value impact).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Split' and resource 'audio file into stems', with specific mention of SOTA models. It distinguishes itself from siblings like 'separate_stems' by detailing the model options and their stem counts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed guidance on when to use each mode (e.g., 'ensemble: Max quality, 4 passes', 'bs6: 6-stem, fast, low bleeding') and explains the import_to_daw workflow. However, it does not explicitly compare with the similar sibling 'mcp_opendaw_separate_stems' or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_spread_voicingA

Spread or compact a chord voicing — open vs close harmony.

Transforms the spacing between chord tones at a specific beat position. Close voicing (all notes within one octave) sounds tight and focused. Open voicing (notes spread across multiple octaves) sounds wide and spacious — the hallmark of jazz piano, film score strings, and orchestral arrangements.

mode: "open" — move every other note up by spread_octaves octaves. This creates drop-2/drop-3 style open voicings from close chords. The lowest note stays, the next goes up an octave, the next stays, etc. Result: wider intervallic spacing, more airy sound. mode: "close" — collapse all chord tones into the lowest possible octave (within 12 semitones from the lowest note). Compresses spread voicings back to close harmony. Useful for tight block chords after open passages. mode: "drop2" — drop the second-highest note down an octave. Classic jazz piano voicing technique. Creates the quintessential "comping" sound. mode: "drop3" — drop the third-highest note down an octave. Another standard jazz voicing, slightly wider than drop2.

chord_position: Beat position where the chord starts (finds all notes at this position, groups them as a chord). spread_octaves: For "open" mode — how many octaves to spread (1-3, default 1). 1 = subtle widening, 2 = very open, 3 = extreme.

Returns original pitches, new pitches, mode used, chord size.

Example:

Open up a close triad for jazz piano sound

spread_voicing(0, 2, 0, 4.0, mode="open")

Classic drop-2 jazz voicing

spread_voicing(0, 2, 0, 4.0, mode="drop2")

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNoopen
unit_indexYes
track_indexYes
region_indexYes
chord_positionYes
spread_octavesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description fully carries the burden. It details exactly what each mode does to notes (e.g., 'move every other note up by spread_octaves octaves') and lists return values (original pitches, new pitches, mode used, chord size). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: summary, mode explanations, parameters, examples. It is somewhat lengthy but every section adds value. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 modes and chord transformation complexity, the description covers purpose, mode mechanics, parameter roles, return values, and an example. With output schema present, it is sufficiently complete for an agent to understand and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains mode (4 options with details), chord_position (beat position), and spread_octaves (range and default). It does not explain unit_index, track_index, or region_index, but these are common DAW identifiers likely understood from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Spread or compact a chord voicing — open vs close harmony.' It specifies the action (transform spacing) and resource (chord tones at a beat position), and is distinct from sibling tools like create_comping or invert_chord_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each mode (open, close, drop2, drop3) is explained with its musical effect and typical use cases, e.g., 'Classic jazz piano voicing technique' for drop2. The example shows concrete usage. However, it doesn't explicitly contrast with alternative tools or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_start_engineA

Start the audio engine (AudioWorklet) after setting up tracks and regions.

Call this AFTER loading audio, creating tracks, and placing regions — but BEFORE playback or effects. The engine serializes the current project state into the AudioWorklet processor, so all boxes must exist first.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although no annotations are provided, the description explains the key behavioral trait: 'The engine serializes the current project state into the AudioWorklet processor, so all boxes must exist first.' This gives the agent insight into what happens internally and why ordering matters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise—only three sentences. The first sentence states the core purpose, and the next two provide essential usage guidelines and behavioral insight. Every sentence is necessary and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no complex side effects) and the presence of an output schema (so return details are already documented), the description covers all necessary context: purpose, prerequisites, sequence, and internal behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning, but it provides relevant context about the tool's prerequisites and behavior, which is more than sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Start the audio engine' and identifies the resource ('AudioWorklet'). It includes the prerequisite 'after setting up tracks and regions', which distinguishes it from other engine control tools like engine_panic, engine_sleep, and engine_wake.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies when to call the tool: 'Call this AFTER loading audio, creating tracks, and placing regions — but BEFORE playback or effects.' This provides clear sequencing and context, though no alternatives are listed since this is a one-time startup step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_strum_notesA

Strum simultaneous notes — convert block chords into guitar-style strums.

Finds groups of notes that start at the same position (within a small tolerance) and offsets them in time to simulate a pick or strum crossing the strings. This transforms static chord pads into lifelike guitar parts.

direction: Strum direction:

  • "down" — low to high (bass strings first, treble last). Default for downstrokes. Most natural for guitar.

  • "up" — high to low (treble first, bass last). Upstroke feel.

  • "random" — random order per chord. Banjo/ukulele feel.

speed: Time between consecutive strings in beats. 0.03125 = 1/32 note (fast shred), 0.0625 = 1/16 (standard strum), 0.125 = 1/8 (slow arpeggiated strum), 0.25 = 1/4 (very slow, harp-like). Range 0.005 to 0.5.

jitter: Random timing variation per string (0.0 = exact, 0.02 = ±2% of speed as humanization). Adds realism. Range 0.0-0.1.

Notes are sorted by pitch within each chord group, then offset by speed × index from the original start position. The first note stays at the original position; subsequent notes are delayed.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track).

Returns per-track chord groups found, notes strummed.

Example:

Standard downstroke — 1/16 between strings

strum_notes(unit_index=0, track_index=2, direction="down", speed=0.0625)

Slow harp-like arpeggiation

strum_notes(unit_index=0, track_index=2, direction="down", speed=0.25)

Upstroke with humanization

strum_notes(unit_index=0, track_index=2, direction="up", speed=0.0625, jitter=0.03)

ParametersJSON Schema
NameRequiredDescriptionDefault
speedNo
jitterNo
directionNodown
unit_indexNo
track_indexNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details the algorithm (grouping by position, offsetting by speed and index), parameter effects, and return value. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (~250 words) and well-structured: purpose, parameter details, algorithm, return value, and examples. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters with no schema descriptions and an output schema, the description covers algorithm, all parameters, return type, and provides three practical examples. Fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds comprehensive parameter explanations: direction values with musical context, speed with note equivalents and range, jitter with range and purpose, and indexing parameters with meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool converts block chords into strum patterns, using a specific verb ('strum') and resource ('notes'). It distinguishes from siblings like arpeggiation or rhythm application by focusing on guitar-style strumming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (static chord pads needing lifelike strumming) but doesn't explicitly exclude alternatives or mention when not to use. Context is clear but lacks direct sibling comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_subdivide_notesA

Subdivide each note in a region into N smaller notes.

Splits every note into subdivisions equal parts. Useful for diminution (quarter → 2 eighths), rhythmic fragmentation, and creating faster passagework from longer notes.

Args: unit_index: Audio unit index track_index: Note track index region_index: Region index (-1 = first region) subdivisions: Number of parts per note (2-16). 2=diminution, 4=sixteenth fragmentation, 3=triplet subdivision. pitch_pattern: Pitch variation per subdivision — "same" = keep original pitch, "scale_up" = ascend scale degrees within the octave, "scale_down" = descend scale degrees, "octave_up" = alternate original and octave up, "octave_down" = alternate original and octave down, "chromatic_up" = semitone steps up, "chromatic_down" = semitone steps down. velocity_pattern: Velocity variation per subdivision — "same" = keep original velocity, "decrescendo" = fade from full to half, "crescendo" = build from half to full, "accent_first" = first sub-note accented, rest softer, "accent_last" = last sub-note accented, "alternating" = strong-weak-strong-weak pattern. accent_first: If True, first subdivision note keeps full velocity (traditional articulation). Overridden by velocity_pattern. dest_track_index: Destination track (-1 = same track). Original notes are replaced in place when same track.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
track_indexYes
accent_firstNo
region_indexNo
subdivisionsNo
pitch_patternNosame
dest_track_indexNo
velocity_patternNosame

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that original notes are replaced in place when dest_track_index=-1, and that accent_first is overridden by velocity_pattern. However, it does not state whether the operation is destructive or reversible, nor any performance or constraint implications (e.g., note overlap, time boundaries).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise intro, a use-case sentence, then a clear Args list. It is slightly verbose in the Args (e.g., repeating 'original'), but all sentences add value. Could be tightened without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 params, 2 required, output schema exists) and many siblings, the description covers inputs, behavior, and use cases well. It does not describe the output (though output schema exists), but that is acceptable. It lacks mention of time signature or tempo constraints which might affect subdivision.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's Args section provides detailed explanations for all 8 parameters, including example values and effects (e.g., subdivisions: '2=diminution, 4=sixteenth fragmentation, 3=triplet subdivision'). This adds significant meaning beyond the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Subdivide each note in a region into N smaller notes.' The verb 'subdivide' and resource 'note region' are specific. It distinguishes itself from sibling tools like 'augment_notes' or 'apply_velocity_pattern' by focusing on rhythmic fragmentation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Useful for diminution, rhythmic fragmentation, and creating faster passagework from longer notes,' giving clear context. However, it does not provide when-not-to-use guidance or compare with alternatives like 'consolidate_note' or 'repeat_notes', which could help the agent choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_swap_sectionsA

Swap two sections of the arrangement — exchange their positions on the timeline.

Exchanges all note/audio content between two time ranges, moving section A to where section B was and vice versa. Useful for song structure experimentation: try chorus before verse, swap bridge with solo, reorder sections without manual cut/paste.

Both sections can be different lengths — the swap preserves each section's content and shifts everything accordingly. If sections are adjacent, it's a simple swap. If there's a gap between them, the gap content stays in place.

Args: section1_start: Start beat of first section section1_end: End beat of first section section2_start: Start beat of second section (must be > section1_end) section2_end: End beat of second section unit_indices: Comma-separated unit indices to process ("" = all units)

Returns: JSON with sections_swapped, notes_moved per unit, section sizes.

ParametersJSON Schema
NameRequiredDescriptionDefault
section1_endYes
section2_endYes
unit_indicesNo
section1_startYes
section2_startYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully bears the burden of transparency. It explains that content is exchanged, different lengths are handled, and gaps between sections stay in place. This gives a clear behavioral model without requiring annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with paragraphs and an explicit Args section, but it is somewhat lengthy. It could be slightly more concise while retaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (swapping with length differences, gaps, units), the description covers all key behaviors and even mentions return format. An output schema exists, but the description still adds value by explaining sections_swapped, notes_moved, and section sizes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description includes an 'Args' section that explains all five parameters clearly: section1_start/end, section2_start/end, and unit_indices. This adds essential meaning beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool swaps two sections of the arrangement by exchanging their positions. It uses specific verbs ('swap', 'exchange') and resources ('sections', 'arrangement'), and distinguishes from sibling tools like move_section or reorder_sections by focusing on a reciprocal exchange.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'Useful for song structure experimentation' and gives examples like swapping chorus before verse. However, it does not explicitly state when not to use the tool or mention alternative tools like reorder_sections for multi-section reordering.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_switch_phaseA

Switch the active tool phase for phase-based tool loading.

When OPENDAW_MCP_MODE=phase, only tools for the active phase are registered. This reduces the tool schema payload by showing only relevant tools.

Phases:

  • inspect: read-only — project state, list tracks/regions/effects, meters, analysis

  • compose: create — tracks, instruments, notes, regions, sections, arrangements, chords, melodies

  • mix: effects — add/configure effects, sends, buses, mixing, mastering, genre effects, automation

  • render: output — render, export, audio I/O, time/pitch stretch, presets

Meta-tools (evaluate_raw, get_full_project_state, switch_phase) are always available.

phase: inspect | compose | mix | render

Example: switch_phase("compose") # activate composition tools switch_phase("mix") # switch to mixing tools

ParametersJSON Schema
NameRequiredDescriptionDefault
phaseYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that switching phases changes which tools are registered and mentions that meta-tools are always available. It does not detail side effects or error conditions, but the core behavior is well described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It starts with the main purpose, provides context, lists phases in bullet points, and includes an example. Every sentence is informative and adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter), and the description covers its purpose, usage, and allowed values. It mentions that meta-tools are always available. It does not explicitly describe the output or whether the phase change is immediate, but it is sufficiently complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'phase' as a string with no enum or description. The description compensates fully by listing the allowed values (inspect, compose, mix, render) and describing what each phase makes available. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Switch the active tool phase for phase-based tool loading.' It explains the concept of phases and how they affect tool registration. This distinguishes it clearly from siblings that create or modify content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool (when in phase-based mode to switch phases) and lists the available phases with their purposes. It does not explicitly state when not to use it, but the context is clear. It effectively guides the agent on when to invoke this tool vs. the many content-focused siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_thin_notesA

Thin out notes in a region — reduce note density for cleaner patterns.

After AI generation, transcription, or dense arrangement, MIDI can be cluttered with too many notes. This tool selectively removes notes to clean up the pattern while preserving musical intent.

Three strategies:

  • "interval" — keep every Nth note (sorted by position). interval=2 keeps every 2nd note, interval=3 keeps every 3rd. Creates space.

  • "velocity_threshold" — remove notes below a velocity threshold. Cleans up ghost notes from transcription or AI generation.

  • "random" — probabilistic removal. random_chance=0.3 means 30% of notes are removed at random. Creates organic variation.

preserve_strong_beats: When True, notes on strong beats (beat 1 and 3 in 4/4) are never removed, regardless of strategy. This maintains the rhythmic foundation while thinning fills and embellishments.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). strategy: "interval", "velocity_threshold", or "random". interval: For "interval" strategy — keep every Nth note (2=halve, 3=third). Must be 2-16. velocity_threshold: For "velocity_threshold" strategy — remove notes with velocity below this value (0.0-1.0, default 0.3). random_chance: For "random" strategy — probability of removing each note (0.0-1.0, default 0.3 = 30% removed). preserve_strong_beats: Keep notes on beat 1 and 3 (0 and 1920 PPQN in 4/4).

Returns per-track original count, removed count, remaining count.

Example:

Halve note density — keep every 2nd note

thin_notes(unit_index=0, track_index=0, strategy="interval", interval=2)

Remove ghost notes below velocity 0.25

thin_notes(unit_index=0, track_index=0, strategy="velocity_threshold", velocity_threshold=0.25)

Random 40% thinning for organic variation

thin_notes(unit_index=0, track_index=0, strategy="random", random_chance=0.4)

ParametersJSON Schema
NameRequiredDescriptionDefault
intervalNo
strategyNointerval
unit_indexNo
track_indexNo
region_indexNo
random_chanceNo
velocity_thresholdNo
preserve_strong_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains how notes are removed and that musical intent is preserved, but it does not disclose whether the operation is destructive or non-destructive (e.g., if it modifies the original region or creates a new one). With no annotations provided, the description carries the full burden for behavioral transparency, and this gap prevents a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear introductory sentence, contextual explanation, strategy breakdown, parameter descriptions, and an example. It is appropriately sized for the complexity. Minor redundancy (e.g., repeating parameter explanations) prevents a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, use cases, strategies, parameters, and return values. It lacks explicit edge case handling (e.g., no notes matching criteria) but otherwise provides a complete picture for an agent to invoke the tool correctly. The presence of a return value description compensates for the lack of an output schema in the input.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description provides extensive, detailed explanations for all 8 parameters, including their purpose, valid ranges, and defaults. It also explains the three strategies in depth, significantly adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Thin out notes in a region — reduce note density for cleaner patterns.' It provides specific context (after AI generation, transcription, dense arrangement) and outlines three distinct strategies. No sibling tool overlaps with this precise functionality, making it easily distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool (after AI generation, transcription, dense arrangement) and implies the need for a region with too many notes. It does not explicitly state when not to use it, but the context is clear. Given the specificity of the tool, this is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_time_warp_notesA

Warp note positions and durations by a factor — half-time / double-time / custom stretch.

Scales both the position and duration of every note in a region by warp_factor. Unlike scale_durations (which only changes note length, not position), this moves notes in time — creating true half-time (0.5×) or double-time (2.0×) feel without changing the DAW's BPM.

Half-time (0.5): notes spread out — a 1-bar pattern becomes 2 bars. Classic for trap, lofi, and creating build-ups before a drop. Double-time (2.0): notes compress — a 2-bar pattern becomes 1 bar. Useful for intensifying a section or creating fills.

unit_index: AU index (-1 = all AUs). track_index: Note track index (-1 = all note tracks on the AU). region_index: Region index (-1 = all regions on the track). warp_factor: Time scaling factor. 0.5 = half-time, 2.0 = double-time, 0.25 = quarter-time, 1.5 = 1.5× stretch. Range 0.1-8.0. origin: Anchor point for the warp — "start" (region start), or "zero" (position 0). "start" preserves relative spacing from region start. "zero" warps from absolute zero.

Returns per-track modification counts and new region extent.

ParametersJSON Schema
NameRequiredDescriptionDefault
originNostart
unit_indexNo
track_indexNo
warp_factorNo
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavior: scales both position and duration, moves notes in time without changing BPM, describes warp_factor range and meaning, explains the origin anchor point, and mentions return value (modification counts, region extent). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise introductory sentence followed by bullet-style explanations of parameters and behavior. It is front-loaded with key information and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (warp factor, origin, multiple indexes), the description covers all essential behavioral and input aspects. Output schema exists, and the description also mentions return values. No gaps or unanswered questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains all five parameters (unit_index, track_index, region_index, warp_factor, origin) with defaults, ranges, and behavioral meaning. For example, it clarifies that -1 means 'all' and describes the effect of each origin value. This fully compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool warps note positions and durations by a factor, with specific examples (half-time, double-time). It distinguishes from the sibling tool scale_durations by noting that this tool moves notes in time rather than just changing length.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage scenarios (half-time, double-time, custom stretch) and contrasts with scale_durations. It also mentions genre use cases (trap, lofi). However, it doesn't explicitly state when not to use this tool or list alternative tools beyond scale_durations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transcribe_audioA

Transcribe a full audio track — drums + melody — into MIDI notes in one call.

Composite tool that runs transcribe_drums + transcribe_melody on the same WAV file, placing drum notes on one track and melody notes on another. Eliminates 2 separate calls. Essential for Suno-to-MIDI pipeline: download_audio → transcribe_audio → full MIDI reconstruction on 2 tracks.

Pipeline:

  1. Parse WAV file

  2. Auto-detect BPM (if bpm=0)

  3. Transcribe drums → kick/snare/hat on drum_track (pitch 36/38/42)

  4. Transcribe melody → pitched notes on melody_track (with cents + clarity)

  5. Create MIDI notes via create_notes_batch on both tracks

Use cases:

  • Extract full groove from a Suno track → remix in DAW

  • Convert a loop to MIDI → quantize, replace instruments, rearrange

  • Capture a performance → edit and enhance

filename: WAV file name (in exports dir) or absolute path. bpm: Tempo for beat conversion (0 = auto-detect). unit_index: AU index with note tracks. drum_track: Track for drum notes (default 0). melody_track: Track for melody notes (default 1).

Returns: drum notes, melody notes, bpm, duration, band counts, avg clarity.

Example:

Full transcription of a Suno track

result = transcribe_audio("suno_track.wav", bpm=120)

Auto-detect BPM

result = transcribe_audio("loop.wav") # bpm=0 → auto-detect

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
filenameYes
drum_trackNo
unit_indexNo
melody_trackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details internal steps (auto-detect BPM, transcribe drums to specific pitches, transcribe melody with cents+clarity, create MIDI notes via create_notes_batch) and mentions returns. It lacks side-effect information but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence summary, then composite explanation, pipeline steps, use cases, parameter list, and example. It is concise (no filler) and front-loaded with the most important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (audio to MIDI with multiple tracks, BPM detection), the description covers key aspects: purpose, pipeline, use cases, parameters, and returns. It could mention file format constraints or performance notes, but it's largely complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates by describing each parameter: filename (with path hint), bpm (default 0 meaning auto-detect), unit_index, drum_track, melody_track. It adds meaning beyond the bare schema, though could be more precise about filename format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it transcribes a full audio track into MIDI notes, specifying drums and melody. It distinguishes itself by being a composite of transcribe_drums and transcribe_melody, which are listed as sibling tools, and explicitly says it eliminates two separate calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides pipeline steps and use cases (e.g., Suno-to-MIDI pipeline, extract groove, convert loop), making it clear when to use. It implicitly contrasts with separate transcribe calls but doesn't explicitly say when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transcribe_drumsA

Transcribe drum onsets from an audio file into MIDI notes on a DAW track.

Audio-to-MIDI drum transcription — converts a drum recording (or any audio with percussive content) into MIDI notes. Pure Python, no external deps.

Pipeline:

  1. Parse WAV file

  2. Split into 3 frequency bands (kick <250Hz, snare 250-2500Hz, hat >2500Hz)

  3. Per-band onset detection (energy spike above local average)

  4. Classify each onset: kick (pitch 36), snare (38), hat (42)

  5. Estimate velocity from onset amplitude

  6. Convert onset times to beat positions (if bpm provided)

  7. Create MIDI notes on the specified track via create_notes_batch

Use cases:

  • Extract a drum groove from a Suno track → reuse as MIDI pattern

  • Transcribe a real drum recording → edit/quantize in DAW

  • Replace original drums with a different instrument

filename: WAV file name (in exports dir) or absolute path. bpm: Tempo for beat conversion (0 = auto-detect via detect_bpm first). sensitivity: Onset detection threshold (1.0=more sensitive, 2.0=less, default 1.5). unit_index: AU index with note tracks. track_index: Track to place transcribed notes.

Returns: notes created, onset count, band counts (kick/snare/hat), bpm, duration.

Example:

Transcribe a drum loop from a downloaded Suno track

result = transcribe_drums("suno_track.wav", bpm=120)

Auto-detect BPM first

result = transcribe_drums("drum_loop.wav") # bpm=0 → auto-detect

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
filenameYes
unit_indexNo
sensitivityNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It details the internal pipeline (frequency bands, onset detection, classification into kick/snare/hat, velocity estimation, beat conversion, note creation). It discloses that notes are created on the specified track via create_notes_batch. However, it doesn't mention potential failure modes or format limitations (e.g., only WAV).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: concise first sentence, numbered pipeline, use cases, parameter list, return values, and examples. No redundant information; every sentence adds value. Front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multi-step pipeline, 5 parameters, return structure), the description is remarkably complete. It explains the process, parameter semantics, return values, and provides a realistic example. Output schema exists, but the description still lists return fields for clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains all five parameters: filename (WAV file or path), bpm (tempo, 0=auto-detect), sensitivity (threshold 1.0-2.0), unit_index (AU with note tracks), track_index (target track). It also includes default values and an example, fully compensating for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Transcribe drum onsets from an audio file into MIDI notes on a DAW track.' It specifies it's for drum/percussive content, contrasting with sibling transcription tools like transcribe_melody. The verb 'transcribe' and resource 'drums' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete use cases (extract drum groove, transcribe recording, replace drums) and examples. It implies when to use (percussive audio) but doesn't explicitly state when not to use or compare directly to alternatives like transcribe_melody.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transcribe_melodyA

Transcribe monophonic melody from an audio file into MIDI notes on a DAW track.

Audio-to-MIDI melody transcription — converts a monophonic instrument recording (bass, vocal, lead synth, horn) into MIDI notes. Pure Python, no external deps.

Pipeline:

  1. Parse WAV file

  2. Frame-by-frame autocorrelation pitch detection

  3. Convert frequency → MIDI pitch (with cents deviation for tuning accuracy)

  4. Group consecutive similar-pitch frames into sustained notes

  5. Estimate velocity from frame energy

  6. Create MIDI notes on the specified track via create_notes_batch

Use cases:

  • Extract a bass line from a Suno track → reuse as MIDI

  • Transcribe a vocal melody → harmonize or transform

  • Capture a horn line → arrange for other instruments

  • Convert any monophonic audio to editable MIDI

filename: WAV file name (in exports dir) or absolute path. bpm: Tempo for beat conversion (0 = auto-detect via detect_bpm). unit_index: AU index with note tracks. track_index: Track to place transcribed notes.

Returns: notes created, note count, bpm, duration, average clarity.

Example:

Transcribe a bass line from a Suno track

result = transcribe_melody("suno_bass.wav", bpm=120)

Auto-detect BPM

result = transcribe_melody("vocal.wav") # bpm=0 → auto-detect

ParametersJSON Schema
NameRequiredDescriptionDefault
bpmNo
filenameYes
unit_indexNo
track_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It explains the pipeline (WAV parsing, pitch detection, note creation) and lists return values (notes created, note count, bpm, duration, clarity). No side effects are mentioned but none expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with front-loaded purpose, pipeline, use cases, parameter list, and examples. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and presence of an output schema, the description covers input format, monophonic requirement, parameter details, use cases, and examples. It lacks information on error handling or file size limits but is otherwise comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides detailed parameter explanations for filename, bpm (with auto-detect), unit_index, and track_index, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'transcribe' and the resource 'monophonic melody from an audio file into MIDI notes on a DAW track'. It distinguishes itself from siblings like transcribe_audio and transcribe_drums by specifying monophonic melody.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases and examples for when to use the tool, but does not explicitly state when not to use it or mention alternatives. The monophonic limitation implies exclusion of polyphonic content.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transfer_audiounitA

Transfer/copy an audio unit (instrument/effects/tracks/regions) within the project.

Uses TransferAudioUnits.transfer — deep-copy an AU with all dependencies (instrument, effects, MIDI effects, tracks, regions, notes, automation) via box-graph serialization. Much more complete than duplicate_audiounit (which uses Python orchestration). Output unit cannot be copied.

unit_index: Source AU index to copy. delete_source: If true, delete source AU after copy (move semantics). insert_index: Position in mixer order for the new AU (-1 = auto-place by type ordering).

Returns the new AU's index, type, and label, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes
insert_indexNo
delete_sourceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully explains the deep-copy behavior with all dependencies, describes parameters for move semantics and insert position, and mentions the return values. Lacks explicit details on whether source is modified when delete_source is false, but otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, front-loaded with the main purpose, then technical details, followed by parameter explanations. No wasted words; all information earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (deep-copy with dependencies, move semantics), the description covers what it does, how it works, parameter details, constraints, and return values. Has output schema so not required to explain returns, but it still lists them. Complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain each parameter. It does so thoroughly: unit_index as source, delete_source for move semantics, and insert_index for mixer order with auto-place behavior. Adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it transfers/copies an audio unit, specifies it deep-copies with all dependencies, and distinguishes itself from duplicate_audiounit by noting higher completeness and the limitation that output unit cannot be copied.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly compares with duplicate_audiounit, stating this tool is more complete and uses box-graph serialization, guiding when to prefer this tool. Also notes the output unit cannot be copied, setting clear constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transfer_regionA

Transfer/copy a region to another track at a specific position.

Uses TransferRegions.transfer — copies the region and all its dependencies (notes, events, audio files) to the target track. Works across different audio units. Preserved resources (AudioFileBox) are shared, not duplicated. The source region can optionally be deleted (move semantics).

src_unit_index: Source AU index. src_track_index: Source track index within AU. region_index: Region index within source track (0-based, sorted by position). dst_unit_index: Destination AU index. dst_track_index: Destination track index within AU. insert_position: Position in beats for the new region. delete_source: If true, delete the source region (move). If false, keep source (copy).

Returns the new region's type, position, and duration, or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
region_indexYes
delete_sourceNo
dst_unit_indexYes
src_unit_indexYes
dst_track_indexYes
insert_positionYes
src_track_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behaviors: copies all dependencies, works across audio units, shared resources are not duplicated, optional deletion (move semantics), and expected return value. This provides good transparency beyond basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a short paragraph describing the action, followed by a bullet-like list of parameter explanations. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (cross-AU transfer, sharing resources, optional deletion), the description covers the essential aspects. It mentions the return value but could further elaborate on error conditions or prerequisites (e.g., destination track must exist). Still, it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides clear, concise explanations for all 7 parameters, including details like region_index being 0-based and sorted by position, insert_position in beats, and delete_source controlling move vs copy. This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool transfers/copies a region to another track at a specific position, using a specific verb and resource. It mentions copying dependencies and optional deletion, but does not explicitly differentiate from sibling tools like mcp_opendaw_copy_region_to_track or mcp_opendaw_move_region_to_track.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (to transfer/copy a region across audio units) but does not provide explicit guidance on when not to use it or what alternatives exist. The usage context is implied rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transportB

Control transport: play, stop, or toggle.

action: "play", "stop", or "toggle"

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says 'Control transport' and lists actions, but omits details like what 'toggle' does (e.g., toggle between play and stop), whether position is reset, or any side effects. This is insufficient for a transport control tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences, front-loaded with the purpose, and lists the parameter values efficiently. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema (not provided but indicated), the description is mostly complete for basic usage. However, it could mention that the action is immediate or provide feedback expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage (no enum, no description). The description adds the allowed values: 'play', 'stop', 'toggle', which partially compensates. However, it does not clarify case sensitivity or exact format. With only one parameter, more explicit guidance would be better.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Control transport: play, stop, or toggle.' It lists the three specific actions, making the function explicit. It does not explicitly distinguish from siblings but the action set is unique enough among the many tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like start_engine or other transport-related tools. It only lists the action parameter values without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_transpose_notesA

Transpose all notes by a number of semitones.

semitones: Positive = up, negative = down (e.g. +12 = octave up, -5 = perfect fourth down). unit_index: Audio unit index (-1 = all AUs with note tracks). track_index: Specific note track (-1 = all note tracks on the AU). region_index: Specific region index (-1 = all regions on the track).

Returns count of notes transposed and notes skipped (out of MIDI range 0-127).

ParametersJSON Schema
NameRequiredDescriptionDefault
semitonesYes
unit_indexYes
track_indexYes
region_indexNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description partially covers behavior: returns count of transposed/skipped notes, scopes via -1 values. However, it omits side effects, authorization, or performance implications. For a mutation tool, more detail would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two short paragraphs. The first states action, the second lists parameters with one line each. No redundancy, highly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with no annotations and no output schema described, the description covers action, parameters, and return value. It lacks usage guidelines and deeper behavioral context, but is still fairly complete for the given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description explains all 4 parameters with clear semantics: semitones direction/example, unit_index/track_index/region_index meaning of -1. This adds significant value beyond the schema's bare type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Transpose all notes by a number of semitones,' specifying the verb (transpose) and resource (notes). The sibling tool 'diatonic_transpose_notes' implies this is a chromatic transposition, distinguishing it from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings or other transpose tools. It does not mention alternative approaches, when not to use, or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_undoB

Undo the last editing operation.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavioral context. It only states 'Undo the last editing operation' without disclosing scope (single vs. multiple undos), redo availability, or side effects. This is insufficient for an agent to understand the full behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It perfectly matches the tool's simple nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description is still minimal. It fails to mention whether multiple undos are supported, how undo history is managed, or any return value context. This lack of detail hurts completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage. The description adds no additional parameter meaning, but since there are none, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool undoes the last editing operation. The verb 'undo' combined with 'last editing operation' is specific and distinguishes from sibling 'mcp_opendaw_redo'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'redo' or other editing tools. The usage context is only implied (after an editing operation), but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_unfreeze_audiounitC

Unfreeze a frozen audio unit — resume real-time processing.

Removes the cached audio and resumes live processing of instruments, effects, and sends for the specified audio unit.

unit_index: AU index to unfreeze.

Returns success or error.

ParametersJSON Schema
NameRequiredDescriptionDefault
unit_indexYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses removal of cached audio and resumption of live processing, but lacks details on side effects, reversibility, permissions, or impact on other units.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, with the main action in the first sentence and elaboration in subsequent sentences. Every line adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a mutation with potential side effects, the description lacks completeness. It does not mention prerequisites (must be frozen), error handling, or behavior if already unfrozen. Output schema exists, but description minimally covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains 'unit_index' as 'AU index to unfreeze', adding minimal context beyond the schema title. No guidance on how to obtain the index or valid ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Unfreeze' and resource 'audio unit', clearly stating the action of resuming real-time processing. It is distinct from its sibling 'freeze_audiounit', providing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. It implies it is the reverse of freeze_audiounit, but does not specify prerequisites (e.g., the unit must be frozen) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_update_automation_eventA

Update an existing automation event's value and/or interpolation.

Only updates parameters that are provided (value >= 0, non-empty interpolation, curve_slope >= 0).

unit_index: AU index. track_index: Value (automation) track index. event_index: Event index (from list_automation_events). value: New normalized value 0.0-1.0 (skip if -1). interpolation: "none", "linear", or "curve" (skip if empty string). curve_slope: Slope for curve interpolation 0.0-1.0 (skip if -1).

Returns success with updated values.

ParametersJSON Schema
NameRequiredDescriptionDefault
valueNo
unit_indexYes
curve_slopeNo
event_indexYes
track_indexYes
interpolationNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It discloses the partial update behavior, valid value ranges (0.0-1.0 for value and curve_slope), interpolation options ('none', 'linear', 'curve'), condition for skipping fields (-1 or empty string), and that it returns success with updated values. It does not mention error handling or side effects, but overall is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: first sentence gives the core purpose, followed by a note on partial updates, then a clear list of parameters. It could be slightly more concise by avoiding repetition of the skip conditions already implied in the parameter notes, but overall it is efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains all 6 parameters with their types and skip conditions, given the context of an update operation. It mentions that the tool returns success with updated values (consistent with an output schema). For a tool of this complexity (optional fields, partial update), the description is complete and leaves no ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning parameter titles provide no meaningful descriptions. The description compensates fully by explaining each parameter: unit_index (AU index), track_index (value track index), event_index (event index), value (0.0-1.0, skip if -1), interpolation (none/linear/curve, skip if empty), curve_slope (0.0-1.0, skip if -1). This adds critical meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and the resource ('existing automation event'), and specifies the modifiable aspects ('value and/or interpolation'). It distinguishes itself from sibling tools like create_automation_event, delete_automation_event, and list_automation_events by focusing on updating existing events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that only provided parameters (value >= 0, non-empty interpolation, curve_slope >= 0) are updated, but it does not give explicit guidance on when to use this tool versus alternatives (e.g., creating a new event or deleting one). The 'Only updates parameters that are provided' note is helpful but lacks comparative context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_update_warp_markerA

Update a warp marker's position and/or seconds value.

Pass -1.0 for either parameter to leave it unchanged.

unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. marker_index: Warp marker index (0-based). position_beats: New musical position in beats (-1 = unchanged). seconds: New audio time in seconds (-1 = unchanged).

Returns updated marker values.

ParametersJSON Schema
NameRequiredDescriptionDefault
secondsNo
unit_indexYes
track_indexYes
marker_indexYes
region_indexYes
position_beatsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states that the tool 'Returns updated marker values' but does not disclose side effects, prerequisites, error handling, or the impact of modification on other markers. It adequately describes the basic behavior but lacks depth for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It begins with the main purpose, provides a critical usage tip, and then lists parameters. Every sentence is informative with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (context signals indicate 'Has output schema: true'), the description does not need to explain the return format. It covers all input parameters and the -1 leave-unchanged pattern. However, it could mention that the marker must exist and what happens if indices are invalid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds significant value by defining each parameter (unit_index, track_index, region_index, marker_index, position_beats, seconds) and explaining the special -1 default for unchanged values. Without this, an agent would have no semantic understanding from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Update a warp marker's position and/or seconds value.' It specifies the verb 'Update', the resource 'warp marker', and the attributes (position and seconds). It distinguishes from sibling tools like create_warp_marker and delete_warp_marker by implying a modification operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on how to update selectively with 'Pass -1.0 for either parameter to leave it unchanged.' It does not explicitly state when to use this tool versus alternatives, but the purpose is clear enough that an agent can infer it is for modifying existing warp markers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_validate_projectA

Check if the project is valid — detects overlapping regions on the same track.

Returns valid (bool) and details about any issues found.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It indicates the tool checks validity and returns issues, implying a non-destructive read operation, but lacks details on side effects, performance, or required context (e.g., project must be loaded). No contradiction with annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the core purpose, and includes return value details without extraneous words. Every sentence contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description adequately covers the tool's function. It specifies the key check (overlapping regions) and return type. However, it could be slightly more complete by noting that the project must be active or loaded, though this is implied for most DAW tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100%. The description does not add parameter-specific information, but with no parameters, the baseline score is 4, and the description provides no additional value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool validates a project by detecting overlapping regions on the same track, and it specifies return values (valid bool and details). It distinguishes from similar siblings like 'detect_problems' by focusing on a specific check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring a loaded project, nor does it differentiate from potential overlapping validation tools like 'detect_problems'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_opendaw_wait_for_conditionA

Wait for a JavaScript condition to evaluate to true in the DAW context.

Polls the condition at regular intervals until it returns true or timeout is reached.

condition_js: JavaScript expression that returns a truthy value when the condition is met. timeout_ms: Maximum wait time in milliseconds (default 10000). poll_interval_ms: Polling interval in milliseconds (default 500).

ParametersJSON Schema
NameRequiredDescriptionDefault
timeout_msNo
condition_jsYes
poll_interval_msNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions polling behavior and the conditions for completion (true or timeout), which adds context beyond the schema. However, it does not disclose potential side effects, error handling, or limitations such as maximum timeout or blocking behavior. Given no annotations, the description carries the full burden but provides only partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences: purpose, behavior, and parameter details. It is well-structured and front-loaded with the core action, wasting no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the existence of an output schema, the description covers purpose, behavior, and all parameters. It lacks explicit details on timeout behavior (e.g., return value on timeout) but is still fairly complete for a wait utility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining all three parameters: condition_js as a JavaScript expression, timeout_ms with default, and poll_interval_ms with default. This adds significant meaning beyond what the schema provides, though it could include more constraints like allowed characters or types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool waits for a JavaScript condition to evaluate to true in the DAW context. It is specific and distinct from sibling tools, which are primarily creation, analysis, or manipulation tools, with no other wait tools present.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives or when not to use it. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for appropriate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 515 tool updatesv1.385.0
    • First observedmcp_opendaw_accent_beats
    • First observedmcp_opendaw_add_anticipation
    • First observedmcp_opendaw_add_automation
    • First observedmcp_opendaw_add_bass_chain
    • First observedmcp_opendaw_add_chord_tension
    • First observedmcp_opendaw_add_drum_chain
    • First observedmcp_opendaw_add_effect
    • First observedmcp_opendaw_add_instrument_automation
    • First observedmcp_opendaw_add_instrument_chain
    • First observedmcp_opendaw_add_marker
    • First observedmcp_opendaw_add_mastering_chain
    • First observedmcp_opendaw_add_midi_effect
    • First observedmcp_opendaw_add_modular_module
    • First observedmcp_opendaw_add_neighbor_tones
    • First observedmcp_opendaw_add_passing_tones
    • First observedmcp_opendaw_add_signature_change
    • First observedmcp_opendaw_add_suspension
    • First observedmcp_opendaw_add_tempo_change
    • First observedmcp_opendaw_add_vocal_chain
    • First observedmcp_opendaw_analyze_dynamics
    • First observedmcp_opendaw_analyze_harmonic_rhythm
    • First observedmcp_opendaw_analyze_melody
    • First observedmcp_opendaw_analyze_mix
    • First observedmcp_opendaw_analyze_phase
    • First observedmcp_opendaw_analyze_song_structure
    • First observedmcp_opendaw_analyze_spectrum
    • First observedmcp_opendaw_analyze_stereo
    • First observedmcp_opendaw_analyze_track
    • First observedmcp_opendaw_apply_articulation
    • First observedmcp_opendaw_apply_contour
    • First observedmcp_opendaw_apply_full_mix
    • First observedmcp_opendaw_apply_genre_humanization
    • First observedmcp_opendaw_apply_genre_mix
    • First observedmcp_opendaw_apply_mix_preset
    • First observedmcp_opendaw_apply_rhythm_pattern
    • First observedmcp_opendaw_apply_sidechain
    • First observedmcp_opendaw_apply_swing
    • First observedmcp_opendaw_apply_velocity_curve
    • First observedmcp_opendaw_apply_velocity_lfo
    • First observedmcp_opendaw_apply_velocity_pattern
    • First observedmcp_opendaw_augment_notes
    • First observedmcp_opendaw_auto_gain
    • First observedmcp_opendaw_automation_sweep
    • First observedmcp_opendaw_balance_track_velocities
    • First observedmcp_opendaw_batch_diagnostic
    • First observedmcp_opendaw_capture_realtime
    • First observedmcp_opendaw_change_base_signature
    • First observedmcp_opendaw_classify_drum_pattern
    • First observedmcp_opendaw_clear_region_notes
    • First observedmcp_opendaw_clone_clip
    • First observedmcp_opendaw_clone_effect_chain
    • First observedmcp_opendaw_clone_track
    • First observedmcp_opendaw_compact_tracks
    • First observedmcp_opendaw_compare_to_profile
    • First observedmcp_opendaw_compare_to_reference
    • First observedmcp_opendaw_connect_modular_modules
    • First observedmcp_opendaw_connect_sidechain
    • First observedmcp_opendaw_consolidate_clip
    • First observedmcp_opendaw_consolidate_note
    • First observedmcp_opendaw_consolidate_region
    • First observedmcp_opendaw_constrain_note_range
    • First observedmcp_opendaw_convert_audio
    • First observedmcp_opendaw_copy_notes_to_track
    • First observedmcp_opendaw_copy_playfield_sample
    • First observedmcp_opendaw_copy_region_fades
    • First observedmcp_opendaw_copy_region_to_track
    • First observedmcp_opendaw_create_acid_arrangement
    • First observedmcp_opendaw_create_additive_rhythm
    • First observedmcp_opendaw_create_afrobeat_arrangement
    • First observedmcp_opendaw_create_ambient_arrangement
    • First observedmcp_opendaw_create_appoggiatura
    • First observedmcp_opendaw_create_arabic_percussion
    • First observedmcp_opendaw_create_arpeggiated_progression
    • First observedmcp_opendaw_create_arpeggio
    • First observedmcp_opendaw_create_arrangement_variation
    • First observedmcp_opendaw_create_audio_bus
    • First observedmcp_opendaw_create_audio_clip
    • First observedmcp_opendaw_create_audio_track
    • First observedmcp_opendaw_create_automation_event
    • First observedmcp_opendaw_create_balkan_meter
    • First observedmcp_opendaw_create_bariolage
    • First observedmcp_opendaw_create_bass_drop
    • First observedmcp_opendaw_create_bass_from_progression
    • First observedmcp_opendaw_create_bassline
    • First observedmcp_opendaw_create_binary_form
    • First observedmcp_opendaw_create_blues_arrangement
    • First observedmcp_opendaw_create_boom_bap
    • First observedmcp_opendaw_create_bordun
    • First observedmcp_opendaw_create_break
    • First observedmcp_opendaw_create_breakbeat
    • First observedmcp_opendaw_create_buildup
    • First observedmcp_opendaw_create_cadenza
    • First observedmcp_opendaw_create_call_and_response
    • First observedmcp_opendaw_create_call_response
    • First observedmcp_opendaw_create_canon
    • First observedmcp_opendaw_create_cascara
    • First observedmcp_opendaw_create_chaconne
    • First observedmcp_opendaw_create_chop
    • First observedmcp_opendaw_create_chorale
    • First observedmcp_opendaw_create_chord_pads
    • First observedmcp_opendaw_create_chord_progression
    • First observedmcp_opendaw_create_clave
    • First observedmcp_opendaw_create_colotomic
    • First observedmcp_opendaw_create_comparsa
    • First observedmcp_opendaw_create_comping
    • First observedmcp_opendaw_create_counter_melody_from_progression
    • First observedmcp_opendaw_create_counterpoint
    • First observedmcp_opendaw_create_country_arrangement
    • First observedmcp_opendaw_create_crescendo
    • First observedmcp_opendaw_create_cross_rhythm
    • First observedmcp_opendaw_create_dembow
    • First observedmcp_opendaw_create_disco_arrangement
    • First observedmcp_opendaw_create_djembe_ensemble
    • First observedmcp_opendaw_create_dnb_arrangement
    • First observedmcp_opendaw_create_downtempo_arrangement
    • First observedmcp_opendaw_create_drum_fill
    • First observedmcp_opendaw_create_drum_pattern
    • First observedmcp_opendaw_create_drum_solo
    • First observedmcp_opendaw_create_dubstep_arrangement
    • First observedmcp_opendaw_create_edm_arrangement
    • First observedmcp_opendaw_create_electronic_bass
    • First observedmcp_opendaw_create_euclidean_rhythm
    • First observedmcp_opendaw_create_filter_sweep
    • First observedmcp_opendaw_create_flamenco_compas
    • First observedmcp_opendaw_create_four_on_floor
    • First observedmcp_opendaw_create_fugato
    • First observedmcp_opendaw_create_fugue
    • First observedmcp_opendaw_create_full_genre_pipeline
    • First observedmcp_opendaw_create_funk_arrangement
    • First observedmcp_opendaw_create_future_bass_arrangement
    • First observedmcp_opendaw_create_garage_arrangement
    • First observedmcp_opendaw_create_genre_sections
    • First observedmcp_opendaw_create_genre_track
    • First observedmcp_opendaw_create_ghost_notes
    • First observedmcp_opendaw_create_glissando
    • First observedmcp_opendaw_create_gospel_arrangement
    • First observedmcp_opendaw_create_ground_bass
    • First observedmcp_opendaw_create_hardstyle_arrangement
    • First observedmcp_opendaw_create_harmonic_arrangement
    • First observedmcp_opendaw_create_harmony
    • First observedmcp_opendaw_create_harmony_line
    • First observedmcp_opendaw_create_hemiola
    • First observedmcp_opendaw_create_hocket
    • First observedmcp_opendaw_create_house_arrangement
    • First observedmcp_opendaw_create_impact
    • First observedmcp_opendaw_create_instrument_track
    • First observedmcp_opendaw_create_irish_trad
    • First observedmcp_opendaw_create_isorhythm
    • First observedmcp_opendaw_create_jazz_arrangement
    • First observedmcp_opendaw_create_konokol
    • First observedmcp_opendaw_create_korean_percussion
    • First observedmcp_opendaw_create_l_system_melody
    • First observedmcp_opendaw_create_liquid_dnb_arrangement
    • First observedmcp_opendaw_create_lofi_arrangement
    • First observedmcp_opendaw_create_markov_melody
    • First observedmcp_opendaw_create_melodic_polyrhythm
    • First observedmcp_opendaw_create_melody
    • First observedmcp_opendaw_create_melody_from_progression
    • First observedmcp_opendaw_create_metal_arrangement
    • First observedmcp_opendaw_create_metric_modulation
    • First observedmcp_opendaw_create_midi_echo
    • First observedmcp_opendaw_create_modulated_song
    • First observedmcp_opendaw_create_montuno
    • First observedmcp_opendaw_create_mordent
    • First observedmcp_opendaw_create_motif_development
    • First observedmcp_opendaw_create_motif_variations
    • First observedmcp_opendaw_create_mute_automation
    • First observedmcp_opendaw_create_neurofunk_arrangement
    • First observedmcp_opendaw_create_note
    • First observedmcp_opendaw_create_note_clip
    • First observedmcp_opendaw_create_note_track
    • First observedmcp_opendaw_create_notes_batch
    • First observedmcp_opendaw_create_ostinato
    • First observedmcp_opendaw_create_pan_sweep
    • First observedmcp_opendaw_create_passacaglia
    • First observedmcp_opendaw_create_pedal_point
    • First observedmcp_opendaw_create_phase_shift
    • First observedmcp_opendaw_create_phonk_arrangement
    • First observedmcp_opendaw_create_pitch_stretched_clip
    • First observedmcp_opendaw_create_pitch_stretched_region
    • First observedmcp_opendaw_create_playfield_sample
    • First observedmcp_opendaw_create_polyrhythm
    • First observedmcp_opendaw_create_pop_arrangement
    • First observedmcp_opendaw_create_progression_from_key
    • First observedmcp_opendaw_create_psytrance_arrangement
    • First observedmcp_opendaw_create_random_walk_melody
    • First observedmcp_opendaw_create_ratchet
    • First observedmcp_opendaw_create_reggae_arrangement
    • First observedmcp_opendaw_create_reggae_percussion
    • First observedmcp_opendaw_create_riff
    • First observedmcp_opendaw_create_riser
    • First observedmcp_opendaw_create_rnb_arrangement
    • First observedmcp_opendaw_create_rock_arrangement
    • First observedmcp_opendaw_create_rondo
    • First observedmcp_opendaw_create_samba_pattern
    • First observedmcp_opendaw_create_scale_run
    • First observedmcp_opendaw_create_second_line
    • First observedmcp_opendaw_create_section_transition
    • First observedmcp_opendaw_create_send
    • First observedmcp_opendaw_create_sequence
    • First observedmcp_opendaw_create_soli
    • First observedmcp_opendaw_create_solo
    • First observedmcp_opendaw_create_solo_automation
    • First observedmcp_opendaw_create_sonata_form
    • First observedmcp_opendaw_create_song_structure
    • First observedmcp_opendaw_create_song_with_variations
    • First observedmcp_opendaw_create_songo_pattern
    • First observedmcp_opendaw_create_soul_arrangement
    • First observedmcp_opendaw_create_stab
    • First observedmcp_opendaw_create_stutter
    • First observedmcp_opendaw_create_synth_track
    • First observedmcp_opendaw_create_synthwave_arrangement
    • First observedmcp_opendaw_create_taiko_ensemble
    • First observedmcp_opendaw_create_tala
    • First observedmcp_opendaw_create_techno_arrangement
    • First observedmcp_opendaw_create_tempo_ramp
    • First observedmcp_opendaw_create_ternary_form
    • First observedmcp_opendaw_create_time_stretched_clip
    • First observedmcp_opendaw_create_time_stretched_region
    • First observedmcp_opendaw_create_track_region
    • First observedmcp_opendaw_create_trance_arrangement
    • First observedmcp_opendaw_create_trap_arrangement
    • First observedmcp_opendaw_create_trap_rolls
    • First observedmcp_opendaw_create_trill
    • First observedmcp_opendaw_create_tumbao
    • First observedmcp_opendaw_create_tuplet_group
    • First observedmcp_opendaw_create_turn
    • First observedmcp_opendaw_create_two_hand_piano
    • First observedmcp_opendaw_create_value_clip
    • First observedmcp_opendaw_create_variations
    • First observedmcp_opendaw_create_voice_exchange
    • First observedmcp_opendaw_create_voice_led_progression
    • First observedmcp_opendaw_create_volume_fade
    • First observedmcp_opendaw_create_walking_bass
    • First observedmcp_opendaw_create_warp_marker
    • First observedmcp_opendaw_delete_audio_region
    • First observedmcp_opendaw_delete_audio_unit
    • First observedmcp_opendaw_delete_automation_event
    • First observedmcp_opendaw_delete_clip
    • First observedmcp_opendaw_delete_marker
    • First observedmcp_opendaw_delete_note
    • First observedmcp_opendaw_delete_note_region
    • First observedmcp_opendaw_delete_region
    • First observedmcp_opendaw_delete_section
    • First observedmcp_opendaw_delete_signature_change
    • First observedmcp_opendaw_delete_track
    • First observedmcp_opendaw_delete_warp_marker
    • First observedmcp_opendaw_detect_bpm
    • First observedmcp_opendaw_detect_frequency_masking
    • First observedmcp_opendaw_detect_key
    • First observedmcp_opendaw_detect_problems
    • First observedmcp_opendaw_detect_scale_from_notes
    • First observedmcp_opendaw_diatonic_transpose_notes
    • First observedmcp_opendaw_displace_rhythm
    • First observedmcp_opendaw_double_melody
    • First observedmcp_opendaw_download_audio
    • First observedmcp_opendaw_duplicate_audiounit
    • First observedmcp_opendaw_duplicate_automation_event
    • First observedmcp_opendaw_duplicate_effect
    • First observedmcp_opendaw_duplicate_note_event
    • First observedmcp_opendaw_duplicate_note_region
    • First observedmcp_opendaw_duplicate_notes
    • First observedmcp_opendaw_duplicate_region
    • First observedmcp_opendaw_duplicate_section
    • First observedmcp_opendaw_engine_panic
    • First observedmcp_opendaw_engine_sleep
    • First observedmcp_opendaw_engine_wake
    • First observedmcp_opendaw_evaluate_raw
    • First observedmcp_opendaw_expand_intervals
    • First observedmcp_opendaw_explode_chords
    • First observedmcp_opendaw_export_dawproject
    • First observedmcp_opendaw_export_dry_stem
    • First observedmcp_opendaw_export_effect_chain
    • First observedmcp_opendaw_export_midi
    • First observedmcp_opendaw_export_mix
    • First observedmcp_opendaw_export_preset
    • First observedmcp_opendaw_export_single_stem
    • First observedmcp_opendaw_export_stems
    • First observedmcp_opendaw_export_stems_format
    • First observedmcp_opendaw_extract_motifs
    • First observedmcp_opendaw_extract_rhythm
    • First observedmcp_opendaw_filter_notes
    • First observedmcp_opendaw_find_overlapping_notes
    • First observedmcp_opendaw_flatten_note_regions
    • First observedmcp_opendaw_force_scale_notes
    • First observedmcp_opendaw_freeze_audiounit
    • First observedmcp_opendaw_generate_melody
    • First observedmcp_opendaw_get_audio_file_info
    • First observedmcp_opendaw_get_automation_value
    • First observedmcp_opendaw_get_bar_interval
    • First observedmcp_opendaw_get_device_chain_detail
    • First observedmcp_opendaw_get_effect_chain
    • First observedmcp_opendaw_get_effect_state
    • First observedmcp_opendaw_get_engine_status
    • First observedmcp_opendaw_get_full_project_state
    • First observedmcp_opendaw_get_midi_effect_chain
    • First observedmcp_opendaw_get_mixer_state
    • First observedmcp_opendaw_get_neuralamp_model
    • First observedmcp_opendaw_get_note_range
    • First observedmcp_opendaw_get_piano_mode
    • First observedmcp_opendaw_get_project_duration
    • First observedmcp_opendaw_get_project_info
    • First observedmcp_opendaw_get_project_metadata
    • First observedmcp_opendaw_get_project_state
    • First observedmcp_opendaw_get_region_info
    • First observedmcp_opendaw_get_region_play_mode
    • First observedmcp_opendaw_get_sample_info
    • First observedmcp_opendaw_get_script_device_code
    • First observedmcp_opendaw_get_signature_events
    • First observedmcp_opendaw_get_studio_settings
    • First observedmcp_opendaw_get_tempo_at
    • First observedmcp_opendaw_get_track_info
    • First observedmcp_opendaw_get_unit_freeze_status
    • First observedmcp_opendaw_groove_transfer
    • First observedmcp_opendaw_humanize_notes
    • First observedmcp_opendaw_humanize_pitch
    • First observedmcp_opendaw_identify_chords
    • First observedmcp_opendaw_import_audio_to_tracks
    • First observedmcp_opendaw_import_dawproject
    • First observedmcp_opendaw_import_midi
    • First observedmcp_opendaw_import_preset
    • First observedmcp_opendaw_insert_rests
    • First observedmcp_opendaw_invert_chord_notes
    • First observedmcp_opendaw_invert_notes
    • First observedmcp_opendaw_list_audio_buses
    • First observedmcp_opendaw_list_audio_regions
    • First observedmcp_opendaw_list_automatable_fields
    • First observedmcp_opendaw_list_automation_events
    • First observedmcp_opendaw_list_automation_events_detail
    • First observedmcp_opendaw_list_clips
    • First observedmcp_opendaw_list_effect_parameters
    • First observedmcp_opendaw_list_effects
    • First observedmcp_opendaw_list_genre_profiles
    • First observedmcp_opendaw_list_instrument_params
    • First observedmcp_opendaw_list_markers
    • First observedmcp_opendaw_list_midi_effect_params
    • First observedmcp_opendaw_list_midi_effects
    • First observedmcp_opendaw_list_midi_output_devices
    • First observedmcp_opendaw_list_modular_connections
    • First observedmcp_opendaw_list_modular_devices
    • First observedmcp_opendaw_list_modular_modules
    • First observedmcp_opendaw_list_note_regions
    • First observedmcp_opendaw_list_notes
    • First observedmcp_opendaw_list_playfield_samples
    • First observedmcp_opendaw_list_samples
    • First observedmcp_opendaw_list_script_params
    • First observedmcp_opendaw_list_script_samples
    • First observedmcp_opendaw_list_sends
    • First observedmcp_opendaw_list_signature_changes
    • First observedmcp_opendaw_list_split_modes
    • First observedmcp_opendaw_list_tempo_changes
    • First observedmcp_opendaw_list_tracks
    • First observedmcp_opendaw_list_transient_markers
    • First observedmcp_opendaw_list_value_regions
    • First observedmcp_opendaw_list_vaporisateur_params
    • First observedmcp_opendaw_list_warp_markers
    • First observedmcp_opendaw_load_audio
    • First observedmcp_opendaw_load_effect_preset
    • First observedmcp_opendaw_load_project
    • First observedmcp_opendaw_map_velocity_by_pitch
    • First observedmcp_opendaw_match_to_reference
    • First observedmcp_opendaw_measure_lufs
    • First observedmcp_opendaw_merge_consecutive_notes
    • First observedmcp_opendaw_merge_note_regions
    • First observedmcp_opendaw_merge_note_tracks
    • First observedmcp_opendaw_modulate_progression
    • First observedmcp_opendaw_move_audio_unit
    • First observedmcp_opendaw_move_automation_event
    • First observedmcp_opendaw_move_effect
    • First observedmcp_opendaw_move_notes
    • First observedmcp_opendaw_move_region_content
    • First observedmcp_opendaw_move_region_to_track
    • First observedmcp_opendaw_move_section
    • First observedmcp_opendaw_move_signature_event
    • First observedmcp_opendaw_move_track
    • First observedmcp_opendaw_note_stats
    • First observedmcp_opendaw_place_audio_region
    • First observedmcp_opendaw_ppqn_to_parts
    • First observedmcp_opendaw_ppqn_to_seconds
    • First observedmcp_opendaw_quantize_notes
    • First observedmcp_opendaw_quantize_velocities
    • First observedmcp_opendaw_query_loading_complete
    • First observedmcp_opendaw_randomize_note_chance
    • First observedmcp_opendaw_randomize_note_durations
    • First observedmcp_opendaw_redo
    • First observedmcp_opendaw_reharmonize_progression
    • First observedmcp_opendaw_remix_track
    • First observedmcp_opendaw_remove_audio_bus
    • First observedmcp_opendaw_remove_effect
    • First observedmcp_opendaw_remove_midi_effect
    • First observedmcp_opendaw_remove_modular_module
    • First observedmcp_opendaw_remove_send
    • First observedmcp_opendaw_rename_unit
    • First observedmcp_opendaw_render_and_analyze
    • First observedmcp_opendaw_render_full
    • First observedmcp_opendaw_render_full_format
    • First observedmcp_opendaw_render_full_song
    • First observedmcp_opendaw_render_range
    • First observedmcp_opendaw_reorder_sections
    • First observedmcp_opendaw_repeat_notes
    • First observedmcp_opendaw_repeat_phrase
    • First observedmcp_opendaw_replace_from_preset
    • First observedmcp_opendaw_replace_instrument
    • First observedmcp_opendaw_reset_playfield_params
    • First observedmcp_opendaw_reset_project
    • First observedmcp_opendaw_reverse_notes
    • First observedmcp_opendaw_rotate_notes
    • First observedmcp_opendaw_save_effect_preset
    • First observedmcp_opendaw_save_project
    • First observedmcp_opendaw_scale_durations
    • First observedmcp_opendaw_scale_velocity
    • First observedmcp_opendaw_schedule_clip_play
    • First observedmcp_opendaw_schedule_clip_stop
    • First observedmcp_opendaw_screenshot_daw
    • First observedmcp_opendaw_seconds_to_beats
    • First observedmcp_opendaw_separate_stems
    • First observedmcp_opendaw_serialize
    • First observedmcp_opendaw_set_articulation
    • First observedmcp_opendaw_set_audio_region_fade
    • First observedmcp_opendaw_set_audio_region_gain
    • First observedmcp_opendaw_set_audio_region_time_base
    • First observedmcp_opendaw_set_audio_region_waveform_offset
    • First observedmcp_opendaw_set_automation_interpolation
    • First observedmcp_opendaw_set_bpm
    • First observedmcp_opendaw_set_bus_color
    • First observedmcp_opendaw_set_bus_enabled
    • First observedmcp_opendaw_set_bus_label
    • First observedmcp_opendaw_set_clip_hue
    • First observedmcp_opendaw_set_clip_label
    • First observedmcp_opendaw_set_clip_mute
    • First observedmcp_opendaw_set_clip_playback
    • First observedmcp_opendaw_set_clip_properties
    • First observedmcp_opendaw_set_crusher_bits
    • First observedmcp_opendaw_set_crusher_crush
    • First observedmcp_opendaw_set_delay_sync
    • First observedmcp_opendaw_set_device_label
    • First observedmcp_opendaw_set_effect_enabled
    • First observedmcp_opendaw_set_effect_parameter
    • First observedmcp_opendaw_set_effect_parameter_bool
    • First observedmcp_opendaw_set_effect_parameter_int
    • First observedmcp_opendaw_set_effect_parameter_string
    • First observedmcp_opendaw_set_fold_oversampling
    • First observedmcp_opendaw_set_groove_shuffle
    • First observedmcp_opendaw_set_instrument_param
    • First observedmcp_opendaw_set_loop_region
    • First observedmcp_opendaw_set_marker_label
    • First observedmcp_opendaw_set_marker_position
    • First observedmcp_opendaw_set_marker_repeat
    • First observedmcp_opendaw_set_metronome
    • First observedmcp_opendaw_set_midi_effect_param
    • First observedmcp_opendaw_set_modular_module_param
    • First observedmcp_opendaw_set_neuralamp_model
    • First observedmcp_opendaw_set_note_advanced
    • First observedmcp_opendaw_set_note_cents
    • First observedmcp_opendaw_set_note_properties
    • First observedmcp_opendaw_set_piano_keyboard
    • First observedmcp_opendaw_set_piano_note_labels
    • First observedmcp_opendaw_set_piano_note_scale
    • First observedmcp_opendaw_set_piano_time_range
    • First observedmcp_opendaw_set_playfield_sample_enabled
    • First observedmcp_opendaw_set_position
    • First observedmcp_opendaw_set_region_color
    • First observedmcp_opendaw_set_region_duration
    • First observedmcp_opendaw_set_region_label
    • First observedmcp_opendaw_set_region_loop
    • First observedmcp_opendaw_set_region_mute
    • First observedmcp_opendaw_set_region_position
    • First observedmcp_opendaw_set_revamp_filter
    • First observedmcp_opendaw_set_script_device_code
    • First observedmcp_opendaw_set_script_param
    • First observedmcp_opendaw_set_send_level
    • First observedmcp_opendaw_set_send_pan
    • First observedmcp_opendaw_set_send_routing
    • First observedmcp_opendaw_set_stereo_tool_panning
    • First observedmcp_opendaw_set_studio_setting
    • First observedmcp_opendaw_set_tidal_rate
    • First observedmcp_opendaw_set_time_signature
    • First observedmcp_opendaw_set_time_stretch_cents
    • First observedmcp_opendaw_set_track_enabled
    • First observedmcp_opendaw_set_track_mute
    • First observedmcp_opendaw_set_track_panning
    • First observedmcp_opendaw_set_track_solo
    • First observedmcp_opendaw_set_track_volume
    • First observedmcp_opendaw_set_transpose
    • First observedmcp_opendaw_set_tuning
    • First observedmcp_opendaw_set_unit_minimized
    • First observedmcp_opendaw_set_vaporisateur_osc_param
    • First observedmcp_opendaw_set_vocoder_band_count
    • First observedmcp_opendaw_set_vocoder_modulator_source
    • First observedmcp_opendaw_set_waveshaper_equation
    • First observedmcp_opendaw_shift_mode
    • First observedmcp_opendaw_shuffle_notes
    • First observedmcp_opendaw_split_note_region
    • First observedmcp_opendaw_split_stems
    • First observedmcp_opendaw_spread_voicing
    • First observedmcp_opendaw_start_engine
    • First observedmcp_opendaw_strum_notes
    • First observedmcp_opendaw_subdivide_notes
    • First observedmcp_opendaw_swap_sections
    • First observedmcp_opendaw_switch_phase
    • First observedmcp_opendaw_thin_notes
    • First observedmcp_opendaw_time_warp_notes
    • First observedmcp_opendaw_transcribe_audio
    • First observedmcp_opendaw_transcribe_drums
    • First observedmcp_opendaw_transcribe_melody
    • First observedmcp_opendaw_transfer_audiounit
    • First observedmcp_opendaw_transfer_region
    • First observedmcp_opendaw_transport
    • First observedmcp_opendaw_transpose_notes
    • First observedmcp_opendaw_undo
    • First observedmcp_opendaw_unfreeze_audiounit
    • First observedmcp_opendaw_update_automation_event
    • First observedmcp_opendaw_update_warp_marker
    • First observedmcp_opendaw_validate_project
    • First observedmcp_opendaw_wait_for_condition

TDQS

B3.2/5.0

Scored across 515 tools

Disambiguation1/5

Dozens of tool pairs are functionally indistinguishable: apply_articulation vs set_articulation, split_stems vs separate_stems, create_break vs create_breakbeat, create_chord_progression vs create_chord_pads, create_arpeggio vs create_arpeggiated_progression, get_project_state vs get_full_project_state vs get_project_info vs get_project_metadata, and 30+ genre arrangement tools differing only in genre. An agent cannot reliably select between these without reading every description.

Naming Consistency3/5

The dominant pattern is consistent verb_noun (create_*, set_*, get_*, list_*, delete_*) under a uniform mcp_opendaw_ prefix. However, there are notable deviations: bare nouns (transport, undo, redo, serialize, note_stats), inconsistent compound spelling (audio_unit vs audiounit in duplicate_audiounit vs delete_audio_unit), and mixed noun-verb forms (engine_sleep, ppqn_to_seconds).

Tool Count1/5

515 tools is extreme by any standard — over 10x the high end of a typical well-scoped server. Even for a comprehensive DAW, the count is inflated by ~30 near-identical genre arrangement generators, at least 7 melody generation tools, 3 stem-splitting tools, 4 project-state tools, and dozens of micro-variations. The switch_phase mechanism acknowledges this bloat but doesn't reduce the total surface.

Completeness5/5

The DAW domain is covered end-to-end with no obvious dead ends: project lifecycle (create/load/save/reset), track/region/note editing, instruments, effects, sends/buses, automation, mixing, mastering, rendering/export (WAV/stems/MIDI/dawproject), audio analysis (BPM/key/LUFS/spectrum/stereo/dynamics/masking), transcription, stem separation, and AI-assisted composition. Every workflow from import to master has tooling.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AMEOBIUS-team/opendaw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server