Skip to main content
Glama
Semmargl

figma-proxy-mcp

by Semmargl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

get_figma_component

Fetch a Figma node by URL to receive pruned, tokenized IR with resolved CSS variables, a Tailwind theme, and a component registry. Call with summary:true first to decompose large frames.

Instructions

Get a Figma node by URL. Returns a deterministic, pruned + tokenized + componentized IR with a :root{} CSS-variable block, a Tailwind theme, and a component registry. Colors/spacing/fonts are already resolved to $--var references — the caller does NOT need to re-match raw RGBA against :root. For large sections, call with summary:true FIRST to get a compact { cssVars, tailwindTheme, registry, sections[] } object (top-level children with bounding boxes) WITHOUT the full node tree; this replaces manual get_figma_file decomposition. Then fetch individual sections (optionally with maxDepth) to build them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leanNoOmit the global blocks (CSS vars, Tailwind theme, component registry) that are identical on every call. Pass true on per-section fetches AFTER the summary call to avoid re-sending ~15KB of duplicated tokens/registry each time. The annotated IR still carries $--var references. Default false.
pruneNoRun the deterministic noise-pruning pass (collapse decorative wrappers, drop invisible/zero-size nodes). Default true; set false for raw IR (debug).
formatNo(non-summary) IR shape. "nested" (default) = full annotated tree. "flat" = a flat array of compact node records (render fields only, coords RELATIVE to the root frame) — much smaller and machine-readable. Use format:"flat" + lean:true for per-section fetches so you NEVER hand-read a deep multi-thousand-line tree.nested
minFreqNoMinimum occurrences for a value to become a design token during tokenization (default 2).
summaryNoWhen true, return a compact summary (component meta, CSS vars, Tailwind theme, component registry, and top-level sections with bounding boxes) instead of the full annotated IR tree. Recommended first call for large frames/sections — avoids reading a multi-thousand-line IR.
figmaUrlYesFull Figma URL to a specific node (e.g., https://www.figma.com/design/{fileId}/...?node-id={nodeId})
maxDepthNoCap the IR tree depth (e.g. 3-4) to keep a large section compact without manual decomposition. Omit for full depth.
tokenizeNoRun frequency-analysis tokenization: emit :root CSS vars + Tailwind theme and replace raw color/spacing/font values in the IR with $--var references. Default true.
componentizeNoCluster repeated nodes into a component registry with variant axes and named text styles. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.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 behavioral burden and does well: it discloses that tokens are pre-resolved to $--var references (no caller re-matching of RGBA), that lean omits ~15KB of duplicated blocks, and that prune defaults to a deterministic pass. It stops short of auth, rate limits, or error behavior, so not a 5.

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 the core purpose, then workflow and field semantics. Dense but every sentence carries information relevant to correct invocation; slightly long, but appropriate for a 9-parameter tool with non-obvious sequencing.

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 9-parameter tool with no output schema, the description documents the return shape (cssVars, tailwindTheme, registry, sections[], IR tree) and the workflow well enough to call correctly. It omits failure modes and access requirements, which keeps it just below complete.

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 real value beyond the schema by explaining parameter interaction and intent — summary-then-lean-per-section ordering, format:flat for machine-readable per-section fetches, and maxDepth as an alternative to manual decomposition. This is more than the schema's per-parameter docs provide.

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 ('Get a Figma node by URL') and precisely characterizes the output (pruned, tokenized, componentized IR with :root vars, Tailwind theme, registry). It also distinguishes itself from get_figma_file by positioning the summary mode as a replacement for manual decomposition.

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 explicit sequencing: use summary:true FIRST for large sections, then fetch individual sections with lean/format:flat/maxDepth. Names the alternative workflow (get_figma_file decomposition) and the condition that makes it unnecessary.

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