Figma to React Native MCP
Figma 到 React Native MCP
使用 Cursor 的 MCP 将 Figma 设计转换为 React Native 组件。此工具可以从您的 Figma 设计中提取组件,并生成具有正确类型和样式的相应 React Native 组件。
安装
为了发展
添加到您的eas.json :
{
"mcpServers": {
"figma-to-code": {
"command": "node",
"args": ["PATH_TO_REPO/build/index.js"],
"env": {
"FIGMA_TOKEN": "your_figma_token",
"FIGMA_FILE": "your_figma_file_id",
"PROJECT_DIR": "your_project_directory"
}
}
}
}对于最终用户
在您的 Cursor IDE 中安装 MCP 服务器:
npx -y @smithery/cli@latest install @kailashg101/mcp-figma-to-code --client claude --config "{
\"figmaToken\": \"YOUR_FIGMA_TOKEN\",
\"figmaFile\": \"YOUR_FIGMA_FILE_ID\",
\"projectDir\": \"YOUR_PROJECT_DIRECTORY\"
}"Related MCP server: MCP Figma to React Converter
用法
安装完成后,您可以在Cursor中使用以下提示:
提取所有组件
using the extract_components mcp tool get all components from figma and generate their corresponding react native components in components folder提取特定组件
using the extract_components mcp tool get the [ComponentName] component from figma and generate its corresponding react native component in components folder配置
配置对象接受以下参数:
{
"figmaToken": string, // Your Figma access token
"figmaFile": string, // Your Figma file ID (from the URL)
"projectDir": string // Where to generate the components
}特征
当前的:
✅ 从 Figma 中提取组件
✅ 生成 React Native 组件
✅ 维护组件层次结构
✅ 处理组件 props 和类型
✅ 支持嵌套组件
即将推出:
🚧 GraphQL 模式生成
发展
贡献或修改:
克隆存储库
安装依赖项:
npm install建造:
npm run build本地运行:
npm start环境变量
在本地运行时,您将需要这些内容在您的.env中:
FIGMA_TOKEN=your_figma_token
FIGMA_FILE=your_figma_file_id
PROJECT_DIR=your_project_directory错误处理
常见错误及解决方法:
“无法创建客户端” :检查所有环境变量是否已正确设置
“未找到组件页面” :确保您的 Figma 文件有一个名为“组件”的页面
“无法获取 Figma 文件” :验证您的 Figma 令牌和文件 ID
执照
麻省理工学院
对于问题和功能请求,请在 GitHub 上打开问题。
Available Tools
3 toolsextract-componentsB
Extract all components from Figma file and get all graphql queries and mutations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 states what the tool does but lacks details on permissions, rate limits, output format, or whether it's read-only or destructive. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 the core functionality ('Extract all components from Figma file') and adds secondary action ('get all graphql queries and mutations') without unnecessary elaboration. Every word earns its place.
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 implied by extracting components and GraphQL queries/mutations, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and usage context, making it inadequate for informed tool selection.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but with no parameters, a baseline of 4 is appropriate as it adequately addresses the lack of parameters.
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 ('extract all components') and target resource ('from Figma file'), and specifies additional functionality ('get all graphql queries and mutations'). It doesn't explicitly differentiate from sibling tools like 'extract-latest-components' or 'extract-one-component', which would require a 5.
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 its siblings ('extract-latest-components' and 'extract-one-component'), nor any context about prerequisites or alternatives. The description implies a comprehensive extraction but lacks explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract-latest-componentsB
Extract newly added components from Figma file
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 'extract' but doesn't clarify if this is a read-only operation, what permissions are needed, how 'newly added' is determined (e.g., based on timestamps or user input), or what the output format might be. This leaves significant gaps for a tool with zero annotation coverage.
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 states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'newly added' means, how the extraction works, or what the result looks like (e.g., a list of components or metadata). For a tool with zero structured data, this leaves too much ambiguity for reliable 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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add any parameter information, which is acceptable here, but it could hint at implicit inputs (e.g., file identification), so it doesn't reach a perfect score.
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 ('extract') and resource ('newly added components from Figma file'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract-components' or 'extract-one-component', which likely handle different scopes of component extraction.
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 its siblings ('extract-components' and 'extract-one-component'). It implies usage for 'newly added components' but doesn't specify what qualifies as 'newly added' or any prerequisites, leaving the agent to guess when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract-one-componentC
Extract a single component from Figma file
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes |
TDQS
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. However, it only states the action without any details on permissions, side effects, rate limits, or output format. For a tool with no annotations, this minimal description fails to provide essential behavioral context.
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 directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its content, making it easy to parse 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 tool's complexity (1 parameter with nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavior, parameter usage, and output, which are critical for an agent to use the tool effectively in context with its siblings.
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?
The input schema has 1 parameter with 0% description coverage, and the tool description doesn't add any parameter semantics. It doesn't explain what 'componentName' represents (e.g., format, examples, or constraints), leaving the parameter's meaning unclear beyond the schema's basic type definition.
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 states the tool's purpose ('Extract a single component from Figma file') with a clear verb ('Extract') and resource ('component from Figma file'), but it doesn't distinguish from sibling tools like 'extract-components' or 'extract-latest-components'. The purpose is understandable but lacks specificity about what makes this tool unique compared to its siblings.
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 or specify scenarios where extracting a single component is preferred over batch extraction (e.g., 'extract-components'), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- First observed
extract-components - First observed
extract-latest-components - First observed
extract-one-component
TDQS
Scored across 3 tools
The tools are mostly distinct, focusing on different extraction scopes: all components, newly added components, and a single component. However, there is some potential overlap between 'extract-components' and 'extract-latest-components' if an agent needs to understand the difference between 'all' and 'newly added' in practice, but the descriptions clarify this well.
All tool names follow a consistent 'extract-[adjective]-components' pattern, using snake_case uniformly. The naming is predictable and clear, making it easy for agents to infer functionality from the names alone.
With only 3 tools, the set feels thin for a server that converts Figma to React Native, as it lacks tools for other operations like updating, deleting, or managing components. While the tools cover extraction well, the scope suggests more functionality might be needed for a complete workflow.
The toolset is severely incomplete for the implied domain of converting Figma designs to React Native code. It only provides extraction tools, with no capabilities for generating code, updating components, handling errors, or integrating with React Native projects, leaving significant gaps that will likely cause agent failures in practical use.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
The Figma MCP server brings Figma design context directly into your AI workflow.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Search and pull 500+ production-ready React + Tailwind sections and elements
- miromiroOAuthapp.miromiro
Turn any live website into brand colors, fonts, design tokens, SVGs, Lottie and paste-ready code.
Related MCP Servers
- FlicenseBqualityDmaintenanceA bridge between Figma designs and React implementations that enables pixel-perfect conversion of Figma designs into React applications by processing Figma file data into React-friendly format.58602-
- AlicenseNot gradedqualityDmaintenanceConverts Figma designs into React components with TypeScript and Tailwind CSS by extracting components from Figma files and transforming them into ready-to-use code.77MIT
- AlicenseAqualityDmaintenanceConverts Figma designs into production-ready React components with design token extraction, widget registry integration, and micro-frontend module generation.3581MIT
- AlicenseNot gradedqualityDmaintenanceConnects Figma designs to React components using your actual component library, enabling AI tools to generate production-ready code with proper imports.1MIT