Allows programmatic creation and manipulation of motion animations (keyframes, animation styles) in Figma via its Motion API, enabling AI agents to apply, read, and remove motion timelines on selected nodes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Figma Motion MCP apply fadeInUp to selection, duration 0.5s"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Code → MCP → our Figma plugin → Figma Plugin API. Authors Figma Motion
(keyframes / animation styles) programmatically from a prompt. No Figma agent, no use_figma.
Claude Code ──stdio(JSON-RPC)── MCP server ──ws://localhost:3055── plugin ui.html ──postMessage── plugin main thread ── figma.* (Motion API, Beta)The MCP server process also hosts the WebSocket bridge, so there is no separate relay.
MCP tool | Plugin command | Purpose |
|
| selected node id/name/type |
|
| confirm Motion (Beta) API is exposed in your build |
|
| current timelines / animated props / tracks / styles |
| (server local) | built-in code templates |
|
| resolve template+params → apply keyframe tracks |
|
| raw keyframe tracks |
|
| timeline length (s) |
|
| delete tracks and/or applied styles |
|
| native preset styles |
|
| apply a native preset |
Create / modify / delete are all covered. Template resolution runs server-side — the plugin only ever receives concrete tracks, so it stays dumb and templates are versioned here.
Related MCP server: Figma MCP Bridge
The folder is self-contained (no monorepo deps). Hand someone this folder, they run:
cd figma-motion-mcp
./setup.shsetup.sh does npm install, resolves your absolute node path (nvm-safe), and registers
the MCP server figma-motion at local scope (this project only, not committed — so
each teammate registers their own; no shared/hardcoded paths). It prints the remaining
manual steps.
claude CLI)npm install
claude mcp add figma-motion -- "$(command -v node)" "$(pwd)/server/mcp-server.js"
claude mcp get figma-motion # verifynvm users: the absolute node path matters — the MCP subprocess won't inherit your shell PATH.
setup.sh/ the$(command -v node)form handles this automatically.
Figma desktop → Plugins → Development → Import plugin from manifest… → pick
figma-motion-mcp/plugin/manifest.json. Open a NEW Claude session (it auto-starts the
server + WS bridge); the panel should turn green "Connected — bridge ready".
Typings (@figma/plugin-typings@1.130.0) confirm the Motion API contract, but it is Beta
and gated per build/seat. Before relying on it:
In Figma, select any node, then run the plugin.
In Claude: "run probe".
Confirm applyManualKeyframeTrack: "function" and figma.motion is non-null.
animatedProperties shows the real field names for your build — if any template name
mismatches, fix it in server/templates.js.
If applyManualKeyframeTrack is "undefined", Motion is not enabled in your Figma build yet.
1) Select a frame/layer in Figma.
2) "get_selection" → nodeId
3) "apply fadeInUp to <nodeId>, duration 0.5" → apply_motion_template
4) "read_motion <nodeId>" → timelines / animatedProperties
5) "nudge TRANSLATION_Y keyframe to 32→0" → apply_keyframes
6) "remove OPACITY motion from <nodeId>" → remove_motionMotion API is Beta — signatures may change. Write calls are wrapped; typings pinned to 1.130.0.
No native style publishing (apply-only). Reuse lives in server/templates.js.
Single-client MVP — newest plugin connection wins.
No SCALE field — use SCALE_XY (corrected vs the original draft spec).
stdout is JSON-RPC only — all server logs go to stderr.
Override the bridge port with FIGMA_MOTION_WS_PORT (default 3055; update ui.html URL to match).
Apply a Figma native animation style to a node. Returns the applied instance id.
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | ||
| nodeId | Yes | ||
| styleId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only discloses that the tool returns an 'applied instance id', leaving out side effects like mutation, permissions, error conditions, or impact on the node.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, and the action is front-loaded. It is slightly terse but appropriate for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a nested config parameter, the description is incomplete. It fails to explain the config's purpose, duration behavior, or the meaning of the returned instance id, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no information about any of the three parameters (nodeId, styleId, config). The agent gets no help understanding the config object, duration, or timelineOffset beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('apply'), the resource ('Figma native animation style'), and the target ('a node'), and it distinguishes itself from sibling tools like apply_keyframes or apply_motion_template by specifying 'native animation style'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any preconditions or exclusions mentioned. The description lacks context for the agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply raw keyframe tracks to a node (lower-level than templates). Provide one or more property tracks directly.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ||
| tracks | Yes | ||
| duration | No | Optional timeline duration in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'raw keyframe tracks' and 'lower-level', but does not disclose side effects, permissions needed, error behavior, or the fact that it is a mutation operation. The description is insufficient for understanding behavior beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and differentiation. Every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested parameters, no output schema, and no annotations. The description is too brief to cover return values, error contexts, or validation constraints (e.g., minItems, required fields). It does not mention that 'baseValue' is optional or the default type behavior. For a moderately complex tool, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%) and the description only adds 'Provide one or more property tracks directly', which clarifies that tracks can be multiple. It does not explain the significance of 'nodeId', 'duration', or the structure of 'baseValue' and 'keyframes' beyond what is in the schema. The description does not compensate adequately for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply', the resource 'raw keyframe tracks to a node', and distinguishes itself from templates by noting 'lower-level than templates'. It also specifies 'Provide one or more property tracks directly', which further clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by contrasting with templates ('lower-level'), but does not explicitly state when to use this tool versus sibling tools like 'apply_animation_style' or 'apply_motion_template'. It lacks explicit 'when to use' and 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a named motion template to a node. The server resolves template+params into keyframe tracks and applies them, optionally setting the timeline duration.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ||
| params | No | Numeric overrides, e.g. { duration: 0.5, distance: 32 } | |
| template | Yes | Template name from list_motion_templates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates the tool modifies state (applies templates) but lacks details on side effects such as overwriting existing animations, reversibility, permissions required, or default behavior when timeline duration is not set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description does not cover return values, error handling, prerequisites (e.g., node existence), or comprehensive behavioral implications, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions). The description adds examples for 'params' and references list_motion_templates for 'template', but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply), resource (motion template to a node), and the process (server resolves template+params into keyframe tracks). It distinguishes from siblings like apply_animation_style and apply_keyframes by specifying 'named motion template' and resolving parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like apply_animation_style or apply_keyframes. It lacks explicit context for appropriate usage, prerequisites, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the currently selected Figma nodes (id, name, type). Use this to obtain a nodeId before authoring motion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes the behavior: listing selection and returning id, name, type. It doesn't cover edge cases or return format, but for a straightforward read operation, it's sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and output fields, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description provides complete context: what it returns, when to use it, and how it relates to motion authoring.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter info, but the schema is fully covered. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists selected Figma nodes with id, name, and type, and explicitly ties it to obtaining a nodeId for motion authoring, distinguishing it from sibling motion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to obtain a nodeId before authoring motion, which provides clear context. It doesn't mention when not to use it, but the tool has no parameters and is simple, so this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Figma's native (Beta) animation styles available to apply: styleId, name, props.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It describes a read operation but does not mention whether it requires a specific file context, whether it returns all styles globally or per document, or any side effects. For a listing tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose and key output fields without any wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description covers the essential aspects: what it lists and what it returns. However, it lacks context about the scope (e.g., current document) and the fact that it's a Beta feature, which could affect reliability. The sibling tools offer context, but the description itself is slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%, so the baseline is 3. The description does not add parameter information (none needed) but does describe the output fields, which is useful. However, this dimension specifically concerns parameters, so no extra credit for output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Figma's native animation styles, including the returned fields (styleId, name, props). The verb 'List' and resource 'animation styles' are specific. However, it does not differentiate from the sibling tool 'list_motion_templates', which could be confused as similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'apply_animation_style' or 'list_motion_templates'. No prerequisites, context, or exclusions are mentioned. The agent is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in motion templates and their tunable params. These are code-defined (Figma has no API to publish native styles).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses that the templates are code-defined and not from Figma's API, which is useful behavioral context for an AI agent. It does not explicitly state it's read-only, but that is inherent for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that provide all necessary information without any filler. Every sentence adds value: the first states the action, the second provides important context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is complete. It explains what is listed and why these templates are special (code-defined). No additional context is needed for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. No parameter semantics are needed, and the description does not add anything beyond the schema, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists built-in motion templates and their tunable params. It distinguishes these from Figma's native styles by noting they are code-defined, which adds clarity and differentiates from sibling tools like list_figma_animation_styles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by explaining these templates are not available via Figma's API, suggesting it's the source for those definitions. However, it does not explicitly contrast with alternatives like list_figma_animation_styles or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the Motion (Beta) Plugin API is exposed in the connected Figma build. Returns apiVersion, figma.motion keys, and whether motion write methods exist on the first selected node.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values and 'first selected node' dependency, but lacks details on error cases (e.g., no selection) and side effects. Without annotations, the description carries the full burden but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Perfectly concise for a simple diagnostic tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description covers the essential behavior and return values. Lacks explicit mention of edge cases (no selection) but is adequate for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so description adds full behavioral meaning beyond schema. Baseline for 0 params is 4, and description effectively explains what the tool does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks if the Motion API is exposed and returns specific diagnostic info (apiVersion, keys, write methods). Distinguishes from sibling tools that apply or read motion, making it uniquely a probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a diagnostic check before other motion operations, but no explicit guidance on when to use vs alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current motion state of a node: timelines, animated property keys, manual keyframe tracks, and applied animation styles. Run this after applying to confirm results and to discover the real property field names for this build.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Figma node id, e.g. '12:34' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses what is read (timelines, keys, tracks, styles) and hints at read-only behavior through the verb 'read'. However, it does not detail potential errors, performance implications, or output structure, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first succinctly states purpose and components, the second provides usage advice. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is fairly complete. It lists the motion state components and gives a use case. However, it lacks details on the output format, which could help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (nodeId) already described as 'Figma node id, e.g. '12:34''. The description adds no further parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current motion state of a node, listing specific components (timelines, animated property keys, manual keyframe tracks, applied animation styles). It distinguishes from sibling tools by being a read-only verification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises running this tool after applying animations to confirm results and discover real property field names, providing a clear context for use. It does not explicitly contrast with alternatives but implies a verification role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete motion from a node. Provide fields (property names) to remove manual keyframe tracks, and/or animationStyleIds to remove applied animation style instances.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Property field names to remove, e.g. ['OPACITY','TRANSLATION_Y'] | |
| nodeId | Yes | ||
| animationStyleIds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'Delete motion' (destructive) but does not disclose side effects, permissions, reversibility, or error conditions. The behavior beyond the basic action is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the core purpose, the second provides usage details. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with three parameters and no output schema, the description covers the main action and parameter roles. It lacks mention of return values or error scenarios, but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%) but the description compensates by explaining the purpose of 'fields' and 'animationStyleIds' in context. It adds meaning beyond the bare schema, though 'nodeId' remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete motion from a node') and specifies two distinct ways to achieve it (via fields or animationStyleIds). It is a specific verb-resource pair that distinguishes from siblings like apply_keyframes or read_motion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to provide each parameter ('fields to remove manual keyframe tracks, and/or animationStyleIds to remove applied animation style instances'). It does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the duration (seconds) of the node's containing timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ||
| duration | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states that the tool sets duration, omitting any side effects, authorization needs, or return value. The write nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, but its brevity omits necessary details, making it marginally helpful. The structure is fine for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description fails to explain the effect on the timeline (e.g., truncation vs. scaling), the role of 'nodeId', or any return behavior. Incomplete for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'duration' is in seconds but does not explain 'nodeId' or provide any parameter constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('duration of the node's containing timeline'), with enough specificity to distinguish it from sibling tools like 'apply_animation_style' or 'apply_keyframes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The agent is left without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: applying motion via different methods (style, keyframes, template), reading, removing, setting duration, listing available assets, getting selection, and probing API. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., apply_animation_style, list_motion_templates). Verbs are predictable and clearly indicate the action.
With 10 tools, the set is well-scoped for a motion server. Each tool covers a necessary aspect of the motion workflow without redundancy or excess.
The tools provide comprehensive coverage for applying, reading, removing, and configuring motion, plus listing available styles/templates. A minor gap is the lack of a tool to explicitly update an existing animation, but remove+reapply works around it.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI coding agents to Anima Playground, Figma, and your design system.
The Figma MCP server brings Figma design context directly into your AI workflow.
Turn Claude into a creative studio: DNA-locked characters, images, video, voiceover — 55 tools.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/seongwoo-choi-imweb-me/figma-motion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
