Skip to main content
Glama
Sign In
Figma Edit MCP

Figma Edit MCP

by neozhehan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Bind Variable

node_bind_variable
Idempotent

Bind design tokens to Figma node properties, replacing literal values with variable references. Also set explicit variable modes for consistent theming.

Instructions

Bind a variable to a node property, or set an explicit variable mode. Use instead of a literal node_set_* when the value should track a design token. Ordering rules: set auto-layout before binding padding/spacing; set a solid fill before binding a colour token.

Input Schema

NameRequiredDescriptionDefault
nodeIdYesThe ID of the node to bind variables to
nodeNameYesThe node's current exact name, passed back verbatim from `node_info`.
bindVariablesNoMap of property names to variable IDs (to bind) or null (to unbind). Valid fields: fills, strokes, height, width, characters, itemSpacing, paddingLeft, paddingRight, paddingTop, paddingBottom, visible, topLeftRadius, topRightRadius, bottomLeftRadius, bottomRightRadius, minWidth, maxWidth, minHeight, maxHeight, counterAxisSpacing, strokeWeight, strokeTopWeight, strokeRightWeight, strokeBottomWeight, strokeLeftWeight, opacity, gridRowGap, gridColumnGap, fontFamily, fontSize, fontStyle, fontWeight, letterSpacing, lineHeight, paragraphSpacing, paragraphIndent. E.g., { 'fills': 'VariableID:1:2' }
explicitVariableModesNoMap of variable collection IDs to mode IDs. E.g., { 'VariableCollectionID:1:2': 'ModeID:1:3' }

Output Schema

NameRequiredDescriptionDefault
nameNoName of the modified node
errorNo
messageNoStatus message
successNoWhether the variables were bound successfully

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.3
    • changedInput schema / properties / nodeName / description
      Previous value: -"Name of the node to verify against"New value: +"The node's current exact name, passed back verbatim from `node_info`."
    • addedOutput schema / properties / error
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "code": {
+      "description": "Stable machine-readable failure code (see the error playbook)",
+      "type": "string"
+    },
+    "details": {
+      "description": "Optional structured context (e.g. partialMutation, before-values)"
+    },
+    "message": {
+      "description": "Human/agent-readable message embedding its own recovery",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changedv2.3.2
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +{}
  3. Changed2 schema fields changedv2.3.1
    • changedInput schema / properties / bindVariables / description
      Previous value: -"Map of property names to variable IDs (to bind) or null (to unbind). E.g., { 'fills': 'VariableID:1:2' }"New value: +"Map of property names to variable IDs (to bind) or null (to unbind). Valid fields: fills, strokes, height, width, characters, itemSpacing, paddingLeft, paddingRight, paddingTop, paddingBottom, visible, topLeftRadius, topRightRadius, bottomLeftRadius, bottomRightRadius, minWidth, maxWidth, minHeight, maxHeight, counterAxisSpacing, strokeWeight, strokeTopWeight, strokeRightWeight, strokeBottomWeight, strokeLeftWeight, opacity, gridRowGap, gridColumnGap, fontFamily, fontSize, fontStyle, fontWeight, letterSpacing, lineHeight, paragraphSpacing, paragraphIndent. E.g., { 'fills': 'VariableID:1:2' }"
    • addedInput schema / properties / bindVariables / propertyNames / enum
      Added value: +[
+  "fills",
+  "strokes",
+  "height",
+  "width",
+  "characters",
+  "itemSpacing",
+  "paddingLeft",
+  "paddingRight",
+  "paddingTop",
+  "paddingBottom",
+  "visible",
+  "topLeftRadius",
+  "topRightRadius",
+  "bottomLeftRadius",
+  "bottomRightRadius",
+  "minWidth",
+  "maxWidth",
+  "minHeight",
+  "maxHeight",
+  "counterAxisSpacing",
+  "strokeWeight",
+  "strokeTopWeight",
+  "strokeRightWeight",
+  "strokeBottomWeight",
+  "strokeLeftWeight",
+  "opacity",
+  "gridRowGap",
+  "gridColumnGap",
+  "fontFamily",
+  "fontSize",
+  "fontStyle",
+  "fontWeight",
+  "letterSpacing",
+  "lineHeight",
+  "paragraphSpacing",
+  "paragraphIndent"
+]
  4. Changed1 schema field changedv2.3.0
    • addedInput schema / additionalProperties
      Added value: +false
  5. Addedv2.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations supply idempotentHint and openWorldHint, but the description adds behavioral nuance beyond those: the design-token tracking semantic and the ordering constraints that affect outcomes. It does not contradict annotations. A slight gap is that it doesn't mention potential side effects of setting explicit variable modes, but the value added is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: functionality, usage guidance, and ordering rules. No redundancy or fluff; front-loaded with the core purpose.

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?

Given the tool's complexity (nested objects, 4 params, output schema present), the description covers purpose, usage distinction, and ordering constraints. The schema handles parameter details, and annotations handle idempotency/open-world semantics, leaving no significant gaps.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter already described in detail. The description adds a high-level reason for binding ('track a design token') but doesn't provide additional parameter-level semantics beyond what the schema already covers. Baseline 3 is appropriate.

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?

The description clearly states the tool binds a variable to a node property or sets an explicit variable mode, with a specific verb and resource. It distinguishes itself from sibling tools like node_set_fill by noting it should be used 'instead of a literal `node_set_*`' when tracking design tokens.

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?

Provides explicit guidance on when to use this tool versus alternatives: 'Use instead of a literal `node_set_*` when the value should track a design token.' It also gives ordering rules (set auto-layout before binding padding/spacing, set solid fill before binding colour token), which contextualizes usage.

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