Skip to main content
Glama
southleft

figma-console-mcp

by southleft

figma_export_tokens

Exports Figma variables to design token files for CSS, Tailwind, SCSS, TypeScript, JSON, and Tokens Studio, supporting config-driven sync with your codebase.

Instructions

Export Figma variables to design token files in your codebase. Bidirectional with figma_import_tokens — together they replace Style Dictionary and Tokens Studio's export pipeline for the popular styling methods.

FULLY-IMPLEMENTED OUTPUT FORMATS: • dtcg — W3C DTCG JSON. Canonical pivot format. Round-trip safe via $extensions["figma-console-mcp"]. • css-vars — CSS custom properties with mode-aware selectors (:root, .dark, [data-theme=...]). • tailwind-v4 — Tailwind v4 @theme inline block. Token-to-namespace mapping (color/, spacing/, radius/*, etc.) generates Tailwind utility classes. • tailwind-v3 — tailwind.config.js theme.extend object grouped under Tailwind's theme keys (colors, spacing, fontFamily, etc.). • scss — $var: value; declarations. Multi-mode emits a primary variable + a mode-keyed SCSS map for runtime access. • ts-module — export const tokens = { ... } as const with derived Tokens type. Multi-mode tokens emit as { Light: ..., Dark: ... } objects. • json-flat — flat key-value JSON ({"ds-color-primary": "#4085F2"}) for custom build scripts. • json-nested — nested object JSON mirroring the token path tree. • style-dictionary-v3 — SD v3 source format with bare value/type keys (back-compat for existing SD users). • tokens-studio — Tokens Studio multi-file layout ($themes.json + $metadata.json + per-set files). Preserves Figma collection/mode bindings for round-trip with the TS plugin.

ZERO-ARG USAGE: With a tokens.config.json at your project root, just call the tool with no args — it picks up source dir, output formats, modes, prefix, etc. from config. See the response's suggestedScaffold payload when no config is detected — present it to the user, write the scaffold via your file tools, then call again.

WRITE SAFETY: Export REPLACES the contents of each target file with the current Figma state — it does not merge into it. Under the default strategy: "merge" the tool refuses to write (and changes nothing) when overwriting an existing DTCG file would delete tokens it does not manage: tokens added by hand, or tokens from collections outside this export. It also refuses when a requested collectionId is not in the file it read, or when the export is empty — both usually mean a different file is active in Figma than you intended. Variables deleted in Figma are removed from the file as normal. Use dry-run to preview, replace to overwrite unconditionally. Generated files record the Figma file they came from (a Source: Figma file <key> header line; figmaFileKey in DTCG), and the default strategy also refuses to overwrite a file that was generated from a DIFFERENT Figma file. Plain-JSON formats (json-flat, json-nested, style-dictionary-v3, tokens-studio) cannot carry that record — pin figmaFile in tokens.config.json for a hard guarantee. Every response includes source (the Figma file name/key the data was read from) — check it.

DTCG DIALECT (dtcgDialect, applies to dtcg/json-flat/json-nested outputs): legacy (default): hex-string colors, maximum compatibility (Style Dictionary v4, Tokens Studio). 2025: DTCG 2025.10 object colors/dimensions (Style Dictionary v5+). figma_import_tokens accepts BOTH dialects regardless of this setting.

ROUND-TRIP SAFETY: Figma variable IDs are preserved in DTCG $extensions["figma-console-mcp"] so renames on either side don't create duplicates. The same metadata enables non-destructive incremental sync via figma_import_tokens. Variable scopes (when non-default) and per-platform codeSyntax (when set) are stashed there too and round-trip through import.

Input Schema

NameRequiredDescriptionDefault
modesNoModes to include in the output. 'all' (default) exports every mode in every collection. Pass an array like ['Light', 'Dark'] to filter.
scopeNoWhether to export the entire file's variables ('file', default) or just specific collections via collectionIds.
formatNoSpecific output format to emit. When omitted, formats come from tokens.config.json's generated.formats list. Common starting choices: 'dtcg' for the canonical JSON, 'css-vars' for runtime CSS custom properties, 'tailwind-v4' for Tailwind v4 @theme blocks.
prefixNoPrefix prepended to every output token name (e.g. 'ds-', 'al-'). Only affects formatters that emit named tokens — DTCG and JSON outputs use unmodified paths.
remBaseNoBase font size in pixels for px→rem conversion. Default: 16.
sizeUnitNoUnit for dimension tokens. Default: 'rem' for web outputs, 'pt' for iOS, 'dp' for Android.
strategyNoHow to handle existing output files. Export always replaces a target file's contents with the current Figma state — it does not merge token-by-token. 'merge' (default) is the SAFE mode: it refuses to write, leaving the file untouched, if overwriting an existing DTCG file would delete tokens the export does not manage (hand-added tokens, or tokens from collections not included in this export). 'replace' overwrites unconditionally. 'dry-run' reports what would be written without writing.
configPathNoExplicit path to a tokens.config.json file. When omitted, the tool walks up from cwd looking for one — typical case is zero-arg.
outputPathNoWhere to write the output. Treated as a DIRECTORY by default — each generated file (e.g. tokens.tokens.json, tokens.css) is written inside it and the directory is created if missing. Treated as a FILE when it is an existing file or ends in a token-file extension (.json, .css, .scss, .less, .ts, .js): the export must then produce exactly ONE file (one format, no splitByMode/splitByCollection — combine with collectionIds to re-export a single collection into e.g. typography.tokens.json), which is written at exactly that path, overwriting it. A file path combined with a multi-file export is rejected with an explanatory error before anything is written. End the path with '/' to force directory handling. Relative paths resolve against the project root (the directory containing tokens.config.json) or cwd if no config. When omitted, the output is returned inline in the response (suitable for the AI to inspect or write via its own file tools).
colorFormatNoColor value format in the output. Default: 'hex'. Use 'oklch' for modern Tailwind v4 charts.
dtcgDialectNoDTCG dialect for dtcg/json-flat/json-nested outputs. legacy (default): hex-string colors, maximum compatibility (Style Dictionary v4, Tokens Studio). 2025: DTCG 2025.10 object colors/dimensions (Style Dictionary v5+). Other formats (css-vars, scss, tailwind, ts-module) render final code and ignore this option.
splitByModeNoEmit one file per mode (e.g. tokens-light.css, tokens-dark.css). Default false (single file with all modes).
collectionIdsNoSpecific Figma collection IDs to export. Required when scope is 'collection'. Use figma_get_variables to enumerate available collections.
resolveAliasesNoIf true, alias references are resolved to literal values in the output. Default is false for JSON formats (preserves alias semantics) and true for CSS/SCSS/Tailwind/etc. (which can't natively express aliases).
splitByCollectionNoEmit one file per Figma collection. Default false. Useful when collections map to different runtime themes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses that export REPLACES file contents rather than merging, enumerates the exact refusal conditions (unmanaged tokens, unknown collectionId, empty export, mismatched source Figma file), and notes that Figma-deleted variables are removed. It also explains the source-stamping mechanism and its limitation for plain-JSON formats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and write-safety are front-loaded well, but the ten-bullet format catalog occupies a large share of the text and largely expands values already enumerated in the schema. The ROUND-TRIP SAFETY paragraph repeats ground already covered under DTCG and dialect, so the definition is longer than an agent needs to make the call.

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?

For a 15-parameter, zero-required, config-driven tool with no output schema, the description covers the gaps that matter: zero-arg resolution, the suggestedScaffold response payload, the `source` field in every response, and the full failure/refusal surface. An agent knows what the call returns and what it must check after it.

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 100%, so the baseline is 3, but the description adds beyond the schema: the strategy semantics are elaborated with consequence-level detail, dtcgDialect is scoped to which outputs it affects and which consumer versions it targets, and outputPath directory-vs-file rules are restated with the rejection behavior. The format bullets also explain what each enum value actually emits.

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?

Opens with a specific verb+resource ('Export Figma variables to design token files') and immediately positions itself against siblings: figma_import_tokens is called out as the reverse direction, and figma_get_variables is named for enumeration. An agent can tell this apart from figma_get_token_values or figma_ds_extract_tokens without opening a schema.

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?

Gives concrete when-to-use guidance: zero-arg mode when tokens.config.json exists, the scaffold flow when no config is detected, dry-run to preview and replace to overwrite unconditionally. It does not explicitly say when to prefer this over figma_get_token_values or figma_ds_extract_tokens, so routing among the read-side siblings is left implicit.

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