Skip to main content
Glama
southleft

figma-console-mcp

by southleft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

figma_get_variables

Extract design tokens and variables from Figma files with multi-mode support and code exports (CSS, Tailwind, TypeScript, Sass). Ideal for retrieving colors, spacing, and theme data.

Instructions

Extract design tokens and variables from a Figma file with code export support (CSS, Tailwind, TypeScript, Sass). Use when user asks for: design system tokens, variables, color/spacing values, theme data, or code exports. Handles multi-mode variables (Light/Dark themes). NOT for component metadata (use figma_get_component). Returns a compact summary by default — pass format='full' for the complete dataset or format='filtered' with collection/namePattern/mode filters for specific variables. Supports verbosity control to prevent token exhaustion. Resolution order: Desktop Bridge plugin (works on any plan) → Variables REST API (Enterprise only) → Styles API as a partial fallback. TIP: For full design system extraction (tokens + components + styles combined), prefer figma_get_design_system_kit instead — it returns everything in one optimized call.

Input Schema

NameRequiredDescriptionDefault
modeNoFilter variables by mode name or ID. Only returns variables that have values for this mode. Only applies when format='filtered'. Example: 'Light' or 'Dark'
pageNoPage number for paginated results (1-based, default 1). Applies to format='filtered' (always paginated, 50 per page by default) and to format='full' when page or pageSize is given. Use when the response is too large.
enrichNoSet to true when user asks for: CSS/Sass/Tailwind exports, code examples, design tokens, usage information, dependencies, or any export format. Adds resolved values, dependency graphs, and usage analysis. Default: false
formatNoResponse format: 'summary' (~2K tokens with overview and names only), 'filtered' (apply collection/name/mode filters), 'full' (complete dataset from cache or fetch). Default: summary (token-efficient). When format is omitted, filter params (collection/namePattern/mode) auto-select 'filtered', and enrichment/export/resolveAliases/returnAsLinks params auto-select 'full'. Full format returns all data but may be auto-summarized if >25K tokens.
fileUrlNoFigma file URL (e.g., https://figma.com/design/abc123). Auto-detected from WebSocket Desktop Bridge connection. Only required if not connected.
pageSizeNoNumber of variables per page (1-100, default 50). Giving page or pageSize with format='full' paginates the full dataset; the response then includes a `pagination` object.
verbosityNoControls payload size: 'inventory' (names/IDs only, ~95% smaller, use with filtered), 'summary' (names/values only, ~80% smaller), 'standard' (essential properties, ~45% smaller), 'full' (everything). Default: standardstandard
collectionNoFilter variables by collection name or ID. Case-insensitive substring match. Only applies when format='filtered'. Example: 'Primitives' or 'VariableCollectionId:123'
namePatternNoFilter variables by name using regex pattern or substring. Case-insensitive. Only applies when format='filtered'. Example: 'color/brand' or '^typography'
refreshCacheNoForce refresh cache by fetching fresh data from Figma. Use when data may have changed since last fetch. Default: false (use cached data if available and fresh)
include_usageNoInclude usage in styles and components (requires enrich=true)
returnAsLinksNoReturn variables as resource_link references instead of full data. Drastically reduces payload size (100+ variables = ~20KB vs >1MB). Recommended for large variable sets — combine with format='filtered' + namePattern/collection/mode to fetch only the variables you need. Default: false
export_formatsNoWhich code formats to generate examples for. Use when user mentions specific formats like 'CSS', 'Tailwind', 'SCSS', 'TypeScript', etc. Automatically enables enrichment.
resolveAliasesNoAutomatically resolve variable aliases to their final values (hex colors, numbers, etc.). When true, each variable will include a 'resolvedValuesByMode' field with the actual values instead of just alias references. Useful for getting color hex values without manual resolution. Default: false.
include_exportsNoInclude export format examples (requires enrich=true)
includePublishedNoInclude published variables from libraries
parseFromConsoleNoDEPRECATED — setting this to true now raises an explicit error. The Puppeteer-based console parser no longer exists. Open the Figma Console MCP Desktop Bridge plugin in Figma Desktop and call figma_get_variables() without parseFromConsole; the plugin returns full variable data through the WebSocket bridge.
useConsoleFallbackNoDEPRECATED — has no effect. The console-snippet workflow was removed in the Phase 3 CDP cleanup; the Desktop Bridge plugin now handles all non-REST variable extraction automatically. Kept for parameter compatibility only — safe to ignore.
include_dependenciesNoInclude variable dependency graph (requires enrich=true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4.5/5.0
Behavior4/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 well: it discloses the resolution order (Desktop Bridge → Enterprise-only REST API → Styles API partial fallback), that the default response is a compact summary to avoid token exhaustion, that full output may be auto-summarized above 25K tokens, and that parseFromConsole now raises an error. Remaining gap: no explicit statement about permissions needed beyond plan tier, or what a partial Styles-API fallback actually omits.

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 with purpose and usage triggers, then falls through to output sizing, resolution order and the sibling tip. Dense and mostly waste-free, but the deprecation/fallback sentences and the resolution-order chain make it longer than a typical selector needs; a short 'see schema for param details' would trim it.

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 19-parameter, zero-annotation, no-output-schema tool this covers the essentials: what comes back by default, how to get more, how to filter, and which backend serves the request. It stops short of describing the returned object shape or what the Styles-API fallback degrades, which an agent would need to interpret a partial result.

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 and the schema already documents every parameter including the format/verbosity enums. The description still adds decision-level framing ('Returns a compact summary by default — pass format='full' … or format='filtered' with collection/namePattern/mode filters') that tells an agent which knobs matter without reading the schema. It does not add much beyond that, so it stops short of a 5.

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+resource ('Extract design tokens and variables from a Figma file') plus the code-export capability. It explicitly names what it is not ('NOT for component metadata (use figma_get_component)') and points to a better sibling for the combined case, so an agent can separate it from figma_get_component, figma_get_token_values and figma_get_design_system_kit without opening schemas.

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?

Gives concrete trigger phrases ('design system tokens, variables, color/spacing values, theme data, or code exports'), an explicit exclusion with the alternative to use instead, and a TIP redirecting to figma_get_design_system_kit for full extraction. When-to-use, when-not-to-use and alternatives are all present.

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