Which integrations are available for this server?

Generates responsive CSS styles based on design definitions extracted from Figma as part of the React component generation process. Extracts designs, components, and design tokens from Figma files to automate the conversion of designs into React code. Automates repository operations such as creating feature branches and generating pull requests for newly converted designs. Integrates with GitHub Actions for managing team releases through manual release workflows. Converts Figma designs into functional React components, maintaining proper structure, props, and responsive styling. Ensures generated React components are type-safe by producing TypeScript code with proper typing and structure.

How do I use Figma to React MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Figma to React MCP Convert https://figma.com/file/abc?node-id=1:2 into a React Navbar component and open a PR" 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.

Figma to React MCP

by surisagar900

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Figma to React MCP

A powerful MCP (Model Context Protocol) server that converts Figma designs into React components automatically. Combines GitHub, Figma, and Playwright integrations for a seamless design-to-React workflow.

Latest Updates: Enhanced performance optimizations, browser pooling, request caching, and improved error handling for production-ready workflows.

✨ Features

🎨 Figma Integration: Extract designs, components, and design tokens from Figma files
🐙 GitHub Integration: Create branches, generate pull requests, and manage repository operations
🎭 Playwright Integration: Automated visual testing and browser automation
⚛️ React-Focused: Generates TypeScript React functional components with proper typing
🔄 Automated Workflow: Figma design → React component → GitHub PR in one step
📦 NPX Distribution: Easy installation and setup via npx

Related MCP server: MCP Component Review

🚀 Quick Start

Easy Installation with npx

# Interactive setup (recommended for first-time users)
npx figma-to-react-mcp --setup

# Or run directly if you have tokens configured
GITHUB_TOKEN=xxx FIGMA_ACCESS_TOKEN=yyy npx figma-to-react-mcp

The --setup command will:

Prompt for your GitHub and Figma tokens
Configure environment variables
Set up Cursor MCP integration automatically
Create all necessary configuration files

Manual Setup

Get your API tokens:
- GitHub: Go to Settings → Developer settings → Personal access tokens → Generate new token with repo permissions
- Figma: Go to Figma Settings → Account → Personal access tokens → Generate new token

Run with environment variables:

GITHUB_TOKEN=your_github_token FIGMA_ACCESS_TOKEN=your_figma_token npx figma-to-react-mcp

🛠️ Available Tools

1. `design_to_code`

Converts Figma designs to React TypeScript components and creates GitHub PRs.

What you get:

React functional component with TypeScript
Responsive CSS styles
Proper component structure and props
Automatic GitHub branch and PR creation

Example usage in Cursor:

Paste a Figma URL: https://www.figma.com/file/abc123/Design?node-id=1%3A2
Specify component name: HeroButton
Get a complete React component with GitHub PR

2. `test_design_implementation`

Tests generated React components against Figma designs using visual regression testing and accessibility validation.

3. `analyze_figma_design`

Analyzes Figma designs and extracts design tokens, components, and structure.

4. `create_design_pr`

Creates GitHub PRs with generated React components and comprehensive test results.

5. `setup_project_branch`

Creates new GitHub branches for feature development.

📋 CLI Commands

npx figma-to-react-mcp --setup    # Interactive setup
npx figma-to-react-mcp --help     # Show help
npx figma-to-react-mcp --version  # Show version
npx figma-to-react-mcp            # Start MCP server

⚙️ Cursor Integration

After running npx figma-to-react-mcp --setup, the MCP server will be automatically configured in Cursor.

Manual Cursor Setup (if needed): Add this to your Cursor MCP settings:

{
  "mcpServers": {
    "figma-to-react-mcp": {
      "command": "npx",
      "args": ["figma-to-react-mcp"],
      "env": {
        "GITHUB_TOKEN": "your_github_token_here",
        "FIGMA_ACCESS_TOKEN": "your_figma_token_here"
      }
    }
  }
}

🔧 Configuration

Environment Variables

Required:

GITHUB_TOKEN: GitHub Personal Access Token with repo permissions
FIGMA_ACCESS_TOKEN: Figma Access Token from your account settings

Optional:

LOG_LEVEL: Logging level (debug, info, warn, error) - default: info
PLAYWRIGHT_BROWSER: Browser to use (chromium, firefox, webkit) - default: chromium

📚 Usage Examples

Basic Workflow

Setup once:
```
npx figma-to-react-mcp --setup
```
In Cursor, use the MCP tools:
- Open a Figma design
- Copy the URL (with node selection)
- Use the design_to_code tool
- Get a React component + GitHub PR automatically

Design to Code Flow

Figma Design URL → Extract Design Tokens → Generate React Component → Run Tests → GitHub PR
                                          ↓
                              TypeScript + CSS + Tests

🚀 Release Management

This package includes multiple approaches for version management:

Interactive Release (Recommended)

# Guided release with prompts
npm run release

Quick Analysis

# Analyze commits to suggest version bump
npm run release:analyze

Commit Helper

# Interactive commit message creation with conventional commits
npm run commit

Direct Release

npm run release:patch   # Bug fixes
npm run release:minor   # New features
npm run release:major   # Breaking changes

GitHub Actions

Use the "Manual Release" workflow in GitHub Actions for team releases.

📖 Complete Release Guide

🏗️ Development

Local Development

git clone <your-repo>
cd figma-to-react-mcp
npm install
npm run build
npm run dev

Testing

npm test
npm run test:watch
npm run test:coverage

📦 Publishing

To publish your own version:

Update package.json with your package name
Build the project: npm run build
Publish: npm publish

🛠️ Architecture

MCP SDK: Model Context Protocol implementation
TypeScript: Type-safe development
Playwright: Browser automation and testing
Octokit: GitHub API integration
Axios: HTTP client for Figma API
Zod: Runtime type validation

🤝 Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request

📄 License

MIT License - see LICENSE file for details.

🆘 Support

For issues and questions:

Create an issue in the GitHub repository
Run npx figma-to-react-mcp --help for CLI help
Check the interactive setup: npx figma-to-react-mcp --setup

Happy coding! 🎨➡️💻

Made with ❤️ for frontend developers who want to automate their design-to-code workflow.

Available Tools

5 tools

analyze_figma_designB

Analyze Figma design and extract design tokens, components, and structure.

ParametersJSON Schema

Name	Required	Description	Default
`figmaInput`	Yes	Figma URL or file ID to analyze

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. However, it only says 'analyze and extract' without indicating side effects, permissions, or whether it is read-only. Mutation potential is unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. Every part is meaningful and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, yet the description omits details about the return format or structure of extracted data. Given the single parameter, it is minimally incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the single parameter with a description. The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Analyze' and the resource 'Figma design', and specifies the outputs: 'design tokens, components, and structure'. This distinctly separates it from sibling tools like 'design_to_code' or 'create_design_pr'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., when to analyze vs convert to code). There is no mention of prerequisites or context, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_design_prC

Create GitHub PR with generated component and test results.

ParametersJSON Schema

Name	Required	Description
`figmaInput`	Yes	Figma URL or file ID
`componentName`	Yes	Component name
`githubBranch`	Yes	GitHub branch name
`testResults`	No	Test results to include (optional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description bears full responsibility for behavioral disclosure. The description only states 'Create GitHub PR', implying mutation, but fails to mention permissions, idempotency, error conditions, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence of 8 words. It is efficient and front-loads the primary action, though it could be expanded slightly to include more context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (3 required), no output schema, and no annotations, the description is too brief. It does not explain what 'generated component and test results' means or how the PR is created, leaving significant gaps for an agent to infer behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with descriptions for all four parameters. The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create GitHub PR' and specifies it includes generated component and test results. It distinguishes from sibling tools like analyze_figma_design and design_to_code by focusing on PR creation, though it could be more explicit about the integration of outputs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like setup_project_branch or test_design_implementation. The description does not mention prerequisites or typical workflow context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

design_to_codeB

Convert Figma design to React component and create GitHub PR. Accepts Figma URLs or file IDs.

ParametersJSON Schema

Name	Required	Description	Default
`figmaInput`	Yes	Figma URL (with node selection) or file ID. Example: https://www.figma.com/file/abc123/Design?node-id=1%3A2
`componentName`	Yes	Name for the generated React component (e.g., "HeroButton")
`outputPath`	No	Output directory for component files (default: "./src/components")	./src/components
`githubBranch`	No	GitHub branch name for the changes (default: auto-generated)	auto-generated

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden of behavioral disclosure. It mentions PR creation but lacks details on authentication, permission requirements, commit process, or error handling. The tool's behavior regarding mutation (creating a PR) is stated but not elaborated upon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The main purpose is stated first, making it easy to grasp. It could be slightly more structured, but it is efficient and free of fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, conversion and PR creation, no output schema, no annotations), the description is incomplete. It does not explain what the tool returns (e.g., PR URL), mention dependencies (e.g., Git, Figma API), or address security or setup requirements. More context is needed for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal new information beyond stating that Figma URLs or file IDs are accepted, which is already in the schema. No additional semantic details provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool converts Figma designs to React components and creates a GitHub PR. It specifies the verb ('Convert' and 'create') and resources (Figma design, React component, GitHub PR), which distinguishes it from sibling tools like 'analyze_figma_design' (analysis only) and 'create_design_pr' (PR creation alone).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as 'analyze_figma_design' or 'create_design_pr'. The description does not mention prerequisites, limitations, or conditions (e.g., when the Figma design is ready for conversion).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

setup_project_branchB

Create a new GitHub branch for feature development.

ParametersJSON Schema

Name	Required	Description	Default
`branchName`	Yes	Name for the new branch (e.g., "feature/hero-section")
`baseBranch`	No	Base branch (default: main)	main

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only says 'Create'. It does not disclose whether the branch is created locally or remotely, or any other behavioral traits like authentication needs or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It front-loads the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having only 2 parameters and no output schema, the description omits important context such as whether the branch is created in the remote repository, what the return value is, or if any subsequent actions are needed. An agent might need more to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no parameter information beyond what the input schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('new GitHub branch') with a specific context for feature development. It is distinct from sibling tools which focus on design analysis, PR creation, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for feature branch creation but provides no explicit guidance on when not to use or alternatives. Since no sibling tools overlap, the lack of exclusions is acceptable but still minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

test_design_implementationB

Test generated component against Figma design with visual regression testing.

ParametersJSON Schema

Name	Required	Description
`figmaInput`	Yes	Figma URL or file ID for comparison
`componentUrl`	Yes	URL of the implemented component to test
`componentName`	Yes	Name of the component being tested

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It mentions 'visual regression testing' but does not disclose what happens during testing (e.g., diff report generation, pass/fail criteria) or any side effects (e.g., artifact creation).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is concise and front-loaded with the key action. It earns its place but could be slightly more structured (e.g., adding a hint about output).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 3 required parameters, the description should explain what the tool returns, potential failure modes, or prerequisites (like a Figma access token). It lacks these details, making it incomplete for a testing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds minimal extra meaning beyond the parameter names and schemas. It clarifies that figmaInput can be a URL or file ID, but that is already implied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: testing a component against a Figma design using visual regression testing. It distinguishes from sibling tools like analyze_figma_design or design_to_code, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not specify prerequisites, scenarios, or when to avoid using it, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation3/5

Some tools have overlapping purposes that could cause confusion. For example, 'design_to_code' and 'create_design_pr' both involve creating GitHub PRs for React components, and 'analyze_figma_design' seems like a preliminary step that might be redundant with 'design_to_code'. However, the descriptions provide enough detail to differentiate their specific focuses, such as analysis vs. full conversion.

Naming Consistency4/5

The tool names follow a mostly consistent verb_noun pattern with snake_case, such as 'analyze_figma_design' and 'setup_project_branch'. There is one minor deviation with 'design_to_code' using 'to' instead of a verb, but overall the naming is predictable and readable across the set.

Tool Count5/5

With 5 tools, the count is well-scoped for the server's purpose of converting Figma designs to React components. Each tool appears to serve a distinct role in the workflow, from analysis to testing, making the set appropriately sized without being too thin or heavy.

Completeness4/5

The tool set covers a complete workflow for the domain: analyzing designs, converting to code, setting up branches, creating PRs, and testing implementations. A minor gap is the lack of tools for updating or managing existing components, but the core lifecycle from design to deployment is well-covered, allowing agents to work effectively.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

marmo-ui A
io.github.mahmoudilyan
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Design Tools Developer Tools
142
design-system
app.zaklad
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Design Tools Developer Tools
2
Visily UI Design
io.github.visily-app
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Design Tools AI & Machine Learning Developer Tools
25
Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93

Related MCP Servers

MCP Figma to React Converter
Developer Tools Content Management Systems App Automation
StudentOfJS
A
license
Not graded
quality
D
maintenance
Converts Figma designs into React components with TypeScript and Tailwind CSS by extracting components from Figma files and transforming them into ready-to-use code.
Updated a year ago (2025-04-24 08:50 UTC)
77
MIT
MCP Component Review
Developer Tools Testing & QA Tools App Automation
igorvieira
A
license
Not graded
quality
D
maintenance
Analyzes React component changes by performing structural analysis and generating visual diffs to identify pixel-level differences. It integrates with Figma to validate implementation compliance against design specifications and automates component reviews across git branches.
Updated 6 months ago (2026-02-20 22:56 UTC)
MIT
@manansiingh/figma-react-mcp
Design Tools Developer Tools
MananSingh2001
A
license
A
quality
D
maintenance
Converts Figma designs into production-ready React components with design token extraction, widget registry integration, and micro-frontend module generation.
Updated 6 months ago (2026-03-18 07:39 UTC)
3
93
1
MIT
Component MCP Server
Design Tools Developer Tools AI & Machine Learning
Mirabelle-Workspace
A
license
Not graded
quality
D
maintenance
Connects Figma designs to React components using your actual component library, enabling AI tools to generate production-ready code with proper imports.
Updated 4 months ago (2026-04-20 03:59 UTC)
1
MIT

Appeared in Searches

Figma design tool and resources

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/surisagar900/figma-to-react-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Figma to React MCP

✨ Features

🚀 Quick Start

Easy Installation with npx

Manual Setup

🛠️ Available Tools

1. design_to_code

2. test_design_implementation

3. analyze_figma_design

4. create_design_pr

5. setup_project_branch

📋 CLI Commands

⚙️ Cursor Integration

🔧 Configuration

Environment Variables

📚 Usage Examples

Basic Workflow

Design to Code Flow

🚀 Release Management

Interactive Release (Recommended)

Quick Analysis

Commit Helper

Direct Release

GitHub Actions

🏗️ Development

Local Development

Testing

📦 Publishing

🛠️ Architecture

🤝 Contributing

📄 License

🆘 Support

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `design_to_code`

2. `test_design_implementation`

3. `analyze_figma_design`

4. `create_design_pr`

5. `setup_project_branch`