Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Set constraints

figma_set_constraints
Idempotent

Responsive constraints: how nodes follow their parent frame when it resizes. horizontal: left, right, center, left-right, scale; vertical: top, bottom, center, top-bottom, scale (Figma's MIN/MAX/CENTER/STRETCH/SCALE also accepted).

Instructions

Responsive constraints: how nodes follow their parent frame when it resizes. horizontal: left, right, center, left-right, scale; vertical: top, bottom, center, top-bottom, scale (Figma's MIN/MAX/CENTER/STRETCH/SCALE also accepted). Omit one axis to keep it. Children of an auto-layout frame are positioned by the layout instead. 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.
nodeIdsYes
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
verticalNo
horizontalNo
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.2/5.0
Behavior4/5

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

Beyond the annotations, the description explicitly details the return behavior, stating that results are per-item and that a single node failing does not cause the entire call to fail. This level of operational detail is highly valuable behavioral context for an agent.

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?

The description is highly dense and efficient, grouping functional definitions, accepted values, and edge case behavior into a coherent block. The structure flows logically from definition to detail to execution.

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?

The definition is extremely complete. It covers the 'what' (constraints), the 'how' (accepted values/syntax), the 'why' (interaction with auto-layout), and the 'what if' (per-item success/failure reporting), providing everything an agent needs to select and call the tool correctly.

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?

While the tool schema handles the parameter structure, the description is critical for defining the semantics of the `vertical` and `horizontal` parameters by listing the accepted values (e.g., 'left', 'scale', 'center'). This domain-specific knowledge is essential for correct invocation, but since the parameter definitions themselves are in the schema, it receives a 3.

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's purpose: setting responsive constraints on Figma nodes. It provides necessary context regarding what these constraints achieve when a parent frame resizes, clearly distinguishing its function from general node editing.

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?

It offers specific usage guidance by detailing how to manage axes (omitting one to keep it) and provides an important behavioral note regarding auto-layout children, which are positioned by the layout instead of constraints. This preemptively guides the user's logic.

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