Add many elements across one or more clips in a single tool call. Replaces the per-element tool — always batch.
SEND LESS. Most batches repeat themselves — the same clip_index, element_type, font_setting, alignment or gradientSetting on every item. Hoist those into `defaults` and send them once; each item then carries only what differs, and overrides any key it sets (type_data merges one level). On a 20-30 element batch this typically cuts the call by a quarter to a half. `returning` shapes the response the way `select` shapes a get_clip read.
defaults: { clip_index: 2, element_type: 'text', type_data: { font_setting: { font: 'Inter', weight: '600' }, alignment: 'center' } }
elements: [ { name: 'headline', x: 960, y: 400, type_data: { text: 'Hello', fontSize: 120 } }, ... ]
Use after calling get_element_schema to confirm the type_data shape per element_type. Items within one call are applied in order; returns one result entry per input item so partial success is fine.
Reuse instead of rebuilding: an item may pass `component_id` INSTEAD of element_type/type_data to insert a saved component from this workspace exactly as stored — no generation, instant — returning every new element_id plus its parameter_schema; set its content afterwards with update_elements(type_data.parameter_values). Find them with find(type='element_components'). Use `base_component_id` (with element_type='animation' and a prompt) only when you want a NEW variant rather than that component.
Z-order: list position IS z-index — later renders on top — and a new element goes on top by default. Pass `insert_at: 'back'` to put it behind what's already there, or `insert_at: {before: id}` / `{after: id}` to land next to a specific element — that also puts the new element in THAT node's group, which is the only way to place inside one. `reorder_elements` rewrites the whole order in one call, grouped clips included.
`group` + `insert_at: {before|after}` together: what the reference is relative to decides what gets positioned. Point at a node INSIDE the group and the ELEMENT takes that slot among its new siblings. Point at one OUTSIDE it and the GROUP takes that slot, with the element inside — which is how you put a backdrop pattern of N elements at a chosen depth as one hideable unit: hoist both into `defaults` and the first item seats the group, the rest just join it. The one refusal left is naming a reference outside a group that already exists somewhere else, since moving an established group is not what adding one element to it should do; seat the group where you want it in the call that CREATES it, because there is no reposition afterwards. `front`/`back` with a `group` follow the same principle: they address the GROUP only while the element is alone in it — the call that creates it — and once the group has other members they address the ELEMENT within the group's interior, so they will not move an established group either.
Grouping: pass `group: "<name>"` to keep a unit together (a card and its label, a stat and its caption) so the user can move or hide it as one thing. Items in one call sharing a name land in the same group, and a later call with that name adds to it. Grouping never changes coordinates. It does affect z-order: a group's members render contiguously at the group's slot, and a NEW group takes the slot of its first member, so grouping already-adjacent elements keeps their z-position while grouping scattered ones pulls them together at the lowest member's slot.
Concurrency: within ONE call every element lands in a single save. Across calls the conflict domain is the CLIP's element list, not the individual element, so you can fan this tool out across parallel subagents targeting DIFFERENT clips. Two concurrent add_elements calls on the SAME clip are NOT safe: every add claims that clip's element list, so the later call is REJECTED ('changed since this edit was based on') and nothing it sent is written — batch all of a clip's elements into ONE call instead. A rejection is not last-write-wins: re-read and re-apply. Do NOT run it concurrently with a whole-clip or whole-project mutation on the same guide (update_clips on that clip, add_clips/remove_clip/split_clip/duplicate_clip, add_audio, update_project) — those rewrite a larger scope and would clobber the element.
Element-type quirks (handled per-item):
• zoom → x/y/width/height are ignored; use centerX/centerY in type_data
• image → provide x/y/width/height (the clip is located by clip_index; the clip_id input is accepted but unused)
• animation → x/y/width/height default to the full canvas if omitted (the clip is located by clip_index)
For everything else, x/y/width/height are required.
Animation: pass a top-level `keyframes` array (sibling of x/y/type_data, NOT inside type_data) — entries are { timestamp, positionX?, positionY?, width?, height?, interpolation? } in canvas pixels. positionX/Y use the SAME alignment-aware origin as the element's x/y. Text caveat: width/height are not keyframable on text — animate its size with fontSize (letterSpacing/lineHeight/padding* are also keyframable).
Position origin: for TEXT `y` is the vertical CENTRE when centre-aligned and the TOP otherwise; every other type uses the top; `x` is the left edge, except TEXT where alignment picks it: left→left, center→centre, right→right.
To centre a label in a row, pill, chip, card or beside an icon: pass the container's centre line as y with y_anchor:'center'. The server centres the measured text in it, so it is one number and it holds for wrapped text. Add type_data.fit{max_height} whenever the text could wrap, so the box stays inside the space you gave it. y_anchor is a directive for computing the stored y, not a property that sticks — repeat it on any later call that moves the same label.