Skip to main content
Glama

mcp_opendaw_create_modulated_song

Create a multi-section song with automatic key modulation between sections. Specify each section's chord progression, bars, and energy level.

Instructions

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")

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

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

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