Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create paint style

figma_create_paint_style
Idempotent

A local PAINT style: one color, or fills (several paints, gradients — entries as in figma_set_fills). variableId / variableName binds the first paint's colour to a COLOR variable, so a semantic colour style follows its token.

Instructions

A local PAINT style: one color, or fills (several paints, gradients — entries as in figma_set_fills). variableId / variableName binds the first paint's colour to a COLOR variable, so a semantic colour style follows its token. Change it later in place with figma_update_style. 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. Editors: Design only.

Input Schema

NameRequiredDescriptionDefault
nameYes
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.
opacityNo
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
variableIdNoBind the first paint's colour to this COLOR variable.
descriptionNoWhat the style is for — shown in Figma's style picker.
variableNameNoOr the variable's full name, e.g. "color/bg/brand".
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.5/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the Design-only editor scope, the fact that a style has no size (so gradient angles are only exact on square nodes, with the 135→~163 on 1280×400 example), and that `variableId`/`variableName` binds the first paint's colour so the style tracks a token. Annotations already cover safety (destructiveHint=false, idempotentHint=true), so remaining gaps like return shape are minor.

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 and dense — the core shape (color or fills, variable binding) comes first, then the gradient-angle caveat and the editor scope. Telegraphic fragments ('A local PAINT style: one `color`, or `fills`...') are efficient rather than confusing, though the angle caveat is lengthy relative to its importance.

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 10-parameter create-mutation with no output schema, the description covers mode selection, variable binding, editor scope, and the trickiest edge case (gradient angle on sizeless styles). It does not address name-collision behavior or what is returned on success, leaving the agent to infer the latter from the absence of an output schema.

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 80% schema coverage the baseline is 3, and the description adds real meaning on top: how `variableId`/`variableName` bind the first paint, that `fills` entries follow figma_set_fills conventions, and the exactness caveat for gradient `angle`. It does not cover `force`, `session`, or `idempotencyKey`, but those are documented in the schema.

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 ('A local PAINT style') and enumerates the two construction modes ('one `color`, or `fills`'). It implicitly but clearly separates itself from figma_create_text_style/figma_create_effect_style by naming the style type, and from figma_set_fills by clarifying that this creates a reusable style rather than node fills.

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?

Explicitly routes the agent elsewhere in two situations: 'Change it later in place with figma_update_style' and 'for an exact CSS angle on a known node use figma_set_fills, or give `transform`.' It also names the editor restriction ('Editors: Design only') so the agent knows when this tool is not applicable at all.

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