Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create variable

figma_create_variable
Idempotent

One design token. value is a string for every type: "#1a2b3c" for COLOR, "16" for FLOAT, text for STRING, "true"/"false" for BOOLEAN, or "alias:" of the same type.

Instructions

One design token. value is a string for every type: "#1a2b3c" for COLOR, "16" for FLOAT, text for STRING, "true"/"false" for BOOLEAN, or "alias:" of the same type. Set scopes (which pickers offer it; [] for a primitive only aliased) and a WEB codeSyntax on every token. A name the collection already has is refused. For a whole token set in one call use figma_create_variables. Bind one to nodes with figma_bind_variable_to_node; extra modes (figma_add_variable_mode) need a paid plan. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
nameYes
typeYes
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.
valueYesThe value for the declared type: "#1a2b3c" for COLOR, "16" for FLOAT, "Inter" for STRING, "true" for BOOLEAN.
modeIdNoMode id or name. Defaults to the collection's first mode.
scopesNoWhich property pickers offer it. [] hides a primitive that is only aliased; semantic tokens name their fields, e.g. ["FRAME_FILL","SHAPE_FILL"] or ["GAP"]. Checked against the type; ALL_SCOPES stands alone. Default (omitted): Figma's ALL_SCOPES.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
codeSyntaxNoThe name in code per platform, e.g. { "WEB": "var(--color-bg-brand)" }. "" removes that platform.
descriptionNo
collectionIdYes
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.
hiddenFromPublishingNoHide it when the file is published as a library.

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 (readOnly=false, idempotent=true, destructive=false), the description discloses that duplicate names are refused, that extra modes require a paid plan, and where the tool is verified versus unverified at the editor level. It does not say what comes back (e.g. the new variable id needed for later aliasing/binding), which is the main remaining behavioral gap.

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 passage is dense and front-loads the value encoding, then scopes/codeSyntax guidance, then sibling routing. The telegraphic, fragment-heavy style ('A name the collection already has is refused.') is efficient but slightly harder to parse than flowing prose, so not a full 5.

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 12-parameter mutation with no output schema, the description covers the highest-risk semantics (value encoding, aliasing, scopes, duplicate refusal, editor support) and the schema documents most remaining parameters. The absence of any statement about the return value—important since aliasing another token requires the new variable's id—is the notable omission.

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 67% schema coverage, the description adds real meaning: it explains that `value` is always a string per type and introduces the 'alias:<variable name or id>' syntax not documented in the schema, plus the `scopes` convention of [] for an aliased-only primitive. It repeats some schema text for `value` and leaves `force`, `modeId`, `session`, and `idempotencyKey` entirely to their schema descriptions.

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?

The description opens with 'One design token' and details the exact value encodings, making it clear this creates a single variable/token, and it explicitly contrasts with figma_create_variables for bulk creation and figma_bind_variable_to_node for binding. The core verb is only implied by the name, not stated in prose, which keeps it just shy of a 5.

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?

It gives explicit routing: use figma_create_variables for a whole token set in one call, figma_bind_variable_to_node to attach one to nodes, and figma_add_variable_mode for extra modes (noting the paid-plan requirement). It also states a constraint (duplicate names in the collection are refused) and platform availability (Design editors; unverified in FigJam/Slides), leaving little ambiguity about when this is the right call.

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