Skip to main content
Glama

mcp_opendaw_generate_melody

Generate melodic lines from any scale using contour-guided random selection. Specify contour shape, rhythm, key, and octave to create melodies directly in openDAW tracks.

Instructions

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)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
barsNo
rootNoC
scaleNomajor
octaveNo
rhythmNomixed
contourNoarch
velocityNo
start_beatNo
unit_indexNo
track_indexNo
rest_probabilityNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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 step-by-step algorithm (scale building, contour mapping, weighted random selection, rhythm application, rest insertion) and return values. However, it does not state whether existing notes on the target track are replaced or appended, an important side-effect for a generation 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 long but well-structured: summary, detailed option lists, numbered algorithm steps, parameter list, return value, and examples. Every sentence adds value, and the organization makes it 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 11 parameters, no schema descriptions, and complex algorithm, the description is remarkably complete: covers all parameters, algorithm behavior, musical intent of each option, and return values. Minor gaps like track content replacement are noted but do not undermine overall 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 thoroughly documents every parameter, including enumerated options for contour, rhythm, scale, and numeric ranges/defaults for bars, velocity, octave, and rest_probability. 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 generates a melodic line from a scale using contour-guided random selection. It explicitly says 'Creates a melody from scratch — no chord progression needed', distinguishing it from sibling tools like create_melody_from_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?

Provides strong context for usage: 'no chord progression needed' and examples for different musical scenarios (arch-shaped C major, ascending pentatonic, sparse ambient). However, it does not explicitly name alternative tools or give when-not-to-use guidance, so it falls short of a 5.

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

Install Server

Other Tools

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-ai/opendaw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server