Skip to main content
Glama

Change a project's song

r3_song_update
Destructive

Change a project's Song with small typed changes, or make a new Song (create). The changes are applied in order and kept as ONE change (one undo step, every open R3 tab shows it): ops: setSong, setSections, setMaster, addTrack, setTrack, removeTrack, setClips, addClip, moveClip, removeClip, setLane, removeLane, addPoint, setPoint, removePoint, setChain, setEffect, addModulator, removeModulator, insertBars, splitClip, transposeClip, setClipGain. Tracks are named by their id ("kick"), sources by entityRef (a Pattern, DrumGrid, Beat, Audio or AudioPositional), clips and lane points by their index as r3_song_read lists them, positions in bars (bar 0 = the start). Examples: {"op": "moveClip", "track": "hats", "clip": 0, "start": 6}; {"op": "setLane", "track": "master", "target": "lp.frequency", "points": [{"bar": 0, "value": 350, "curve": "exp"}, {"bar": 12, "value": 1200}]}; {"op": "insertBars", "at": 64, "count": 8} (moves everything from bar 64 on 8 bars later); one eighth of a clip a few semitones higher, its length kept: {"op": "splitClip", "track": "bass", "clip": 0, "at": 65}, {"op": "splitClip", "track": "bass", "clip": 1, "at": 65.125}, {"op": "transposeClip", "track": "bass", "clip": 1, "semitones": 2} (whole semitones -24..24; a Sound Studio sound is rendered again from its public recipe, another file pitch-shifted, a Pattern's synth notes moved; 0 takes it off); that clip quieter (a clip's Volume in dB, -24..12, on top of its track's; 0 takes it off): {"op": "setClipGain", "track": "bass", "clip": 1, "gain": -4}. A song is version-checked, never merged: changing one needs baseVersion, the songVersion r3_song_read answered; if someone changed it since, the write is refused with the current version. A new Song (create) needs none. Every result is checked by lib-r3's song schema (SONGS.md) before anything is kept. How-to: HOWTO_SONG.md.

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": {
      "projectId": "<projectId>"
    },
    "name": "r3_song_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
songNoThe Song's entityRef; leave it out when the project has one song.
createNoMake a NEW Song (wired to the project's Transport), then apply changes to it, e.g. {"name": "Main song"}.
changesNoThe changes, in order: [{"op": "setTrack", "track": "kick", "gain": -3}, …]. Required unless create.
projectIdYesThe project, from r3_project_list.
baseVersionNoREQUIRED to change a song: its songVersion from r3_song_read. Leave it out with create.

Output Schema

NameRequiredDescriptionDefault
seqNo
nameYes
partsYes
actionYes
answerYesThis answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
changedYes
summaryYes
warningsNo
entityRefYes
projectIdYes
componentIdYes
songVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

The description reveals complex behavioral traits not covered by annotations, including the sequential application of operations, the 'one undo step' mechanism, and the specific version control refusal logic.

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 highly technical and dense, resembling API documentation more than concise natural language, but its extreme verbosity is justified by the complexity of the function it encapsulates.

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?

Given the complexity of handling granular audio operations like 'splitClip' and 'setLane', the description is maximally complete, detailing all necessary operational logic and constraints for correct invocation.

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?

Despite 100% schema coverage, the description adds vital semantic value by defining the operational types (the list of 'ops') and the specific requirements for the 'baseVersion' and 'create' parameters.

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 clearly states that the tool is used to either change an existing song or create a new one, differentiating its high-level function within the R3 project context.

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?

It explicitly outlines critical usage constraints, such as the necessity of providing `baseVersion` for updates and the version-checking policy which prevents overwriting changes made by others.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources