Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Remove keyframes (Motion)

figma_remove_keyframes
Idempotent

Remove a layer's manual keyframe tracks: the given fields, or every track when omitted. A field that is not animated is reported in notAnimated, not an error.

Instructions

Remove a layer's manual keyframe tracks: the given fields, or every track when omitted. A field that is not animated is reported in notAnimated, not an error. Each removal is read back once Figma settles and repeated if the track is still there; one that will not go fails INTERNAL with partial.notRemoved. Returns removed and remaining, read back. Animation styles are not touched; figma_set_keyframes writes tracks. Under BRIDGE_PROCESS=strict (the default) PROCESS_REQUIRED until this session read the motion skill (figma_get_guide) and the frame has a plan (figma_set_motion_plan). Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
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.
fieldsNoFields as figma_get_motion_context names them, e.g. ["OPACITY", "fill:0"].
nodeIdYes
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. 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.8/5.0
Behavior5/5

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

Annotations already cover safety flags, but the description adds substantial non-structured context: read-back verification, automatic retry, the specific failure mode (INTERNAL with `partial.notRemoved`), non-animated fields reported in `notAnimated` rather than erroring, and environment gating (BRIDGE_PROCESS=strict, PROCESS_REQUIRED). This is behavior an agent cannot get from annotations.

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-loads the core action and scope in the first clause, then layers failure/reporting semantics. Dense and mostly waste-free, though it compresses a lot of distinct concepts into long clauses that could be split for scanability.

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 and 5 parameters, the description supplies what is missing: the returned values (`removed`, `remaining`, `notAnimated`), partial-failure behavior, retry semantics, and environment gating. An agent has everything needed to call this correctly and interpret results.

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 80% and already documents force, fields, session, and idempotencyKey. The description still adds real meaning beyond the schema: omitting `fields` removes every track, and unanimated fields land in `notAnimated`. It does not restate the field naming format that the schema already gives.

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 ('Remove a layer's manual keyframe tracks') and immediately scopes it: the named `fields`, or every track when omitted. It explicitly contrasts with the sibling that writes tracks (figma_set_keyframes), so an agent can distinguish the two without inspecting schemas.

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?

Names the alternative (figma_set_keyframes writes tracks) and the boundary (animation styles are not touched), and spells out preconditions for strict mode: read the motion skill via figma_get_guide and have a plan via figma_set_motion_plan. When-to-use and when-not-to-use are both inferable with no ambiguity.

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