Skip to main content
Glama

Resize nodes

figma_resize_nodes
Idempotent

Resize nodes, or change how they size (Figma's fixed / hug / fill). Give width and/or height; the other dimension is kept — a text given only a width wraps and grows downwards.

Instructions

Resize nodes, or change how they size (Figma's fixed / hug / fill). Give width and/or height; the other dimension is kept — a text given only a width wraps and grows downwards. sizing: { horizontal: "fill" } makes a node take its auto-layout parent's width (the fix for text that overflows). min/max limits bound a hug or fill size — a fill paragraph with maxWidth 480 stays readable — on auto-layout frames and their direct children; clearLimits removes them. A node whose size is not its own — a sticky, a table, a connector, a code block, a 1920×1080 slide — is refused per item with the tool that sizes it. Returns per-item results: items: [{ id, ok, error? }] — one node failing does not fail the call. 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.
widthNo
heightNo
sizingNoHow it sizes, as in Figma's panel: { "horizontal": "fill" } to take the parent column's width; "hug" fits content; "fixed" keeps the number.
nodeIdsYes
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
maxWidthNo
minWidthNo
maxHeightNo
minHeightNo
clearLimitsNoLimits to remove.
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.6/5.0
Behavior5/5

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

Goes well beyond the annotations (which only cover read-only/idempotent/destructive flags) by disclosing partial-failure semantics — 'one node failing does not fail the call' — plus the per-item result shape and editor coverage (Design supported, FigJam/Slides unverified). The refusal behavior for non-owned sizes is exactly the kind of surprise an agent needs warned about before calling.

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-loaded with the core action, then progressively narrower detail; nearly every clause carries actionable information (wrap behavior, overflow fix, limit scope, refused types, return shape). It is dense to the point of being a wall of text, with example-heavy asides that could be tightened slightly.

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?

Complete for a 12-parameter batch mutation with a nested object and no output schema: the description supplies the return shape (`items: [{ id, ok, error? }]`), the failure model, environment support, and the scope caveat on limits. An agent can call this correctly without opening anything else.

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?

With 12 parameters and only 42% schema description coverage, the description carries real weight: it defines the interaction between width and height, explains the `sizing` enum values in Figma-panel terms with a worked fill example, and clarifies the min/max limit semantics and their scope restriction. It does not address `force`, `session`, or `idempotencyKey`, though those do carry their own schema descriptions.

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 plus resource and immediately widens the scope correctly: 'Resize nodes, or change how they size (Figma's fixed / hug / fill)'. This distinguishes it from siblings like figma_move_nodes, figma_set_auto_layout, and figma_set_constraints, which could otherwise be confused with resizing.

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

Usage Guidelines4/5

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

Gives concrete when-to-use context: omit one dimension to keep it, width-only on text wraps downward, `sizing: {horizontal: "fill"}` is framed as 'the fix for text that overflows', and min/max only bound auto-layout frames and their direct children. It also states a when-not: nodes whose size is not their own (sticky, table, connector, code block, slide) are refused. The gap is that the alternative tools for those refused types are described rather than named.

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