Skip to main content
Glama
neozhehan

Figma Edit MCP

by neozhehan

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

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the modified node
errorNo
messageNoStatus message
successNoWhether the variables were bound successfully
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/neozhehan/figma-edit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server