figmcp

Overview Schema Source Related Servers Discussions Admin

Verify Code

verify_code

Idempotent

Check Flutter or React + Tailwind code against a Figma design by rendering both at 2x, then report errors, differing pixel share, and a diff image.

Instructions

Check Flutter or React + Tailwind code against the design: renders it at 2x (Flutter with flutter test, React in headless Chrome with Tailwind) and compares the render with Figma's own 2x render of the node. Returns analyzer or runtime errors (overflows, missing assets, broken images), the share of differing pixels and a diff image (the design in grey, differing pixels in red).

React and HTML: without file it checks the code get_design_context generates and compares every layer's box too. With file (a .jsx or .tsx under a folder with package.json, or an .html page) it renders that file's default export or page: it must be self-contained apart from React and image imports; images load from the project's public folder. Pass css for the stylesheet with its tokens. React and Tailwind load from a CDN and the fonts from the system or Google Fonts. Needs Chrome and the puppeteer-core package.

Flutter: With file, it checks that widget inside its own Flutter project: the project's packages and assets, inside a MaterialApp, scaled by flutter_screenutil to the frame size when the project uses it. The widget needs a constructor without arguments. Without file, it checks the reference code get_design_context generates and also compares every layer's box. Use it after implementing a frame, and fix what it reports. Text in fonts it cannot find is drawn in a fallback font, and emoji have no colour font in the test, so text after them shifts. A run takes from 20 seconds to a few minutes.

Input Schema

Name	Required	Description
`css`	No	React: a CSS file to load with the component, e.g. its global stylesheet with the design tokens.
`file`	No	Flutter: the .dart file with the widget, under the project's lib/. React: the .jsx/.tsx component file. Absolute, or relative to the project.
`fonts`	No	Folders with font files (default: the project's assets/fonts and the system fonts).
`nodeId`	No	The ID of the node, eg. "123:456" or "123-456" (instance ids like "I1:2;3:4" work too). Omit it to use the current selection in Figma.
`widget`	No	Flutter: the widget class in `file` (default: its first widget class).
`fileKey`	No	The key of the Figma file. Accepted for compatibility; the file open in Figma Desktop is always used.
`flutter`	No	Path of the flutter tool, when it is not on PATH.
`tailwind`	No	React: the Tailwind major version (default: the project's, else 4).
`viewport`	No	Lay the code out on a screen of this size, e.g. "360x780", and report runtime errors (overflows) and layers pushed off screen instead of comparing.
`framework`	No	flutter or react (default: from the file, else as get_design_context picks: the client, then the project).
`clientLanguages`	No	Comma separated languages of the client, e.g. "dart" (picks the framework).
`clientFrameworks`	No	Comma separated frameworks of the client, e.g. "flutter" (picks the framework).

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 19, 2026

addedInput schema / properties / clientFrameworks

Added value: +{
+  "description": "Comma separated frameworks of the client, e.g. \"flutter\" (picks the framework).",
+  "type": "string"
+}

addedInput schema / properties / clientLanguages

Added value: +{
+  "description": "Comma separated languages of the client, e.g. \"dart\" (picks the framework).",
+  "type": "string"
+}

addedInput schema / properties / css

Added value: +{
+  "description": "React: a CSS file to load with the component, e.g. its global stylesheet with the design tokens.",
+  "type": "string"
+}

changedInput schema / properties / file / description

Previous value: -"The .dart file with the widget, under the project's lib/ (absolute, or relative to the project)."New value: +"Flutter: the .dart file with the widget, under the project's lib/. React: the .jsx/.tsx component file. Absolute, or relative to the project."

addedInput schema / properties / framework

Added value: +{
+  "description": "flutter or react (default: from the file, else as get_design_context picks: the client, then the project).",
+  "enum": [
+    "flutter",
+    "react",
+    "html"
+  ],
+  "type": "string"
+}

addedInput schema / properties / tailwind

Added value: +{
+  "anyOf": [
+    {
+      "const": 3,
+      "type": "number"
+    },
+    {
+      "const": 4,
+      "type": "number"
+    }
+  ],
+  "description": "React: the Tailwind major version (default: the project's, else 4)."
+}

changedInput schema / properties / widget / description

Previous value: -"The widget class in `file` (default: its first widget class)."New value: +"Flutter: the widget class in `file` (default: its first widget class)."

First observedv1.5.1Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses prerequisites (Chrome, puppeteer-core), runtime cost ('20 seconds to a few minutes'), what a run returns (analyzer/runtime errors, diff share, grey/red diff image), and rendering caveats (fallback fonts, uncoloured emoji shifting text). These are exactly the operational facts an agent needs before committing to the call.

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 first sentence front-loads purpose, mechanism, and return value, and the framework-split paragraphs are a sensible structure for a dual-mode tool. It is dense and repeats the 'compares every layer's box too' clause across both framework paragraphs, which is mildly redundant, but almost every sentence carries actionable content.

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

Completeness5/5

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

For a 12-parameter, no-output-schema tool this is unusually complete: it covers both framework paths, the with/without-`file` behavior, environment requirements, latency, and known rendering limitations. Nothing an agent needs to invoke it correctly appears to be missing.

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

Parameters4/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, but the description adds real meaning: `file` must be self-contained apart from React/image imports with images from the public folder, `css` carries the design tokens, `viewport` switches the tool into layout/overflow reporting instead of comparison, and `fileKey` is accepted for compatibility only. These go beyond the field descriptions.

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?

States a specific verb and resource ('Check Flutter or React + Tailwind code against the design') and immediately explains the mechanism (renders at 2x, compares with Figma's own render). This is clearly distinguishable from every sibling, which either produce code, screenshots, or metadata rather than verifying a render.

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

Usage Guidelines4/5

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

Gives a clear trigger: 'Use it after implementing a frame, and fix what it reports,' and ties usage to get_design_context output when `file` is omitted. It does not, however, name an alternative tool or state when not to use it (e.g. when a plain screenshot would suffice), so it stops short of full when/when-not routing.

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

Deploy Server

Verify Code

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools