figma-proxy-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIGMA_API_KEY | Yes | Your Figma personal access token (starts with figd_), required to authenticate with the Figma REST API. Can be set in .env, the MCP client's env block, or the shell. | |
| FIGMA_FILE_DEPTH | No | Optional depth for file tree traversal. Defaults to 4. | 4 |
| FIGMA_NODE_DEPTH | No | Optional depth for node traversal. Defaults to 12. | 12 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_figma_fileC | Get Figma file data by file ID and transform it for development |
| get_figma_componentA | 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. |
| export_svgC | Export a specific Figma node as SVG and optionally save it |
| render_node_pngB | Export a specific Figma node as PNG and return base64-encoded image data |
| migrate_all_svgsC | Automatically find and export all SVG icons from a Figma file |
| get_cached_componentsB | Get previously fetched Figma components data |
| get_component_by_nameB | Get a specific Figma component by name from cached data |
| list_svg_cacheB | List all cached SVG exports |
| verify_renderA | Visual verification (MEASUREMENT ONLY): render an HTML file with headless Chromium INSIDE this server (does NOT use the user's Chrome / Control_Chrome) and compare it to the Figma design PNG. Returns SSIM (0-1, higher = closer), pixel-diff %, and clustered diff regions (bounding boxes of disagreement, in logical px). Provide the reference PNG via figmaUrl (auto-fetched), figmaPngPath, or figmaPngBase64. Use after generating HTML to objectively check fidelity, then fix only the reported regions — this tool never changes code. Requires |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools are clearly distinct by resource and action, such as export_svg vs render_node_png and migrate_all_svgs vs export_svg. The main overlap is between get_figma_file and get_figma_component, though get_figma_component's detailed description and summary-first workflow help clarify its role. Cache tools are also differentiated by whether they list or retrieve by name.
All tool names use consistent snake_case and follow a predictable verb_noun pattern such as list_svg_cache, get_figma_file, export_svg, and verify_render. There are no mixed conventions or confusing abbreviations.
Nine tools is well within the ideal range and each tool appears to serve a distinct purpose in the Figma proxy workflow. The set is neither bloated nor too thin for fetching, exporting, caching, and verifying Figma assets.
The surface covers core workflows: fetching files/components, exporting SVG/PNG, migrating SVGs, using cached components, and verifying renders. Minor gaps exist, such as no explicit cache invalidation or Figma write operations, but these may be outside the server's read-only proxy scope.