Skip to main content
Glama

create_chord_progression

Creates a chord progression as a single MIDI item on a track from comma-separated chord names and a start position, enabling quick MIDI composition in REAPER.

Instructions

Create a chord progression on a track as a single MIDI item. chords: comma-separated chord names, e.g. "C,G,Am,F" or "Cm7,Fm7,Bb7,Ebmaj7". Supports: maj, min/m, dim, aug, maj7, min7/m7, dom7/7, dim7, hdim7, sus2, sus4. All chords are voiced around middle C (MIDI 60).

Input Schema

NameRequiredDescriptionDefault
chordsYes
track_indexYes
start_positionYes
beats_per_chordNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

C2.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 but does disclose meaningful behavior: everything is written as a single MIDI item and all chords are voiced around middle C. It omits mutation side effects, what happens to existing item content, error conditions, and the response shape, leaving substantial 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?

Front-loaded with the core action and efficient across four short lines, with no filler. Slightly under-sizes the explanation of the non-chord parameters, but the structure itself is clean.

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 4-parameter mutation tool with zero schema descriptions, no annotations, and no output schema, the description should cover positioning units, beats_per_chord behavior, and track targeting. It only fully addresses one parameter, leaving the agent under-specified for correct invocation.

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, but it only really explains the 'chords' parameter (comma-separated, supported types). It leaves 'start_position' units unclear, never mentions 'beats_per_chord' behavior despite a default, and doesn't clarify '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?

States a specific verb and resource ('Create a chord progression on a track as a single MIDI item'), which is clear and actionable. However, it does not distinguish itself from sibling tools like create_midi_item or add_midi_note, which an agent could reasonably confuse with this higher-level helper.

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 never says when to prefer this over create_midi_item, add_midi_note, or create_drum_pattern, nor does it state prerequisites (e.g., that the track must exist). Usage is left entirely to inference.

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