Skip to main content
Glama

clear_automation

Destructive

Remove automation envelopes from a Session clip. Preview what would be cleared with a dry run, then confirm to delete specific or all parameter envelopes.

Instructions

Delete automation envelopes on a Session clip. 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 only 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoLOM path to a Session clip, song.tracks[N].clip_slots[M] with or without a trailing .clip, as an alternative to track and slot. A song.tracks[N].arrangement_clips[i] path is refused with code region_not_addressable.
slotNoClip slot index in track.clip_slots, counted from 0, which is the scene the clip sits in. Give track and slot, or give path instead. These are Session coordinates; an Arrangement clip has none.
trackNoSession track index in song.tracks, counted from 0. Give track and slot, or give path instead. These are Session coordinates; an Arrangement clip has none.
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.

  1. Changed10 schema fields changed
    • addedInput schema / properties / path
      Added value: +{
      +  "default": "",
      +  "description": "LOM path to a Session clip, song.tracks[N].clip_slots[M] with or without a trailing .clip, as an alternative to track and slot. A song.tracks[N].arrangement_clips[i] path is refused with code region_not_addressable.",
      +  "title": "Path",
      +  "type": "string"
      +}
    • addedInput schema / properties / slot / anyOf
      Added value: +[
      +  {
      +    "minimum": 0,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / slot / default
      Added value: +null
    • changedInput schema / properties / slot / description
      Previous 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."New value: +"Clip slot index in track.clip_slots, counted from 0, which is the scene the clip sits in. Give track and slot, or give path instead. These are Session coordinates; an Arrangement clip has none."
    • removedInput schema / properties / slot / type
      Removed value: -"integer"
    • addedInput schema / properties / track / anyOf
      Added value: +[
      +  {
      +    "minimum": 0,
      +    "type": "integer"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / track / default
      Added value: +null
    • changedInput schema / properties / track / description
      Previous value: -"Track index in song.tracks, counted from 0."New value: +"Session track index in song.tracks, counted from 0. Give track and slot, or give path instead. These are Session coordinates; an Arrangement clip has none."
    • removedInput schema / properties / track / type
      Removed value: -"integer"
    • removedInput schema / required
      Removed value: -[
      -  "track",
      -  "slot"
      -]
  2. 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."
  3. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, but the description adds essential nuance: confirm=True actually deletes, confirm=False is a dry-run report. It discloses the fallback behavior (parameter returns to outside value, not first breakpoint), sampling limitations, and the all_envelopes report limitation. This goes far 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but every section serves a purpose. It is front-loaded with the primary action and structured with Returns and Note sections for clarity. Slightly more verbose than necessary, but the density of critical caveats justifies the length.

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 6 parameters and an output schema, the description covers purpose, usage, behavior, parameter interactions, alternatives, and error handling (refusing Arrangement paths). Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, but the description enriches parameter meaning: confirm's dry-run vs. actual behavior, the mutual exclusivity of parameter and all_envelopes (neither is refused), and how to resolve parameter names via lom_get. It adds context the schema alone lacks.

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 precise verb+resource: 'Delete automation envelopes on a Session clip.' It immediately distinguishes from Arrangement clips and names sibling tools (write_automation, read_automation) for alternatives. An agent can confidently select this tool over its siblings without ambiguity.

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?

Explicit guidance is given: use write_automation with clear_first=True to change a curve, use read_automation to preserve shape, and use lom_get to inspect envelope parameters. It also clarifies the Session-only scope and the confirm requirement. No inference is needed.

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