Skip to main content
Glama

Create an animatic

figma_create_animatic
Idempotent

Turn a storyboard board into a timed animatic: one plate per panel, each shown on its frames, switched by frame-exact opacity cuts at the board's fps.

Instructions

Play a storyboard back at its planned pace: turn a figma_create_storyboard board into an animatic, a top-level frame Animatic · <title> with one plate per panel, each on screen on exactly the panel's frames, switched by frame-exact OPACITY cut pairs. Timing is read from the board as it is now (each duration caption), at the board's fps. A plate shows the panel's best picture: its styleframe once something is drawn in it, else its source rendered again, else its thumbnail; blank lists panels with nothing yet. dissolveFrames cross-fades out of a panel whose transition caption starts with "dissolve"; drift pushes each plate 3 %; burnIn labels plates. Every track is read back (verified, else notApplied). The result's render is the figma_export_video call; then judge the pace with figma_review_video. Plates 2–n rest at opacity 0, so figma_export_node shows panel 1. Skill: storyboard (figma_get_guide). One undo step. Editors: Design only, unverified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoDefault: right of everything on the page.
yNo
driftNoPush each plate's picture 3 % over its panel, so a held panel does not read as a freeze. Default false.
widthNoPlate width in px; the height follows the board's aspect. Default 1080 (1920 for 16:9).
burnInNo"panel" (default): each plate's number and title in its corner; "full": also its time, frames and the beat, action, camera and transition captions; "none".
pageIdNoThe page to build on, at its top level. Default: the board's page.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
storyboardIdYesThe board figma_create_storyboard returned (its storyboardId: the Storyboard / <title> frame), id or Figma link.
dissolveFramesNoFrames of cross-fade out of a panel whose transition caption starts with "dissolve". Default 0: every change is a cut.
idempotencyKeyNoCaller-owned retry key, ≤128 chars. Re-calling with the same key never executes twice: it returns the existing result, or waits for the op still in flight. Supply your own for anything large — if the MCP client times out (rather than the bridge), only a key you chose can be used to retry safely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Going beyond the annotations (which only declare non-readonly, idempotent, non-destructive, closed-world), the description discloses the creation mechanics (one plate per panel, frame-exact opacity cuts), that outputs are read back as `verified` or `notApplied`, that plates 2–n rest at opacity 0, and that it costs one undo step and is Design-editor-only + unverified. This is rich behavioral context; only minor gaps (e.g. failure modes, scale limits) remain.

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?

Purpose is front-loaded in the first clause, and the dense detail that follows is generally relevant. It is long and several clauses are run-on, but for a complex 10-parameter generative tool most sentences earn their place.

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?

With no output schema, the description compensates by describing return semantics (`render` is the export_video call, `blank` lists empty panels, per-track `verified`/`notApplied`), the visual result, the frame-timing mechanics, editor restrictions, and undo cost. Nothing essential for invoking it correctly appears to be missing.

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 description coverage is already 90%, so the schema documents x/y/drift/width/burnIn/dissolveFrames/idempotencyKey thoroughly. The description restates and contextualizes a few behaviors (dissolveFrames cross-fades, drift pushes 3%, burnIn labels, blank lists empty panels) but adds little syntax or format detail beyond the schema. Baseline 3 applies.

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?

Names a specific verb and resource ('turn a figma_create_storyboard board into an animatic') and describes the concrete artifact produced (a top-level frame `Animatic · <title>` with one plate per panel). It explicitly references the sibling figma_create_storyboard it consumes, so an agent can distinguish it from other create tools at a glance.

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

Usage Guidelines4/5

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

Lays out a clear pipeline: read timing from the board as-is, then export via figma_export_video and judge pace with figma_review_video, with the storyboard skill guide referenced. It gives context for when this applies, but does not state explicit exclusions or when-not-to-use conditions.

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