Skip to main content
Glama

Create a storyboard

figma_create_storyboard
Idempotent

Lay out a motion piece's storyboard before animating it: a board of cards in rows, one per panel, each a thumbnail frame at aspect above caption rows (time, duration, story beat, on-screen copy, action, camera, transition, audio, notes).

Instructions

Lay out a motion piece's storyboard before animating it: a board of cards in rows, one per panel, each a thumbnail frame at aspect above caption rows (time, duration, story beat, on-screen copy, action, camera, transition, audio, notes). Timing is derived from each panel's durationS, snapped to whole frames by default: start and end in seconds and frames at fps, and bar.beat with bpm. The result lists panels that start off the beat (offBeat) and copy on screen too briefly to read (readTime): fix both before building. A panel can snapshot a frame of this file (source), show an image already in it (image), or get an empty full-size styleframe beside the board (styleframe). Sketch into a thumbnail with figma_create_from_spec { parentId: thumbId }. The duration caption is the plan: edit its text to retime a panel. A plan, not an animation: figma_set_keyframes animates. Skill: storyboard (figma_get_guide). One undo step. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
xNoDefault: right of everything on the page.
yNo
bpmNoTempo: adds bar.beat per panel and lists panels that start off the beat.
fpsNoFrame rate the frame numbers use. Default 30.
snapNoRound each duration to whole frames (default), whole beats (needs bpm), or not at all. Changes are listed in `snapped`.
forceNoOverwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.
titleYesThe piece's name; the board is named Storyboard / <title>.
aspectYesOf every thumbnail and styleframe.
pageIdNoThe page to build on, at its top level. Default: the current page.
panelsYes
columnsNoCards per row. Default 6 (9:16), 5 (4:5, 1:1), 4 (16:9).
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
captionsNoCaption rows on every card, always in this order. Default: timecode, duration, and every row any panel fills.
thumbWidthNoThumbnail width in px; height follows the aspect. Default 216 / 288 / 300 / 384 by aspect.
beatsPerBarNoDefault 4. Needs bpm.
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.
styleframeWidthNoStyleframe width in px. Default 1080 (1920 for 16:9).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / force
      Added value: +{
      +  "description": "Overwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.",
      +  "type": "boolean"
      +}
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare it is a write (readOnlyHint=false) that is idempotent and non-destructive; the description adds value beyond them by noting "One undo step" and disclosing that the result flags offBeat panels and readTime issues to fix before building. It doesn't spell out return structure or failure modes, keeping it from a 5.

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 with purpose and artifact structure, then timing rules, then alternatives. It is dense but every sentence (snapping, offBeat/readTime warnings, sketch/retime workflow) carries operational information rather than padding.

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

Completeness4/5

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

For a 17-parameter tool with no output schema, the description covers when to use it, how timing is computed, what the result flags (offBeat, readTime), and the follow-up path. Return-value detail is partial and the `source`/`image`/`styleframe` panel modes are only lightly sketched, leaving minor gaps.

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

Parameters4/5

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

Schema coverage is high (88%), so the schema carries most parameter documentation. The description nevertheless adds semantics the schema doesn't: timing is derived from each panel's `durationS` and snapped to whole frames by default, with start/end expressed in seconds and frames at `fps` and bar.beat via `bpm`.

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?

States a specific verb and resource ("Lay out a motion piece's storyboard") and immediately defines the artifact: a board of card rows, one per panel, thumbnail at `aspect` above caption rows. It explicitly contrasts with the animation sibling ("figma_set_keyframes animates"), so an agent can distinguish it without opening a schema.

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?

Gives explicit when-to-use (before animating), routes to concrete alternatives (figma_create_from_spec for sketching thumbnails, figma_set_keyframes for animation, figma_get_guide for the skill), and states the retiming workflow (edit the duration caption). It also names supported environments (Design) versus unverified ones (FigJam, Slides).

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