Skip to main content
Glama

mcp_opendaw_strum_notes

Convert block chords into guitar-style strums by offsetting simultaneous notes in time. Set direction, speed, and jitter to shape the attack and humanize timing.

Instructions

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)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
speedNo
jitterNo
directionNodown
unit_indexNo
track_indexNo
region_indexNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Despite no annotations, the description discloses the algorithm in detail: notes are grouped by simultaneous start, sorted by pitch, then offset by speed × index. It explains the effect on the first note, parameter ranges, and even mentions the return value. This goes well beyond a basic description.

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 and well-structured: purpose, method, parameter details, return value, and examples. No fluff; the technical details are necessary for correct use.

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 MIDI transformation tool with 6 optional parameters and no annotations, the description covers operation, parameter semantics, return value, and usage examples. The output schema covers return structure, so the description need not do 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?

All six parameters are explained in the description, including direction values, speed ranges with musical equivalents, jitter range, and index semantics. Since the schema provides no descriptions (0% 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?

States the tool's function with a specific verb and resource: 'Strum simultaneous notes — convert block chords into guitar-style strums.' The description distinguishes this from sibling tools by focusing on strumming chord voicings, not other rhythmic manipulations.

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 use context: it is for block chords that start simultaneously, converting them into guitar-style strums. Examples show common scenarios (downstroke, upstroke, humanization). However, it does not explicitly name alternatives or exclusions, so it stops short of full when-not guidance.

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