Skip to main content
Glama

update_layer

Change specific properties of an existing animation layer by ID, such as position, size, timing, text, color, or media, without recreating it.

Instructions

Update properties of an existing layer. Only provide fields you want to change.

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": {
      "layerId": "<layerId>"
    },
    "name": "update_layer"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoX position in px (left edge of bounding box)
yNoY position in px (top edge of bounding box)
loopNoVideo/audio loop
nameNo
seedNoBlob deterministic seed integer
textNoText content (required when type=text)
countNoRepeater: number of copies
endMsNoTime (ms) when layer disappears
mutedNoVideo/audio muted
phaseNoWave phase offset in radians
sidesNoEdge count for polygon/star (3-12) or blob (5-64)
stepXNoRepeater linear: x offset per copy (px)
stepYNoRepeater linear: y offset per copy (px)
turnsNoSpiral turn count (0.5–20)
widthNoWidth in px
heightNoHeight in px
scaleXNoHorizontal scale (1 = 100%)
scaleYNoVertical scale (1 = 100%)
volumeNoVideo/audio volume 0–1
assetIdNoMedia: id of an existing scene asset (see list_assets)
layerIdYesID of the layer to update
opacityNoOpacity 0-1
startMsNoTime (ms) when layer becomes visible
endAngleNoEnd angle for arc/ring in degrees
fontSizeNo
parentIdNoParent group layer id
amplitudeNoWave peak height in px
endRadiusNoSpiral outer ending radius in px
fillColorNoFill hex color e.g. "#3B82F6"
frequencyNoWave full-cycle count across width (0.1–50)
objectFitNoImage fit mode (default contain)
requestIdNo
sessionIdNo
shapeKindNoShape geometry kind
textAlignNo
textColorNo
tightnessNoSpiral radius interpolation exponent (1=linear)
fontFamilyNo
fontWeightNo
startAngleNoStart angle for arc/ring in degrees
stepScaleXNoRepeater: scaleX step per copy
stepScaleYNoRepeater: scaleY step per copy
fillOpacityNo
innerRadiusNoInner radius for star/ring
polarRadiusNoRepeater polar: ring radius (px)
rotationDegNoRotation in degrees
startRadiusNoSpiral inner starting radius in px
stepOpacityNoRepeater: opacity step per copy
strokeColorNo
strokeWidthNo
cornerRadiusNo
irregularityNoBlob noise ratio 0–1
repeaterModeNoRepeater layout
stepRotationNoRepeater: rotation step per copy (deg)
letterSpacingNo
polarEndAngleNoRepeater polar: end angle (deg)
sourceLayerIdNoRepeater: id of the layer to repeat
polarStartAngleNoRepeater polar: start angle (deg)
expectedRevisionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations declare this is a non-read-only, closed-world mutation, so safety framing is already covered. The description adds one genuinely useful behavioral fact: omitted fields are preserved (partial update). It does not disclose failure modes for invalid layer/property combinations, revision conflicts, or what the response contains.

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?

Two short sentences, front-loaded with the action; the sparse-update rule follows immediately with no filler. It is efficient, though extremely sparse for a 59-parameter tool.

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

Completeness2/5

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

For a mutation tool with 59 parameters, five enums, and no output schema, the description omits property-to-layer-type applicability, the meaning/purpose of expectedRevision and requestId/sessionId, and the return shape. An agent can guess the general intent but cannot call it safely on complex layers from this text alone.

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?

At 76% schema description coverage, the schema carries most parameter meaning, and the description adds only the sparse-update convention. It does not explain type-dependent constraints (e.g., text requires a text layer, repeater fields only apply to repeater layers) or the concurrency role of expectedRevision, which the schema leaves bare.

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?

The description uses a specific verb and resource ("Update properties of an existing layer"), making it clearly a mutation of an existing entity rather than creation or deletion, which distinguishes it from add_layer/delete_layer. It doesn't explicitly name a sibling or clarify how it differs from patch_object/update_composition, keeping it short of a 5.

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

Usage Guidelines3/5

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

"Only provide fields you want to change" usefully establishes the sparse-patch convention, which is real usage guidance. However, it offers no when-to-use vs. when-not guidance, no mention of alternatives like patch_object or set_keyframes, and no prerequisites (e.g., layer must exist, type must support the property).

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