Provides tools for interacting with Figma's API to list projects and files, fetch file JSON data and nodes, and generate React+Vite frontend code from Figma frames.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Figma MCP Server generate a React frontend from the main dashboard frame in file ABC123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Minimal local MCP (Model Context Protocol) server that exposes a few Figma-related tools to LLM clients (e.g., Claude Desktop, Cursor) over stdio. It can list projects/files, fetch file JSON (or nodes), and generate a simple React+Vite frontend from a Figma frame.
Exposes 4 tools over stdio:
list_projects — list projects for a Figma team
list_project_files — list files in a Figma project
get_file — fetch full file JSON or specified nodes
generate_frontend — generate simple React+Vite files from a Figma frame
Built with @modelcontextprotocol/sdk and Zod for schemas.
Intended to be launched by an LLM client which speaks MCP over stdio.
Related MCP server: Figma MCP Server
Node.js 18+ (native fetch)
npm
A Figma personal access token (optional for discovery; required for calls that access Figma)
Claude Desktop / another MCP-capable client to spawn the process
From the project root:
npm installOptionally create a .env:
FIGMA_TOKEN=your_figma_personal_access_tokenWindows cmd:
set FIGMA_TOKEN=your_token
node server.jsPowerShell:
$env:FIGMA_TOKEN = "your_token"
node server.jsNote: the process will open stdio transport and wait for an LLM client to connect; it does not expose an HTTP port.
Add a new MCP server entry in Claude Desktop.
Program/Command: node
Arguments: ["C:\\Users\\PawarMrHimanshuMahes\\Desktop\\Projects\\Figma_MCP\\server.js"]
Working directory: C:\Users\PawarMrHimanshuMahes\Desktop\Projects\Figma_MCP
Ensure the client spawns the process (stdio). If tools don't appear:
Run node server.js manually to verify the process stays running and emits no immediate error.
Confirm Node >= 18.
Confirm the path / args are correct and tools are registered before connect().
list_projects
Input: { team_id: string, token?: string }
Output: { projects: [{ id: string, name: string, last_modified?: string }] }
list_project_files
Input: { project_id: string, token?: string }
Output: { files: [{ id: string, name: string, thumbnailUrl?: string }] }
get_file
Input: { file_id: string, node_ids?: string[], token?: string }
Output: { file: any } — full Figma file JSON or nodes response
generate_frontend
Input: { file_id: string, node_id?: string, token?: string, framework?: "react"|"html" }
Output: { files: Record<string, string> } — generated filename → content
Handlers return both:
content: text blocks for the LLM view
structuredContent: validated data for client UI
Client launches node server.js and opens stdio pipes.
Server instantiates McpServer, registers tools (with Zod schemas), then calls server.connect(transport).
Client sends initialize; server answers with name/version and tool metadata.
Client calls tools/list to discover tools (serialized from Zod schemas).
When a tool is invoked (tools/call), the SDK validates inputs, runs the handler, and returns content + structuredContent.
Important: register tools before calling server.connect() so discovery works.
"No tools" in client:
Ensure input/output schemas are Zod objects (z.object(...)) — malformed schemas break discovery.
Confirm registerTool calls run before server.connect.
Run node server.js manually to capture startup errors.
Figma API errors:
Ensure FIGMA_TOKEN is valid and passed (env or per-call).
Check Figma rate limits and error payloads.
Node issues:
Use Node 18+ so fetch is available; the project is ESM ("type":"module" in package.json).
Key generator helpers are in server.js:
figmaFetch, color utilities, findFrameNode, nodeToJsx, traverseAndGenerate, reactAppFromFrame, generateFilesFromFigmaFile.
To improve fidelity:
Expand nodeToJsx to support more Figma node types, fonts and layout behaviors.
Add logging (console or a logger) for handler entry/exit and Figma responses.
To test locally: call tools via an MCP-capable client or temporarily add a CLI/testing harness that calls the handlers directly.
generate_frontend returns files (App.jsx, index.html, package.json, etc.).
To run a generated React app:
Save files into a new directory, run npm install then npm run dev (Vite).
Open the dev URL (typically http://localhost:5173).
server.js — MCP server + tool implementations and Figma helpers
package.json / package-lock.json — dependencies
readme.md — this document
MIT
Fetches Figma file JSON in background and returns generated frontend files (React+Vite minimal skeleton).
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| node_id | No | ||
| token | No | ||
| framework | No |
| Name | Required | Description |
|---|---|---|
| files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions fetching Figma JSON and generating frontend files, but lacks details on permissions (e.g., token usage), side effects (e.g., file creation), rate limits, or error handling. This is insufficient for a tool that likely involves external API calls and file generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key information: fetching Figma JSON and generating frontend files. It avoids redundancy and wastes no words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is partially complete. It covers the high-level purpose but misses critical details like parameter meanings, behavioral traits, and usage context. The output schema may handle return values, but the description doesn't provide enough guidance for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't explain any parameters (file_id, node_id, token, framework), such as what they represent, how to obtain them, or the meaning of enum values (react, html). The description only vaguely relates to parameters by mentioning 'Figma file' and 'React+Vite,' but adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetches Figma file JSON in background and returns generated frontend files (React+Vite minimal skeleton).' It specifies the action (fetches and returns), resource (Figma file), and output (frontend files). However, it doesn't explicitly differentiate from sibling tools like get_file, which might also fetch Figma files but not generate code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (get_file, list_project_files, list_projects) or specify scenarios where this tool is preferred over others, such as for code generation versus simple file retrieval. Usage is implied by the purpose but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches full file JSON or specific nodes if ids provided.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| node_ids | No | ||
| token | No |
| Name | Required | Description |
|---|---|---|
| file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'fetches' implies a read operation, it doesn't address authentication needs (the 'token' parameter suggests auth is required), rate limits, error conditions, or what happens when node_ids are omitted versus provided. The description is too sparse for a tool with authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the conditional behavior. There's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a tool with authentication requirements (implied by the token parameter) and multiple parameters with no schema descriptions, the description should provide more context about when and how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides minimal parameter context. It mentions that 'specific nodes' can be fetched 'if ids provided,' which hints at the node_ids parameter's purpose, but doesn't explain file_id or token at all. The description doesn't compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetches') and resource ('Figma file JSON or specific nodes'), making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'list_project_files' or 'list_projects' - those appear to list metadata while this fetches content, but the description doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance - it mentions that specific nodes can be fetched if ids are provided, but offers no explicit guidance on when to use this tool versus the sibling tools. There's no mention of prerequisites, alternatives, or context for choosing between fetching full JSON versus specific nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given project_id, returns files in that project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| token | No |
| Name | Required | Description |
|---|---|---|
| files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function without mentioning permissions, rate limits, pagination, error handling, or response format. This is inadequate for a tool that likely interacts with an external API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core functionality. There is no wasted verbiage or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is incomplete. It lacks behavioral details and parameter explanations, though the output schema may cover return values. This is the minimum viable level, with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'project_id' but provides no context about its format, source, or constraints. It omits 'token' entirely, leaving a required parameter undocumented. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('returns files') and the resource ('in that project'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'get_file' or 'list_projects', but it's not vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_file' (for individual files) or 'list_projects' (for listing projects). It lacks any context about prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a list of projects for the given team id.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| token | No |
| Name | Required | Description |
|---|---|---|
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it 'Returns a list' but doesn't disclose pagination, rate limits, authentication needs (though token parameter hints at this), error handling, or what happens if team_id is invalid. For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It states the basic purpose but lacks details on parameters, behavioral traits, and usage context. It meets a bare minimum but has clear gaps in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'team_id' generically but doesn't explain its format, sourcing, or constraints. The 'token' parameter is entirely undocumented in both schema and description. With 2 parameters and low coverage, the description fails to provide meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('list of projects'), specifying it's for Figma projects for a given team. It distinguishes from siblings like 'list_project_files' by focusing on projects rather than files, but doesn't explicitly contrast with 'generate_frontend' or 'get_file'. The purpose is specific but sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for team_id selection, or compare with sibling tools like 'list_project_files' for related operations. Usage is implied only by the tool name and description, lacking explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_frontendget_filelist_project_fileslist_projectsScored across 4 tools
Each tool has a clearly distinct purpose: generate_frontend creates code from a file, get_file retrieves file data, list_project_files lists files within a project, and list_projects lists projects for a team. There is no overlap in functionality, and an agent can easily distinguish between them.
All tool names follow a consistent verb_noun pattern using snake_case: generate_frontend, get_file, list_project_files, and list_projects. The naming is predictable and readable throughout the set.
With 4 tools, the server is well-scoped for basic Figma operations, but it feels slightly thin as it lacks update or delete capabilities. However, each tool earns its place, covering key actions like listing, retrieving, and generating from Figma data.
The toolset covers listing and retrieving Figma data well, with generate_frontend adding a useful transformation. However, there are notable gaps: no tools for creating, updating, or deleting files or projects, which limits full lifecycle management in the Figma domain.
The Figma MCP server brings Figma design context directly into your AI workflow.
Access and maintain design system docs, tokens, components, skills, and contexts across any project.
Serves your design system and coding standards to coding agents, so they stop guessing.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
