Skip to main content
Glama
LiveSession MCP
by Uri-Rosen

set_clip_automation

Draw stepwise automation inside a Session or Arrangement clip, letting you shape volume, pan, sends, or device parameters over time by setting value points in beats.

Instructions

Draw automation inside a Session clip as steps.

  • parameter: with device_index omitted, a mixer control: "volume", "pan" or "send 0"; otherwise a parameter name/index on that device

  • points: [{"time": beats, "value": raw value}, ...]; each value holds until the next point Example — fade the volume up over 4 bars: points=[{"time":0,"value":0.4},{"time":8,"value":0.6},{"time":16,"value":0.85}]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "track_index": "<track_index>",
      "clip_index": "<clip_index>",
      "parameter": "<parameter>",
      "points": "<points>"
    },
    "name": "set_clip_automation"
  }
}

Input Schema

NameRequiredDescriptionDefault
pointsYes
parameterYes
clip_indexYes
arrangementNo
clear_firstNo
track_indexYes
device_indexNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false. The description never discloses that `clear_first` defaults to true, meaning existing automation on the clip is overwritten by default — a materially destructive behavior for a tool flagged non-destructive. It also omits what happens on out-of-range times or invalid parameter names.

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 purpose sentence followed by two tightly scoped bullets and a concrete example; no filler. The example is long but earns its place by demonstrating value scaling and bar-to-beat conversion.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the points/parameter semantics are covered well. However, for a 7-parameter mutation tool with zero schema descriptions, the default-on overwrite (`clear_first`) and the `arrangement` mode are significant omissions that an agent needs before calling it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the load, and it does well on the two hardest parameters: `parameter` addressing (mixer control vs device parameter) and `points` shape with the hold-until-next-point rule plus a worked fade example. It says nothing about `clear_first`, `arrangement`, `track_index`, or `clip_index`, leaving four of seven parameters undocumented anywhere.

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?

"Draw automation inside a Session clip as steps" names a specific verb (draw) and resource (clip automation) and implicitly separates it from clear_clip_automation and set_device_param. The wording is slightly undercut by the presence of an undocumented `arrangement` flag, which suggests the tool is not strictly Session-only.

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?

No statement of when to use this versus clear_clip_automation (to wipe automation) or set_device_param (for one-off parameter changes). The bullet about `parameter` describes addressing modes, not usage conditions, so the agent must infer the choice from sibling names alone.

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

Deploy Server

Other Tools