Skip to main content
Glama
AvYour

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check motion frame by frame

figma_check_motion
Read-only

Audit an animated Figma frame's motion from keyframes without rendering, catching pops, dead holds, blur errors and timing issues with per-layer fixes before export.

Instructions

A motion designer's frame-by-frame check of an animated top-level frame from its keyframes, no render: figma_check_layout for motion. Each issue names layer, field, frame and numbers at fps, with a fix. It finds pops and vanishes mid-move, one frame carrying most of a move, fast moves without blur, blur out of phase, one-frame peaks, arrivals never held, dead stretches (outside holds), a cold open, template moves, missing staggers, keys between frames, HOLD, beat offsets (bpm or beatTimes), text too brief, a late brand or short CTA (brandId, ctaId). The frame's plan (figma_set_motion_plan) fills bpm, holds, brandId and ctaId when left out; its accept lists intended findings apart. ok: true = no errors or warnings. A whole passing check (no rules, from, to, nothing looser than the plan) at the delivery fps unlocks figma_export_video { final: true } until the file changes. Then figma_review_video. UNSUPPORTED: no Figma Motion here. Skill: critique. Editors: Design only, unverified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoJudge up to this time, s. Default the end.
bpmNoTempo: turns on the beat check. Default the plan's.
fpsNoFrame rate to judge at; match the planned export. Default 30.
fromNoJudge from this time, s. Default the start.
ctaIdNoThe call-to-action layer: turns on cta_short. Default the plan's.
holdsNoIntended stillness, exempt from dead_span: seconds, e.g. [{ from: 10.4, to: 10.9 }], or frames at `fps`, e.g. [{ fromFrame: 312, toFrame: 327 }]. Default the plan's.
limitNoMax findings returned. Default 100.
rulesNoOnly these rules. Default all.
nodeIdNoThe animated top-level frame, or any layer in it (id or Figma link). Default: the selection's frame, else the page's only animated frame.
brandByNoBrand fully visible by this time, s. Default 3.
brandIdNoThe brand layer: turns on brand_late. Default the plan's.
ctaMinSNoSeconds the CTA must stay readable. Default 2.5.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
maxNodesNoLayers read. Default 2000.
beatTimesNoThe beat times of the music in seconds, increasing: the beat check uses them instead of the bpm grid.
beatOffsetNoTime of the first downbeat, s. Default the plan's, else 0.
thresholdsNoOverride a default threshold; each comes from a measured 2026-10-09 finding.
beatsPerBarNoDefault 4.
minSeverityNoHide findings below this level. Default "info".
includeActivityNoAdd `activity`: the fastest on-screen move per frame, px.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnly/non-destructive/closed-world; the description adds genuinely new behavior — keyframe-based analysis with no render, the meaning of ok:true, the export-unlock gate that expires when the file changes, and the plan-default-fill behavior. It does not cover permission requirements or error/limit behavior, so it stops short of the top of the range.

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 removal signal ('no render') lands immediately. It is a dense wall of clauses for a 20-parameter tool, but nearly every sentence maps to a distinct capability or workflow step rather than padding.

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?

Despite no output schema, the description sketches the return shape ('each issue names layer, field, frame and numbers at fps, with a fix') and the ok:true contract, and it covers the surrounding workflow and the unsupported case. For a complex 20-param checker this is complete enough to invoke correctly.

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. The description goes beyond the schema by explaining cross-parameter semantics: which params the plan supplies by default, that `holds` are exempt from dead_span, that `rules`/`from`/`to` must stay as loose as the plan to preserve the ok verdict, and that bpm/beatTimes/brandId/ctaId each toggle a specific rule.

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 ('frame-by-frame check of an animated top-level frame from its keyframes'), plus a crisp scope qualifier ('no render'). It explicitly positions itself against the sibling figma_check_layout, so an agent can distinguish the two without opening either 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 when-to-use via the workflow chain: figma_set_motion_plan fills bpm/holds/brandId/ctaId, this check runs, a clean pass unlocks figma_export_video { final: true }, then figma_review_video. It names the alternative (figma_check_layout) and states the failure-mode scope (UNSUPPORTED: no Figma Motion here), leaving little to inference.

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