Allows comparing Vue components with Figma designs, capturing high-quality screenshots for pixel-perfect restoration.
Provides tools for Vue component development and restoration, including screenshot capture and visual comparison.
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-restoration-tools Compare the Button component with its Figma design."
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.
🛠️ Professional Figma Component Restoration Kit - A comprehensive MCP (Model Context Protocol) server for Vue component development and Figma design restoration. Features snapDOM-powered high-quality screenshots, intelligent visual comparison, and automated SVG optimization.
🎯 High-Quality Screenshots: snapDOM technology with 3x scaling, font embedding, and intelligent shadow detection
🔍 Advanced Visual Comparison: Pixel-perfect analysis with smart difference detection and quality assessment
🎨 SVG Optimization: Built-in SVGO integration with customizable configuration
🤖 MCP Integration: Seamless integration with AI coding assistants (Cursor, Claude, etc.)
Related MCP server: forgekit-storybook-mcp
Use the published npm package for easy setup and automatic updates:
Step 1: Add the MCP server to your Cursor configuration (~/.cursor/mcp.json):
{
"mcpServers": {
"figma-restoration-tools": {
"command": "npx",
"args": [
"-y",
"figma-restoration-tools",
"start"
],
"env": {
"PUPPETEER_EXECUTABLE_PATH": "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
"NODE_ENV": "production"
}
}
}
}Step 2: Restart Cursor after adding the configuration.
Step 3: Use the MCP tools in Cursor:
figma_compare - Compare components with Figma designs
snapdom_screenshot - Take high-quality component screenshots
optimize_svg - Optimize SVG assets
For contributors or advanced users who need to modify the source code:
Step 1: Clone and setup the repository:
git clone https://github.com/tianmuji/figma-restoration-tools.git
cd figma-restoration-tools
npm installStep 2: Add the local MCP server to your Cursor configuration:
{
"mcpServers": {
"figma-restoration-tools": {
"command": "node",
"args": [
"/absolute/path/to/figma-restoration-tools/src/server.js"
],
"cwd": "/absolute/path/to/figma-restoration-tools",
"env": {
"PUPPETEER_EXECUTABLE_PATH": "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
"NODE_ENV": "development"
}
}
}
}Advanced component comparison tool that analyzes differences between expected and actual screenshots.
Parameters:
{
"tool": "figma_compare",
"arguments": {
"componentName": "MyComponent",
"projectPath": "/path/to/your/vue/project",
"threshold": 0.1,
"outputPath": "/custom/output/directory"
}
}Features:
Pixel-perfect difference detection
Quality assessment scoring
Detailed analysis reports (JSON & Markdown)
Customizable comparison threshold
High-quality DOM screenshot tool using snapDOM technology for precise component capture.
Parameters:
{
"tool": "snapdom_screenshot",
"arguments": {
"componentName": "MyComponent",
"projectPath": "/path/to/your/vue/project",
"port": 3000,
"viewport": {
"width": 1440,
"height": 800
},
"snapDOMOptions": {
"scale": 3,
"compress": true,
"embedFonts": true,
"backgroundColor": "transparent",
"padding": 0
},
"outputPath": "/custom/output/path.png"
}
}Features:
3x scaling for high-resolution output
Intelligent shadow and effect capture
Font embedding support
Transparent background support
Custom viewport and output settings
SVG optimization tool powered by SVGO with customizable configuration.
Parameters:
{
"tool": "optimize_svg",
"arguments": {
"inputPath": "/path/to/input.svg",
"outputPath": "/path/to/optimized.svg",
"svgoConfig": {
"plugins": ["preset-default"],
"multipass": true,
"floatPrecision": 2
}
}
}Features:
Advanced SVG optimization
Customizable SVGO configuration
Batch processing support
Size reduction reports
PUPPETEER_EXECUTABLE_PATH: Path to Chrome/Chromium executable
NODE_ENV: Environment mode (development/production)
For components with shadows, the tool automatically calculates optimal padding based on effect data:
{
"snapDOMOptions": {
"scale": 3,
"padding": 0,
"figmaEffects": [
{
"type": "DROP_SHADOW",
"offset": {"x": 0, "y": 5},
"radius": 30,
"spread": 0
}
]
}
}Threshold | Sensitivity | Use Case |
0.0-0.05 | Very Strict | Pixel-perfect matching |
0.05-0.1 | Strict | High-quality components |
0.1-0.2 | Moderate | General comparison |
0.2+ | Loose | Rough similarity check |
Setup: Configure MCP server in Cursor
Screenshot: Use snapdom_screenshot to capture component
Compare: Use figma_compare to analyze differences
Optimize: Use optimize_svg for asset optimization
Iterate: Refine component based on analysis results
Node.js: ≥ 18.0.0
Chrome/Chromium: For screenshot generation
Vue.js project: For component restoration
MCP-compatible client: Cursor IDE, Claude Desktop, etc.
Fork the repository
Create a feature branch (git checkout -b feature/new-feature)
Commit your changes (git commit -m 'Add new feature')
Push to the branch (git push origin feature/new-feature)
Open a Pull Request
This project is licensed under the MIT License. See the LICENSE file for details.
GitHub: tianmuji/figma-restoration-tools
Issues: Report bugs & feature requests
snapDOM: High-quality DOM screenshots
Model Context Protocol: MCP framework
Vue.js: Progressive JavaScript framework
SVGO: SVG optimization library
🎨 Built for developers who demand pixel-perfect component restoration 🎨
Simple Figma component comparison tool: compare existing screenshots and generate diff.png for visual analysis
| Name | Required | Description | Default |
|---|---|---|---|
| threshold | No | Comparison threshold (0-1, lower is more strict) | |
| outputPath | No | Custom output directory for results (optional). If not provided, defaults to src/components/{componentName}/results | |
| projectPath | No | Path to the Vue project | /Users/yujie_wu/Documents/work/camscanner-cloud-vue3 |
| componentName | Yes | Name of the component to compare |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does reveal that the tool 'generate[s] diff.png', which indicates a file-writing side effect, but it does not state whether files are overwritten, how screenshots are located, what happens if screenshots are missing, or whether the tool modifies any existing files. This is insufficient for an agent to predict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's core function and output. There is no filler or redundant phrasing, 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?
The description is too brief for the full context. It does not explain how the tool relates to snapdom_screenshot (likely the capture counterpart), what the expected directory structure is, how threshold affects comparison, or what the tool returns. The schema covers parameter semantics but not the workflow or prerequisites, leaving an agent without enough context to invoke the tool confidently.
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?
All parameters have descriptive schema entries (100% coverage), so the baseline is 3. The description adds minimal meaning beyond the schema; it mentions comparing and generating diff.png but does not elaborate on the threshold, output paths, or project path. Since the schema already documents these adequately, the description does not need to compensate.
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 a specific verb ('compare'), a resource ('existing screenshots' of Figma components), and a concrete output ('generate diff.png'). It clearly differentiates from siblings: optimize_svg is for SVG optimization, snapdom_screenshot is for screen capture, while figma_compare is for visual comparison.
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 given about when to use this tool vs alternatives. It does not mention prerequisites (e.g., that screenshots must already exist), nor does it reference sibling tools or exclusion conditions. The description only implies usage through the tool name and phrase 'compare existing screenshots'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize SVG files using SVGO (SVG Optimizer) with customizable configuration
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | Path to the input SVG file (required) | |
| outputPath | No | Path to the output SVG file (optional - if not provided, overwrites the original file) | |
| svgoConfig | No | Custom SVGO configuration (optional - uses default if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it only says 'Optimize' and does not mention that the original file may be overwritten when outputPath is omitted, whether the operation is destructive/irreversible, or what the tool returns. The SVGO reference gives some expected behavior but leaves important side effects unstated.
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 filler; 'SVG Optimizer' is slightly redundant but not harmful. It is concise and scannable, though its compactness does omit behavioral context that is scored in other dimensions.
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 input schema fully documents all three parameters, including the overwrite behavior of outputPath and defaults for svgoConfig. However, with no annotations and no output schema, the definition lacks explicit guidance about side effects, safe usage, and what a successful call returns, making it adequate but not 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%, with meaningful descriptions for inputPath, outputPath, and svgoConfig, so the description does not need to repeat parameter details. The phrase 'customizable configuration' lightly reinforces svgoConfig but adds little 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 states a specific verb ('Optimize') and resource ('SVG files'), and further identifies the implementation via SVGO. It is clear what the tool operates on, though it does not explicitly differentiate from siblings; the sibling names are unrelated enough that this is not a major gap.
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?
There is no guidance about when to use optimize_svg versus figma_compare or snapdom_screenshot, nor any mention of prerequisites, exclusions, or common scenarios. The only implied usage is the general 'optimize' verb, which is not sufficient for an agent to make a confident selection decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take high-quality screenshots using snapDOM technology for precise DOM-to-image capture
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Port where Vue dev server is running | |
| selector | No | Custom CSS selector to screenshot (optional) | |
| viewport | No | Viewport size for screenshot | |
| outputPath | No | Custom output path for screenshot (optional) | |
| projectPath | No | Path to the Vue project | /Users/yujie_wu/Documents/work/camscanner-cloud-vue3 |
| figmaEffects | No | Figma effects data for smart shadow padding calculation (optional) | |
| componentName | Yes | Name of the component to screenshot | |
| snapDOMOptions | No | snapDOM capture options for high-quality screenshots with box-shadow support |
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 of behavioral disclosure. It only claims 'high-quality' and 'precise' capture but does not explain that this requires a running Vue dev server, that it writes screenshot files to an output path, or that componentName is required. These operational behaviors are essential for an agent to invoke the tool correctly and are entirely absent.
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 that communicates the core function without redundancy. It is concise and easy to scan. However, it leans on vague marketing terms like 'high-quality' and 'precise' rather than concrete operational detail, so it is not maximally informative for its brevity.
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?
This is a complex tool with 8 parameters, nested objects, no annotations, and no output schema. The description does not mention the Vue development server requirement, the required componentName, or what happens after the screenshot is taken. An agent would need to inspect the full schema and likely make assumptions about runtime requirements, which is a substantial gap for a tool of this complexity.
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 100% description coverage across all 8 parameters, including nested snapDOMOptions and viewport properties. The description itself adds no parameter-specific meaning, but with high schema coverage, baseline 3 is appropriate. The schema already documents defaults and purposes adequately.
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 function: taking high-quality screenshots of DOM elements using snapDOM technology. This distinguishes it from its siblings (figma_compare and optimize_svg) which are clearly not screenshot tools. The verb 'take' and resource 'DOM-to-image capture' make the purpose unambiguous.
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 this tool is used for capturing screenshots of Vue components, but it does not explicitly state when to use it versus alternatives like figma_compare. There are no exclusion criteria or context around when screenshot capture is appropriate. However, the siblings are functionally distinct, so the intended usage is reasonably inferred.
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.
v1.0.0figma_compareoptimize_svgsnapdom_screenshotScored across 3 tools
The three tools have distinct purposes: comparing screenshots, optimizing SVGs, and taking screenshots. There is slight conceptual overlap between figma_compare and snapdom_screenshot, but their roles are clear: one captures, one compares. No two tools appear to do the same thing.
Names use consistent snake_case, but the pattern is mixed: optimize_svg and snapdom_screenshot are verb-first, while figma_compare is object-first. This is readable but not perfectly predictable.
With only 3 tools, the server is on the lighter side, but each tool serves a distinct function in a focused restoration workflow. The count is reasonable for a specialized utility server, though slightly thin.
The tools cover capture, comparison, and optimization, but the server name suggests a broader restoration workflow. Missing operations like image conversion, batch processing, or asset export create notable gaps that agents may need to work around.
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
The Figma MCP server brings Figma design context directly into your AI workflow.
A MCP server built for developers enabling Git based project management with project and personal…
