Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create variable collection

figma_create_variable_collection
Idempotent

A new variable collection (a token group). Its first mode is named after modes[0], or "Default" — never Figma's "Mode 1".

Instructions

A new variable collection (a token group). Its first mode is named after modes[0], or "Default" — never Figma's "Mode 1". Extra modes beyond the first are paid-plan only — if Figma refuses one, the result carries a warnings entry rather than dropping it silently. Rename or remove modes later with figma_update_variable_collection. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
nameYes
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.
modesNoMode names, first is the default. Default ["Default"].
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
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
Behavior5/5

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

With no output schema, the description carries the return-value burden and does: it discloses that a refused mode surfaces as a `warnings` entry instead of a silent drop — exactly the partial-success semantics an agent needs. It also documents the first-mode naming rule (never 'Mode 1') and the editor surface (Design; unverified FigJam, Slides), which goes meaningfully beyond the idempotent/non-destructive annotations.

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?

Four dense sentences, each carrying distinct information (naming, plan limits, follow-up tool, editor availability) with no filler. The opening fragment lacks its verb, which makes the front-load slightly weaker than it could be.

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 non-destructive, idempotent creation tool with no output schema and 80% parameter coverage, the description supplies the missing result-contract detail (warnings) and platform reach. It stops short of describing the returned collection identifier/shape or duplicate-name behavior, which an agent would still need to infer.

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?

Schema coverage is 80%, so the bar is baseline-3, and the description earns above it by explaining the `modes[0]` default-name rule and the paid-plan ceiling on extra modes, which the schema's 'first is the default' note does not convey. The `name` parameter is undocumented anywhere, but it is self-evident.

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?

It establishes the resource precisely by glossing 'variable collection' as a token group and describes the mode-naming behavior, which no sibling does. The verb is only implied — the sentence is a fragment ('A new variable collection...') rather than 'Creates...' — but combined with the title and the pointer to figma_update_variable_collection, an agent can tell it apart from figma_create_variable, figma_create_variables, and figma_add_variable_mode.

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 gives concrete usage context: extra modes beyond the first are paid-plan only, so multi-mode creation may partially fail, and later mode changes belong to figma_update_variable_collection. It does not explicitly contrast with figma_add_variable_mode or figma_create_variables for bulk creation, so the alternative routing is only partly covered.

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