Skip to main content
Glama
Sign In
figma-ui-mcp

figma-ui-mcp

by TranHoaiHung
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

figma_read

Extract node trees, styles, tokens, and screenshots from Figma to understand layouts before generating code.

Instructions

READ design data from Figma — extract node trees, colors, typography, spacing, and screenshots. Use to understand an existing design before generating code, or to inspect what's on the canvas.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>"
    },
    "name": "figma_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoTree depth for get_design/get_selection. Number (default 10) or 'full' for unlimited. Higher = more detail but larger output.
scaleNoExport scale for screenshot (default 1).
detailNoDetail level for get_design/get_selection: 'minimal' (~5% tokens), 'compact' (~30%), 'full' (default, 100%). Use minimal for large files.
formatNoImage format for export_image: 'png' (default) or 'jpg'.
nodeIdNoTarget node ID (optional — omit to use current selection).
nodeNameNoTarget node name (alternative to nodeId).
operationYes── Design-to-code (use these for code generation) ── get_design_context: AI-optimized payload for a node — flex layout, token-resolved colors, typography with style names, component instances with variant properties. Best single call for design→React/Vue/Swift code. get_css: ready-to-use CSS string for a single node — background, flex, border, radius, shadow, typography, opacity, transform. get_component_map: list every component instance in a frame with componentSetName, variantLabel, properties, and suggestedImport path. Use to scaffold import statements. get_unmapped_components: find component instances that have no description in Figma (likely no code mapping yet). Prompts AI to ask user for correct import paths. ── Inspect ── get_node_detail: structured properties for a single node — fills, bound variables (resolved to name+value), style refs (resolved to name+hex), instance overrides (full field list), componentSetName/variantLabel. get_selection: full design tree of selected node(s) + design tokens summary. get_design: full node tree for a frame/page (depth param: number or 'full'). get_page_nodes: top-level frames on the current page. ── Styles & tokens ── get_styles: all local paint, text, effect, grid styles. get_variables: all local Design Token variables — collections, modes, resolved values. get_local_components: component listing with descriptions + variant property definitions. ── Export ── screenshot: PNG of a node — displays inline in Claude Code. export_svg: SVG markup string. export_image: base64 PNG/JPG for saving to disk (scale param for resolution). ── Search ── search_nodes: filter by type, namePattern (wildcard *), fill color, fontFamily, fontSize, hasImage, hasIcon. scan_design: structured summary of large frames — all text, colors, fonts, images, icons, sections. ── Viewport ── get_viewport: current viewport center, zoom, bounds.
sessionIdNoTarget a specific Figma file/tab when multiple are connected. Omit to auto-select.
includeHiddenNoInclude invisible nodes (visible:false) in results. Default false — hidden layers are skipped to reduce noise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.5.26

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must carry full burden. It states it reads data but does not disclose specific behaviors such as rate limits, authentication requirements, or side effects. The operation parameter's enum descriptions provide some behavioral context per sub-operation, but the main description is insufficient.

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 description is concise with two sentences, no wasted words. Front-loads the action ('READ design data'). Could benefit from bullet points or structure, but remains efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, 17 operations, no output schema), the description is incomplete. It doesn't explain return values or output format. The operation enum fills some gaps, but the main description could provide a high-level overview of what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The main description does not add meaning beyond the schema descriptions. The operation parameter has extensive inline descriptions, but that is part of the schema. The description adds marginal value over structured fields.

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?

The description clearly states the tool reads design data from Figma and lists specific extractable elements (node trees, colors, etc.). It distinguishes itself from sibling tools like figma_write (write operations) and figma_docs (documentation).

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?

The description provides clear usage context: 'understand an existing design before generating code, or to inspect what's on the canvas.' It doesn't explicitly state when not to use, but the sibling tools cover other cases, making the intent clear.

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