Skip to main content
Glama

clear_automation

Destructive

Remove automation envelopes from an Ableton Session clip, either for one parameter or all at once. Use confirm=False to preview exactly what will be cleared before committing.

Instructions

Delete automation envelopes on a Session clip. Requires confirm=True.

Requires confirm=True. With confirm=False it changes nothing and reports the
envelope it would remove: its range, where the low and the high point sit, and
how densely it was sampled to find them.

That report covers one named parameter. With all_envelopes it says whether the
clip is automated at all, because has_envelopes is one flag for the whole clip.
To see which parameters those envelopes belong to, read
clip.automation_envelopes with lom_get and then each
automation_envelopes[i].parameter.name.

Returns:
    Dictionary reporting the clearance, or the envelopes that would go.

Note:
    A cleared envelope is gone, and the parameter falls back to whatever value it
    holds outside the clip rather than to the first breakpoint. Sample it with
    read_automation first if the shape might be wanted back, since nothing here
    restores it.

    The dry run samples the curve rather than reading its breakpoints, so a
    feature narrower than the reported sampling step can still sit between two
    samples. Where the exact shape matters, read it with read_automation at a
    resolution you choose, or read the breakpoints out of the saved file with
    als_read.

    To change a curve rather than remove it, write_automation with
    ``clear_first=True`` replaces it in one call and needs no clearing first.
    This tool is for leaving the parameter unautomated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotYesClip slot index in track.clip_slots, counted from 0. A slot index is the scene the clip sits in, so slot 2 is the third scene down.
trackYesTrack index in song.tracks, counted from 0.
confirmNoTrue carries the removal out. False changes nothing and returns a report of what the call would remove, which is how to look before committing to it.
parameterNoLOM path to the one DeviceParameter whose envelope should go, e.g. 'song.tracks[0].mixer_device.volume'. Leave empty only when all_envelopes is true.
all_envelopesNoTrue clears every envelope on the clip, ignoring ``parameter``. One of this or ``parameter`` has to be given; neither is refused rather than treated as clear everything.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / properties / all_envelopes / description
      Added value: +"True clears every envelope on the clip, ignoring ``parameter``. One of this or ``parameter`` has to be given; neither is refused rather than treated as clear everything."
    • addedInput schema / properties / confirm / description
      Added value: +"True carries the removal out. False changes nothing and returns a report of what the call would remove, which is how to look before committing to it."
    • addedInput schema / properties / parameter / description
      Added value: +"LOM path to the one DeviceParameter whose envelope should go, e.g. 'song.tracks[0].mixer_device.volume'. Leave empty only when all_envelopes is true."
    • addedInput schema / properties / slot / description
      Added value: +"Clip slot index in track.clip_slots, counted from 0. A slot index is the scene the clip sits in, so slot 2 is the third scene down."
    • addedInput schema / properties / track / description
      Added value: +"Track index in song.tracks, counted from 0."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true, but the description adds substantial behavioral context: confirm=True is required for actual deletion, confirm=False is a dry run, a cleared envelope falls back to the outside-clip value rather than the first breakpoint, and the dry run's sampling can miss narrow features. This goes well beyond the annotation flags.

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?

The description is well-organized with Returns and Note sections, but it repeats 'Requires confirm=True' verbatim in consecutive paragraphs, which is avoidable waste. The remaining detail is dense but mostly necessary, so it is more verbose than ideal.

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 destructive tool with 5 parameters, the description covers the action, prerequisites, dry-run semantics, return shape, irreversibility, sampling limitations, and alternatives. The presence of an output schema means the return value does not need further elaboration, so nothing important 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 100%, so the baseline is 3, but the description adds meaningful parameter behavior: it explains the interaction between parameter and all_envelopes, clarifies what the confirm flag does, and warns about the difference between one named parameter versus whole-clip has_envelopes reporting. This supplements the schema without repeating it.

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 opens with a specific verb and resource: 'Delete automation envelopes on a Session clip.' It clearly distinguishes this from sibling tools like write_automation and read_automation by framing the action as removal, not modification or inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing: 'To change a curve rather than remove it, write_automation with clear_first=True... This tool is for leaving the parameter unautomated.' It also advises sampling with read_automation before destructive clearing and using als_read for exact breakpoints, so the agent knows when to pick alternatives.

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

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/romanstark/live-maestro'

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