Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update style

figma_update_style
Idempotent

Change a local style IN PLACE — every node using it follows; deleting and recreating would detach them all. By styleId or styleName (+ type when a name is shared). Any kind: name, description.

Instructions

Change a local style IN PLACE — every node using it follows; deleting and recreating would detach them all. By styleId or styleName (+ type when a name is shared). Any kind: name, description. Paint: color or fills, with opacity; opacity alone fades every paint and keeps bound colours. A gradient style's angle is exact only on a square node — a style has no size; for an exact CSS angle on a known node use figma_set_fills, or give transform. Text: font, size, line height, letter spacing, case, decoration, paragraph spacing/indent. Effect: effects. Grid: grids. variables binds tokens inside the style: text fields by name (fontSize, fontFamily…), a paint's "color", "effect.color" / "effect.radius" …, "grid.count" …, with index for the entry. A field that does not fit the style's kind, and a library style, are refused before anything changes. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
caseNo
nameNoRename the style.
typeNoOnly to tell same-named styles apart.
colorNoA solid colour. Give this or `fills`.
fillsNoSeveral paints or a gradient, entries as in figma_set_fills.
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.
gridsNoReplaces the grids; entries as in figma_set_layout_grids.
weightNoFont weight as a number ("600") or a Figma style name ("Semi Bold" — Inter uses spaces, not "SemiBold").
effectsNoReplaces the effects; entries as in figma_set_effects.
opacityNo
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
styleIdNoA style id from figma_get_styles.
fontSizeNo
styleNameNoOr its exact name, e.g. "Heading/H1".
variablesNo
decorationNo
fontFamilyNoDefault Inter (create); the style's own family (update).
lineHeightNo"auto", px ("32") or percent ("150%"). A string, not a number.
descriptionNoWhat the style is for — shown in Figma's style picker.
letterSpacingNopx ("0.5") or percent ("-2%"). A string, not a number.
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.
paragraphIndentNopx of first-line indent.
paragraphSpacingNopx between paragraphs.

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.5/5.0
Behavior4/5

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

Annotations already declare it is a non-readonly, non-destructive, idempotent mutation. The description adds meaningful behavior: updates propagate to every node using the style, invalid kind mismatches and library styles are refused before changes, and editor support is Design with FigJam/Slides unverified.

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 dense but front-loads the core update-in-place concept before covering kind-specific fields. It is appropriately sized for a 23-parameter tool, though the long semicolon-heavy paragraph makes some details harder to scan than a structured layout would.

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

Completeness4/5

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

For a complex style-update mutation with no output schema, the description covers the essential semantics: in-place propagation, style lookup, kind-specific fields, variable bindings, gradient constraints, and refusal cases. Some schema-documented operational parameters such as `force`, `session`, and `idempotencyKey` are not discussed in the description, but the schema covers them.

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 78% schema coverage, the schema already documents many parameters. The description still adds substantial meaning by grouping parameters by style kind (paint, text, effect, grid), explaining the `styleId`/`styleName`+`type` lookup, `opacity` behavior, gradient angle caveat, and how `variables` binds fields with an optional `index`.

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 and resource: change a local style in place so every node using it follows. It also distinguishes this from delete/recreate behavior and from figma_set_fills for the exact-angle-on-node case.

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?

Explains when to use it (in-place updates to an existing local style) and gives explicit alternatives: use figma_set_fills when an exact CSS angle is needed on a known node, or provide `transform`. It also notes that library styles and fields of the wrong kind are refused.

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