Figma MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FIGMA_TOKEN | Yes | Figma personal access token with file_content:read | |
| FIGMA_OUTPUT_ROOT | No | Directory that every fetch_frame output directory must stay below | ./figma-output |
| FIGMA_API_BASE_URL | No | Override the Figma REST API base URL | https://api.figma.com/v1 |
| FIGMA_MAX_JSON_BYTES | No | Upper bound on a Figma JSON response, in bytes | 104857600 |
| FIGMA_MAX_FRAME_BYTES | No | Upper bound on a downloaded frame PNG, in bytes | 104857600 |
| FIGMA_REQUEST_TIMEOUT_MS | No | Per-request timeout in milliseconds | 60000 |
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 | {} |
| logging | {} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_framesA | List and optionally filter all top-level FRAME nodes in a Figma file. Returns exact page/name/node-id data, nullable dimensions, current file metadata, completeness, request ID, and rate-limit proof. Requires file_content:read. |
| fetch_frameA | Read one Figma frame and transactionally write frame.png, node.json, and a normalized imageRef-to-URL fills.json map under the output directory. Returns upstream request proof plus local size, SHA-256, PNG structure/dimensions, and JSON read-back proof. Existing unrelated files are preserved. |
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 2 tools
The two tools are fully distinct: list_frames discovers available frames while fetch_frame retrieves and writes a specific frame. There is no overlap or ambiguity in their responsibilities.
Both tool names follow the same verb_noun pattern and use consistent snake_case naming. The singular/plural distinction (fetch one frame vs. list many frames) aligns with their semantics.
With only two tools, the server feels minimal and borderline thin. The pair supports a basic list-then-fetch workflow but leaves little room for broader Figma integration beyond frame extraction.
The server covers listing and fetching frames, but it only lists top-level frames, leaving nested-frame discovery as a notable gap. There are also no tools for other common Figma actions like retrieving comments or asset exports, making the surface feel incomplete for a general Figma MCP.