figma-mcp

update_node

Change an existing Figma node's dimensions, position, fill, image, corner radius, opacity, layout alignment, or text auto-resize settings.

Instructions

Update dimensions, coordinates, fills, images (supports local file paths), corner radius, opacity, layout alignment, or text auto-resize of an existing node

Input Schema

Name	Required	Description
`x`	No	New X coordinate
`y`	No	New Y coordinate
`fill`	No	New hex color fill (e.g. '#FFFFFF')
`name`	No	New name for the node
`image`	No	New image URL, local file path, or base64 data URI
`width`	No	New width in pixels
`height`	No	New height in pixels
`nodeId`	Yes	Target node ID
`opacity`	No	Opacity from 0 to 1
`visible`	No	Visibility boolean
`fontSize`	No	New font size in pixels
`fontFamily`	No	New font family for text nodes (e.g. 'Playfair Display', 'Inter')
`fontWeight`	No	New font weight/style for text nodes (e.g. 'Bold', 'Regular', 'SemiBold')
`layoutGrow`	No	Flex grow factor (0 or 1)
`itemSpacing`	No	AutoLayout gap between children
`layoutAlign`	No	Layout alignment in parent flex container
`cornerRadius`	No	New corner radius
`textAutoResize`	No	Text auto-resize mode
`counterAxisAlignItems`	No	Counter axis alignment for frames
`primaryAxisAlignItems`	No	Primary axis alignment for frames

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.2.0Oct 3, 2026

addedInput schema / properties / counterAxisAlignItems

Added value: +{
+  "description": "Counter axis alignment for frames",
+  "enum": [
+    "MIN",
+    "CENTER",
+    "MAX",
+    "BASELINE"
+  ],
+  "type": "string"
+}

addedInput schema / properties / fontFamily

Added value: +{
+  "description": "New font family for text nodes (e.g. 'Playfair Display', 'Inter')",
+  "type": "string"
+}

addedInput schema / properties / fontSize

Added value: +{
+  "description": "New font size in pixels",
+  "type": "number"
+}

addedInput schema / properties / fontWeight

Added value: +{
+  "description": "New font weight/style for text nodes (e.g. 'Bold', 'Regular', 'SemiBold')",
+  "type": "string"
+}

changedInput schema / properties / image / description

Previous value: -"New image URL or base64 data URI"New value: +"New image URL, local file path, or base64 data URI"

addedInput schema / properties / itemSpacing

Added value: +{
+  "description": "AutoLayout gap between children",
+  "type": "number"
+}

addedInput schema / properties / layoutAlign

Added value: +{
+  "description": "Layout alignment in parent flex container",
+  "enum": [
+    "INHERIT",
+    "STRETCH",
+    "MIN",
+    "CENTER",
+    "MAX"
+  ],
+  "type": "string"
+}

addedInput schema / properties / layoutGrow

Added value: +{
+  "description": "Flex grow factor (0 or 1)",
+  "type": "number"
+}

addedInput schema / properties / primaryAxisAlignItems

Added value: +{
+  "description": "Primary axis alignment for frames",
+  "enum": [
+    "MIN",
+    "CENTER",
+    "MAX",
+    "SPACE_BETWEEN"
+  ],
+  "type": "string"
+}

addedInput schema / properties / textAutoResize

Added value: +{
+  "description": "Text auto-resize mode",
+  "enum": [
+    "NONE",
+    "WIDTH_AND_HEIGHT",
+    "HEIGHT",
+    "TRUNCATE"
+  ],
+  "type": "string"
+}

First observedv0.1.0Sep 26, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation on an existing node but says nothing about required permissions, whether changes are reversible, what happens to properties not passed, or error behavior for invalid node IDs. The only extra nugget ('supports local file paths') is already echoed in the image schema description, so it does not compensate.

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?

A single sentence that front-loads the verb and resource, then lists property groups efficiently. The enumeration is long but each item earns its place by signaling scope; no filler or redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 20-parameter mutation tool with no annotations and no output schema, the description should disclose more: which properties are combinable, unit/format expectations beyond the schema, and what the call returns or how failures surface. As written it names what can be changed but not how the update behaves, leaving meaningful 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%, so the schema already documents all 20 parameters with types, units, enums, and examples. The description merely groups them into categories and adds nothing semantic beyond the schema, giving the expected baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a clear verb ('Update') and resource ('an existing node') and enumerates the categories of editable properties, so an agent knows exactly what the tool does. However, it does not differentiate itself from siblings that also mutate nodes (set_stroke, set_text_content, set_autolayout), so an agent must infer whether to use this broad updater or the narrower setters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool rather than an alternative. With sibling tools such as set_autolayout, set_stroke, and set_text_content covering overlapping mutations, the absence of any 'use this when... / prefer X for Y' guidance leaves the routing decision entirely 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

update_node

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools