Converts Figma color variables to CSS/design tokens in various framework standards
Auto-adapts generated code to local ESLint configurations when converting designs to code
Provides design-to-code conversion capabilities, extracting SVG assets, color variables, and allowing visual comparison between Figma prototypes and project screenshots
Analyzes Figma DSL structure to extract and download SVG resources and vectors with intelligent handling of complex node structures
Generates TypeScript interface types from API documentation to facilitate type-safe development
Supports extracting color variables from Figma and converting them to UnoCSS configuration formats
Click on "Install 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., "@feuse-mcp generate code from my Figma design 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.
Frontend Useful MCP (Model Context Protocol) Tools - Essential utilities for web developers to automate API integration, Figma design-to-code conversion, and development workflow optimization.
English | 中文
feuse-mcp Official Documentation
Related MCP server: Stitch MCP Auto
🎨 Figma Integration: Built-in integration with Figma-Context-MCP for seamless Figma design-to-code conversion and automatic asset extraction
📝 API Automation: Generate TypeScript interface types, API URL constants, mock data, and request functions from API documentation
🖼️ Asset Management: Download SVG and PNG images from Figma files with organized file structure
🎯 Similarity Comparison: Compare generated code pages with original Figma prototypes for accuracy validation
🛠️ Project Standards: Generate global specification guidance files for Copilot & Cursor based on current project architecture
🔧 Color Variables: Extract and convert Figma color variables to CSS/design tokens in specified standards (UnoCSS, TailwindCSS, or custom structures)
Tool Name | Category | Description | Input Parameters | Notes |
Figma-To-Code | Figma Integration | Generate frontend code based on Figma styling info with PNG assistance |
| Auto-adapts to local configs (ESLint etc), supports responsive layouts |
extract-svg-assets | Asset Analysis | Analyze Figma DSL structure and auto-extract SVG resources |
| Intelligent Figma file analysis, batch extraction of SVG icons/vectors |
extract-color-vars | Design Tokens | Extract color variables from Figma DSL to CSS framework configs |
| Supports UnoCSS, TailwindCSS, or custom file format output |
similarity-figma | Quality Control | Compare Figma prototypes with project page screenshots |
| Visual comparison with intelligent similarity scoring and detailed analysis |
api-automation | Development Tools | Parse backend API docs and generate types, constants, mock data |
| Supports multiple API doc formats, generates complete frontend API toolkit |
initialize-project-standard | Project Management | Analyze project structure and generate Copilot/Cursor global rules | No parameters | Auto-generates intelligent coding assistant project context and standards |
Download-Figma-Images | Asset Management | Batch download SVG and PNG image resources from Figma by node ID |
| Supports imageRef handling, auto-creates directory structure (low-level tool for other MCPs) |
download-svg-assets | Asset Management | Download SVG vector resources from Figma by image/icon node ID |
| SVG format only, supports complex node structures (low-level tool for other MCPs) |
Add to your MCP client configuration:
Get your Figma API key from Figma Developer Settings.
{
"feuse-mcp": {
"command": "npx",
"args": ["feuse-mcp@latest"],
"env": {
"FIGMA_API_KEY": "YOUR_FIGMA_API_KEY"
}
}
}# Clone the repository
git clone https://github.com/your-username/feuse-mcp.git
cd feuse-mcp
# Install dependencies
pnpm install
# Build
pnpm buildAdd to your MCP client configuration:
Get your Figma API key from Figma Developer Settings.
{
"feuse-mcp": {
"command": "npx",
// Configure path
"args": ["YOUR/PATH/TO/dist/main.cjs"],
"env": {
"FIGMA_API_KEY": "YOUR_FIGMA_API_KEY"
}
}
}feuse-mcp/
├── src/
│ ├── main.ts # Main entry point
│ ├── services/ # Core services
│ │ ├── figma/ # Figma integration
│ │ ├── similarity/ # Visual comparison
│ │ └── utility/ # Utility toolset
│ ├── types/ # TypeScript definitions
│ └── utils/ # Helper functions
├── docs/ # Documentation
└── dist/ # Built filesContributions are welcome! Feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.
Follow the existing code style
Update documentation as needed
This project is licensed under the MIT License - see the LICENSE file for details.
If you have more interesting, fun, and cool ideas, please submit them in issues immediately ! ! !
Figma-Context-MCP for providing Figma design analysis capabilities
fastmcp for providing MCP rapid development framework
All contributors and users of this project
理解后端接口文档自动生成接口类型、地址常量、mock数据、请求函数等
| Name | Required | Description | Default |
|---|---|---|---|
| apiDocs | Yes | 后端接口文档内容 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions generation of multiple artifacts but lacks details on side effects, authentication requirements, or whether files are created/modified. The transparency is limited to high-level functionality.
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 concise sentence that efficiently conveys the tool's core function. It is not verbose and gets to the point, though it could benefit from slightly more detail. No wasted words.
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 single parameter, no output schema, and no annotations, the description is minimally adequate. It clarifies the input and general output artifacts but lacks specifics about output format, error handling, or any prerequisites. For a tool of this apparent complexity, it is somewhat incomplete.
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 coverage is 100% with a description for the single parameter 'apiDocs' ('后端接口文档内容'). The tool description does not add additional parameter-specific semantics beyond what the schema provides, so it meets the baseline of 3.
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 generates interface types, address constants, mock data, and request functions from backend API documentation. The verb 'understand and generate' combined with the target artifacts makes the purpose specific, and it is clearly distinct from sibling tools focused on Figma/SVG assets.
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 implies usage when one needs to process backend API documentation into structured artifacts, but it does not explicitly state when to use this tool versus alternatives or provide any usage constraints. No exclusions or context about when not to use it are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download SVG and PNG images used in a Figma file based on the IDs of image or icon nodes
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | The key of the Figma file containing the node | |
| nodes | Yes | The nodes to fetch as images | |
| pngScale | No | Export scale for PNG images. Optional, defaults to 2 if not specified. Affects PNG images only. | |
| localPath | Yes | The absolute path to the directory where images are stored in the project. If the directory does not exist, it will be created. The format of this path should respect the directory format of the operating system you are running on. Don't use any special character escaping in the path name either. | |
| svgOptions | No | Options for SVG export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. Only states the basic action of downloading images, with no disclosure of network calls, authentication needs, rate limits, error handling, or side effects. Insufficient for a tool interacting 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?
Single sentence of 20 words, front-loaded with key information. Efficiently communicates core function, though could be slightly more structured (e.g., bullet points for parameter groups).
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?
Despite 5 parameters and nested objects, no output schema is provided. Description lacks details on return values (what the download produces), error conditions, and prerequisite setups (e.g., Figma API credentials). Adequate for basic understanding but not fully complete.
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 100%, so baseline is 3. The description adds context about the tool's overall purpose but does not elaborate on parameters beyond what the schema already provides. No additional semantic value for individual 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?
Description clearly specifies verb 'Download', resource 'images', formats 'SVG and PNG', and selection criterion 'based on the IDs of image or icon nodes'. Distinguishes from siblings like 'download-svg-assets' which likely handle bulk downloads.
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?
Implies use for specific image/icon nodes via node IDs, but does not explicitly state when to use this tool versus alternatives like download-svg-assets or extract-svg-assets. No when-not or prerequisite conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据图像或图标节点的ID，仅下载Figma文件中使用的SVG资源
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | The key of the Figma file containing the node | |
| nodes | Yes | The nodes to fetch as images | |
| pngScale | No | Export scale for PNG images. Optional, defaults to 2 if not specified. Affects PNG images only. | |
| localPath | Yes | The absolute path to the directory where images are stored in the project. If the directory does not exist, it will be created. The format of this path should respect the directory format of the operating system you are running on. Don't use any special character escaping in the path name either. | |
| svgOptions | No | Options for SVG export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description claims 'only download SVG resources', but the schema includes 'pngScale' for PNG exports and 'imageRef' for image fills, contradicting the stated scope. No information about side effects, authentication, or rate limits is given.
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 sentence, which is concise. However, it lacks structure and could be more informative without being verbose.
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?
With no output schema and a complex input schema (5 parameters, nested objects), the description is too brief. It does not explain return values, the relationship between parameters, or how the tool should be invoked in context.
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 100%, so the schema already documents parameters. The description does not add extra meaning beyond the schema; it merely restates the purpose. Baseline score of 3 is appropriate.
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 it downloads SVG resources based on node IDs. However, it does not differentiate from similar sibling tools like 'Download-Figma-Images' or 'extract-svg-assets', missing explicit context on when to use this tool over alternatives.
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. There are no exclusions or context hints for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从Figma DSL文件中提取颜色变量，并输出在用户指定的文件中（比如unocss、tailwindcss或者自定义标准文件中等）
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | The key of the Figma file to fetch, often found in a provided URL like figma.com/(file|design)/<fileKey>/... | |
| nodeId | No | The ID of the node to fetch, often found as URL parameter node-id=<nodeId>, always use if provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states extraction and output to a file but omits key behavioral traits: whether this is a read-only operation, authentication requirements, side effects (e.g., file creation), or what happens if the file already exists. The description is insufficient for an agent to understand the tool's impact.
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 sentence, which is concise. However, it lacks structure and fails to front-load critical information. While not verbose, the brevity sacrifices completeness and clarity.
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?
The tool has 2 parameters, no output schema, and no annotations. The description does not explain the output format, how the output file path is determined, or any error conditions. Given the low schema/annotation richness, the description is incomplete for safe and effective 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 coverage is 100% (both fileKey and nodeId are described in schema). However, the description mentions outputting to a user-specified file, yet no parameter for the output path exists in the schema. This inconsistency confuses parameter semantics and reduces the value added by the description 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 extracts color variables from a Figma DSL file and outputs them to a user-specified file. It distinguishes from sibling tools like extract-svg-assets or similarity-figma by focusing on color variables. However, the description is in Chinese, which may impact clarity for non-Chinese-speaking agents.
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 does not mention prerequisites, limitations, or context where other tools might be preferred. Sibling tools exist (e.g., extract-svg-assets), but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析figma SDL中的结构，并调用download-svg-assets工具下载Figma文件中使用的SVG资源
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | The key of the Figma file to fetch, often found in a provided URL like figma.com/(file|design)/<fileKey>/... | |
| nodeId | No | The ID of the node to fetch, often found as URL parameter node-id=<nodeId>, always use if provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It mentions analyzing structure and calling another tool, but does not disclose whether it returns data, has side effects, or error handling. The behavioral traits are insufficiently described.
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?
Single sentence, concise and to the point. However, it is not front-loaded with the most critical information and the term 'SDL' is undefined.
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?
No output schema, so description should explain return value or result; it does not. It also lacks explanation of the orchestration flow, making the tool's full behavior ambiguous.
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 100% with both parameters described adequately. The tool description does not add extra parameter details beyond what the schema provides, so a baseline score of 3 is appropriate.
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 analyzes Figma file structure and downloads SVG assets by calling another tool. It distinguishes itself from the sibling 'download-svg-assets' by implying it does preprocessing, but the exact output of the analysis is vague.
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 on when to use this tool versus 'download-svg-assets' directly or when not to use it. The agent must infer based on the description that it performs both analysis and download, but exclusion criteria are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate pixel-perfect frontend code from Figma designs. Automatically parses Figma DSL structure and style information, combines with PNG preview images for visual validation, and generates high-quality frontend component code that matches your project tech stack. Supports automatic detection of project configurations (UnoCSS/TailwindCSS/SCSS etc.) and uses existing style variables and design standards.
| Name | Required | Description | Default |
|---|---|---|---|
| fileKey | Yes | The key of the Figma file to fetch, often found in a provided URL like figma.com/(file|design)/<fileKey>/... | |
| nodeId | No | The ID of the node to fetch, often found as URL parameter node-id=<nodeId>, always use if provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions automatic detection of project configs and combining with PNG previews, but omits side effects, authentication needs, or concretely what the tool does (e.g., writes files, returns code). Incomplete behavioral disclosure.
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?
Description is a single paragraph of 4 sentences, front-loaded with purpose. Some redundancy exists (e.g., 'automatically parses...combines...'), but overall efficient for the detail provided.
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?
No output schema or annotations; description covers basic functionality but lacks specifics on output format, behavior when nodeId is omitted, or how code is delivered. Additional context needed for full understanding.
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 coverage is 100% with clear descriptions for both parameters. The description only rephrases the schema (e.g., 'fileKey from URL'), adding no meaningful new info beyond what the schema already provides.
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 generates frontend code from Figma designs, with specific verbs and resources. It distinguishes itself from sibling tools like download-svg-assets by emphasizing code generation and visual validation.
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 implies when to use (converting Figma designs to code) but lacks explicit when-not-to-use or alternative tool references. Context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
针对用户指定项目进行分析，生成Copilot 和 cursor对应的全局项目规则
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or return values. The phrase 'analyze and generate' suggests a write operation but with no further details.
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, front-loaded sentence with no superfluous information.
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?
Despite lacking parameters and output schema, the description fails to explain how the project is identified, what rules are generated, or their storage location, leaving critical 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?
The input schema has 0 parameters (100% coverage vacuously). Baseline for 0 params is 4, and the description does not add parameter meaning since none exist.
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 analyzes a project and generates rules for Copilot and cursor. However, it does not explain how the project is specified, as the input schema has no parameters.
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 vs alternatives, nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取Figma原型图，请你结合项目源码并通过原型图与生成的代码页面的截图进行相似性比对
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 当前项目代码页面的URL地址，注意不是figma网址 | |
| fileKey | Yes | The key of the Figma file to fetch, often found in a provided URL like figma.com/(file|design)/<fileKey>/... | |
| nodeId | No | The ID of the node to fetch, often found as URL parameter node-id=<nodeId>, always use if provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It describes fetching and comparing but omits details like screenshot capture, return format, or side effects. Adequate but incomplete.
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?
Single sentence covering the core purpose; could be structured into two parts (fetch and compare) but is efficient overall.
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?
Missing critical information like return value (e.g., similarity score or images) and the role of 'source code' which has no parameter. Incomplete for a comparison tool without output schema.
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 descriptions cover 100% of parameters, so baseline is 3. The description adds no extra meaning beyond what the schema already provides.
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 specifies fetching a Figma prototype and comparing similarity with a screenshot, which is a specific verb and resource. However, the mention of 'project source code' is unclear and not reflected in parameters, slightly reducing clarity.
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 on when to use this tool versus siblings like 'Figma-To-Code' or 'Download-Figma-Images'. The name implies similarity checking, but no explicit context is provided.
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. Dates show when Glama detected each change.
v1.0.0api-automationDownload-Figma-Imagesdownload-svg-assetsextract-color-varsextract-svg-assetsFigma-To-Codeinitialize-project-standardsimilarity-figmaMost tools have distinct purposes, but there is slight overlap between Download-Figma-Images and download-svg-assets, and between Figma-To-Code and similarity-figma. The mixed language (English and Chinese) may cause minor confusion, but descriptions clearly differentiate them.
Tool names mix verb-noun and noun-noun patterns, with inconsistent capitalization (e.g., Download-Figma-Images vs. download-svg-assets). Some use hyphens, others capital letters. The pattern is not uniform, but still readable.
With 8 tools covering key aspects of the Figma-to-code workflow (image downloading, color extraction, code generation, validation, project setup), the count is appropriate. It is neither too sparse nor overwhelming.
The tool set covers the main design-to-code pipeline, but lacks features like updating generated code or handling component variants. Some operations like exporting multiple assets at once or managing design tokens beyond colors are missing, leaving minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Figma MCP server brings Figma design context directly into your AI workflow.
An MCP server that provides asset auto generator
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Panzer-Jack/feuse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
