figmcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIGMA_LOCAL_MCP_FRAMEWORK | No | Optional: flutter or react |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_design_contextA | Get design context for a Figma node — the primary tool for design-to-code workflows. Returns reference code (Flutter widgets for Flutter projects, React + Tailwind otherwise), the assets it uses, a screenshot and the variables in the node. The code must be adapted to the target project. Use the nodeId parameter to specify a node id; from a URL like https://figma.com/design/:fileKey/:fileName?node-id=1-2 the node id is 1:2. With no nodeId the current selection in Figma is used. Large nodes return metadata instead of code unless forceCode is set. |
| get_metadataA | IMPORTANT: Always prefer to use get_design_context. Get metadata for a node or page in XML format: node IDs, layer types, names, positions and sizes, useful for an overview of the structure. nodeId can be a page id (e.g. 0:1). When nodeId is omitted, returns the pages of the document (and saved snapshots) instead. When something is selected in Figma, the response starts with a "Currently selected nodes:" block. |
| get_screenshotA | Generate a screenshot for a given node or the currently selected node in Figma. maxDimension (default 1024) caps the longer edge of the PNG (up to 2x the node size). The response gives a local URL and file path plus width/height and original_width/original_height. Set enableBase64Response to also get the image inline. |
| get_variable_defsA | Get variable definitions for a given node id. E.g. {'icon/default/secondary': #949494}. Variables and styles are reusable values applied to colours, fonts, sizes and spacings. Values resolve for the node's own mode. Read-only; with no nodeId it uses the selection. Use it for design tokens, and get_design_context for the layout. Without the plugin, a saved snapshot gives the raw values only, without names. |
| download_assetsA | Download assets for a single node: an exported render ( |
| get_code_connect_mapA | Get the mapping from the component instances in a node to code components: { nodeId: { codeConnectName, codeConnectSrc, label } }, plus the components that are not mapped yet. Mappings live in the project (.figma-local/code-connect.json under the working directory). |
| add_code_connect_mapA | Map a design component to a code component, so get_design_context names the code component for every instance of it. Pass an instance, component or component set id; a component in a set maps the whole set. |
| remove_code_connect_mapA | Remove the code component mapping saved by add_code_connect_map, so get_design_context stops naming that code component. Pass an instance, component or component set id. Only the local mapping file changes, never the design; returns how many mappings were removed (0 when none existed). Add it again with add_code_connect_map to undo. |
| whoamiA | Status of the local Figma connection: whether the plugin is connected, the pairing code it needs, the open file, page and selection, the project and its Code Connect file, and the saved snapshots. Use it when a read fails. |
| import_design_exportA | Save a design export JSON (frames with node trees, as the plugin produces) as a snapshot, so its nodes can be read without the plugin. Use it for an export made earlier with save_design_export or the plugin. Copies the file into the local snapshot store, replacing an earlier snapshot of the same frames; the source file and the Figma file are not changed. Fails if the JSON is not a design export. |
| save_design_exportA | Write a full design export of a node (default: the selection) to a JSON file: the node tree with every layout, paint, text, variable, style, component and interaction detail, icon SVGs, renders of masked or rotated groups, image fills and a 2x preview. Mapped components carry their code component. Use it to hand a frame to a build script. |
| use_figmaA | Create or edit designs in the file open in Figma Desktop by running JavaScript against the Figma plugin API. Rules of the plugin API here:
Build a screen in a few calls (structure, then sections), return the ids, and check each step with get_screenshot. |
| place_imageA | Put an image file from this computer into the file open in Figma Desktop: a PNG, JPG or GIF becomes a rectangle with the image fill (or the fill of the layer |
| verify_codeA | Check Flutter code against the design: analyzes it, renders it with With |
| search_design_systemA | Search the design system of the file open in Figma Desktop: local components and component sets (with their properties and variant options), library components the file already uses (with an instance to copy), and local paint, text and effect styles and variables (with their default-mode values). Every word of |
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 15 tools
Most tools have clearly distinct purposes (editing via use_figma, reading via get_design_context/get_metadata/get_screenshot, asset download, code-connect mapping). The main overlap risk is among the read/inspect tools (get_design_context, get_metadata, get_variable_defs, get_screenshot, download_assets) and between the export/snapshot tools (save_design_export, import_design_export, download_assets), though descriptions explicitly steer usage (e.g. 'Always prefer get_design_context').
Nearly all tools follow a verb_noun snake_case pattern (get_design_context, add_code_connect_map, search_design_system, place_image, download_assets, verify_code). The lone outlier 'whoami' breaks the convention, a minor deviation in an otherwise predictable scheme.
15 tools is at the top of the well-scoped range and each maps to a distinct capability (edit, inspect, verify, assets, mappings, status). No filler tools; the count fits a design-to-code Figma integration.
The surface covers the full lifecycle: design export/snapshot (save/import), code-connect mapping (add/get/remove), reading (context, metadata, screenshot, variables, design system search), editing (use_figma, place_image), verification (verify_code), and asset download. Minor gaps exist (e.g. no dedicated snapshot listing/removal tool beyond whoami), but core workflows are covered.