Skip to main content
Glama

clip_action

Destructive

Edit Ableton Live clips in place: crop, duplicate loops, quantize notes or pitch, scrub, adjust warp markers, and copy session clips to the arrangement timeline.

Instructions

Edit a clip in place: crop (discard everything outside the loop), duplicate_loop (loop twice as long, notes and envelopes copied; MIDI only), quantize (grid: rec_q_quarter, rec_q_eight, rec_q_eight_triplet, rec_q_sixtenth, rec_q_thirtysecond...; amount 0-1, default 1; on audio clips it aligns warp markers), quantize_pitch (like quantize for one pitch, 0-127; MIDI only), scrub (position in beats) / stop_scrub, move_playing_pos (amount beats, negative goes back; clip must be playing), and on AUDIO clips add_warp_marker (beat_time; sample_time = seconds in the file, default: where it changes nothing), move_warp_marker (beat_time of an existing marker, distance in beats: this is how audio is retimed) and remove_warp_marker (beat_time); current markers are the clip's warp_markers property. to_arrangement copies a SESSION clip onto its track's arrangement timeline at time (beats) and returns the new clip's address; a clip that carries automation envelopes turns them into arrangement track automation (the envelopes do not stay on the copy; the result lists the parameters now automated), which is how arrangement automation is written: draw_automation on the Session clip first. address must be a clip. crop and quantize rewrite content: one undo step each, and expect ({name}) refuses to act on the wrong clip. Returns the clip's length and loop after the action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gridNoSong.RecordingQuantization name (quantize, quantize_pitch)
timeNoto_arrangement: destination position in beats on the arrangement
pitchNoMIDI note number (quantize_pitch)
actionYesWhat to do
amountNoquantize: 0-1 strength; move_playing_pos: beats
expectNoGuard: {"name": "..."} must match the clip
addressYesA clip, e.g. 'tracks/2/slots/0/clip'
distanceNomove_warp_marker: beats to move by
positionNoBeats from the clip start (scrub)
beat_timeNoWarp marker actions: the marker position in beats
sample_timeNoadd_warp_marker: position in the file in seconds

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.3

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description goes further: crop 'discard[s] everything outside the loop', crop/quantize each cost 'one undo step', and the `expect` guard 'refuses to act on the wrong clip'. It also discloses envelope-copy and envelope-to-arrangement-automation side effects, which the annotations cannot express.

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?

Length is defensible for 11 actions, but it is delivered as one dense run-on paragraph heavy with parentheticals and semicolons, with no per-action structure. The opening clause is front-loaded well, yet the middle is hard to scan, so each sentence only partly 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?

For an 11-parameter, 11-action tool with no output schema, it covers preconditions, side effects, undo cost, and even the return value ('the clip's length and loop after the action'). Minor gaps remain (e.g., detailed behavior of stop_scrub, error modes), but nothing an agent needs to call it 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 coverage is already 100%, so baseline is 3; the description nevertheless adds real semantics beyond the schema: the actual grid enum values (rec_q_quarter, rec_q_eight, ...), `amount` 0-1 with default 1, sample_time defaulting to 'where it changes nothing', and the meaning of `beat_time`/`distance` as retiming. Only the omission of explicit defaults for a few params keeps it off 5.

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

Purpose5/5

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

Starts with a specific verb+resource ('Edit a clip in place') and then enumerates the exact 11 operations with what each does, letting an agent separate clip-level edits from the note-level siblings (edit_notes, transform_notes) and from automation siblings. MIDI-only vs audio-only scoping is stated per 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?

Gives per-action preconditions and routing ('clip must be playing' for move_playing_pos; MIDI only for duplicate_loop/quantize_pitch; audio-only for warp markers) and names a genuine alternative workflow by telling the agent to use draw_automation on the Session clip first for arrangement automation. It does not systematically cover when *not* to use a given action, but the when-to-use coverage is well above average.

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