Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Set the motion plan of a frame

figma_set_motion_plan
Idempotent

Record the plan of one animated top-level frame before animating it, as a motion designer does: the brief (audience, message, format, durationS, fps, bpm?) and the beat sheet, beats back to back from 0 to durationS, each with its copy on…

Instructions

Record the plan of one animated top-level frame before animating it, as a motion designer does: the brief (audience, message, format, durationS, fps, bpm?) and the beat sheet, beats back to back from 0 to durationS, each with its copy on screen, action and transition. A role-motion brief (figma_set_brief { role: "motion" }; briefId, or the one in force) fills the fields left out. Checked before anything is stored: times on the frame grid; no gap or overlap; each beat long enough to read its copy, max(5/6 s, 0.3 s a word); accents on the bpm grid; every transition named. Stored on the frame; a new call replaces it. figma_check_motion judges the frame against it: bpm, holds, brandId, ctaId and accept (findings the brief intends, with reasons). Under BRIDGE_PROCESS=strict the keyframe tools refuse a frame without a plan. The result gives each beat's frames and check, the figma_check_motion call. One undo step. Editors: Design only.

Input Schema

NameRequiredDescriptionDefault
cutsNoPlanned hard cuts, in seconds.
beatsYesThe beat sheet, in order, back to back from 0 to brief.durationS.
briefYesThe motion brief; fields left out come from a role-motion brief.
ctaIdNoThe call-to-action layer in the frame, for cta_short.
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.
holdsNoIntended stillness, in seconds: what figma_check_motion's `holds` exempts.
acceptNoFindings the brief intends (a still open, a hard-cut grammar, a loop): figma_check_motion lists them in `accepted`, not against ok.
nodeIdYesThe animated top-level frame, or any layer in it (id or Figma link).
brandIdNoThe brand layer in the frame, for figma_check_motion's brand_late.
briefIdNoThe role-motion brief to take left-out fields from (figma_set_brief returns its id). Default: the motion brief in force.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
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. Changed9 schema fields changedv0.3.0
    • changedInput schema / properties / brief / description
      Previous value: -"The motion brief."New value: +"The motion brief; fields left out come from a role-motion brief."
    • changedInput schema / properties / brief / properties / audience / description
      Previous value: -"Who it is for."New value: +"Who it is for. Default: the motion brief's."
    • changedInput schema / properties / brief / properties / durationS / description
      Previous value: -"Length in seconds, a whole number of frames."New value: +"Length in seconds, a whole number of frames. Default: the motion brief's."
    • changedInput schema / properties / brief / properties / format / description
      Previous value: -"Size and placement, e.g. \"1080x1920 IG Reels\"."New value: +"Size and placement, e.g. \"1080x1920 IG Reels\". Default: the motion brief's format, else its placement."
    • changedInput schema / properties / brief / properties / fps / description
      Previous value: -"Delivery rate: 8, 12, 15, 24, 30, 60."New value: +"Delivery rate: 8, 12, 15, 24, 30, 60. Default: the motion brief's."
    • changedInput schema / properties / brief / properties / message / description
      Previous value: -"The one thing it must say."New value: +"The one thing it must say. Default: the motion brief's."
    • removedInput schema / properties / brief / required
      Removed value: -[
-  "audience",
-  "message",
-  "format",
-  "durationS",
-  "fps"
-]
    • addedInput schema / properties / briefId
      Added value: +{
+  "description": "The role-motion brief to take left-out fields from (figma_set_brief returns its id). Default: the motion brief in force.",
+  "type": "string"
+}
    • 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.8/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: validation before storage, replacement semantics for a new call, strict-mode refusal by keyframe tools, the returned frames and check call, one undo step, and Design-only editor permissions.

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?

It is front-loaded and dense with useful information, not padded. The single-paragraph delivery and long semicolon-separated clauses make it less scannable than a short bulleted structure would be.

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?

For a complex 12-parameter mutation with nested objects and no output schema, it covers validation, storage, replacement, downstream checking, return shape, undo, and permissions. Nothing essential for correct invocation is missing.

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 100%, so the baseline is 3, but the description adds cross-parameter meaning such as beats being back-to-back, brief inheritance, read-time validation, and how accept/holds relate to figma_check_motion. Much of the detail is still duplicated in the very rich schema.

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/resource: record the motion plan of one animated top-level frame before animating it. It clearly distinguishes this setup step from figma_check_motion judging and keyframe tools applying animation.

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?

Explains when to use it: before animating, with fields inherited from a role-motion brief, and notes that strict mode makes keyframe tools refuse a frame without a plan. It also names the sibling tools that consume or support the plan.

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