The Reqwise Figma MCP server lets AI agents safely read from and draw onto a Figma canvas, with built-in guardrails, structured verification, and persistent session state.
Check connection health (figma_status): Get rich diagnostics about the plugin connection, leader/follower mode, heartbeat, queue, and ordered next-step hints for troubleshooting — never just a bare boolean. Supports multiple IDE windows via leader/follower election.
Read the Figma canvas (figma_read): Structured reads via operations including:
Get document info, current selection, or deep-read a selection (read_selection)
Fetch nodes by ID, search/scan nodes by type or text
Retrieve styles, variables, components, and design system kits
Generate a comprehensive design.md from the file's design system
Take screenshots or export nodes
Run a layout audit to compare declared vs. rendered bounds, detect overflow, clipping, and text truncation
Draw and modify the canvas (figma_write): Execute modern JavaScript (ES2020+, async/await, etc.) against a safe figma.* proxy API to create/modify elements. Features include:
Persistent state object across calls within a session
Batched operations with partial commit and per-index error reporting
Safe defaults (e.g., frames default to transparent fill)
Structured errors with {code, message, hint} for every failure
Fetch design system rules (figma_rules): One-call markdown rule sheet covering styles, variables, and components — helping agents reuse tokens instead of hardcoding values.
Access on-demand documentation (figma_docs): Retrieve documentation for specific topics: rules, layout, API reference, tokens, icons, or recipes.
Allows AI agents to read and draw on the Figma canvas safely, with features like layout auditing, overlay creation, persistent session state, and batch operations.
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., "@Reqwise Figma MCP run a layout audit on the selected frame"
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.
An MCP server that lets AI agents read and draw on the Figma canvas — safely.
Reqwise Figma MCP pairs a local MCP server with a companion Figma plugin. Point Claude Code, Cursor, or any MCP-capable agent at it, and the agent can inspect a Figma file and draw into it by executing JavaScript against a figma.* proxy API — with the plugin layer catching the mistakes that usually turn "AI draws a screen" into "AI draws an overflowing, half-clipped mess."
It exists because the current generation of Figma MCPs make agents responsible for discipline they don't have: remembering never to overlay a semi-transparent frame, re-declaring token maps every call, manually computing x/y offsets, eyeballing screenshots to check for clipping. Reqwise moves that discipline into the server and plugin, and gives the agent a structured way to verify its own work.
Typical Figma MCP | Reqwise Figma MCP | |
Verification | Screenshot only — agent eyeballs pixels |
|
Overlays / scrims | Agent dims a screen with an opacity'd FRAME (dims the whole subtree) |
|
Session state | Token maps and id registries re-declared every call |
|
Connection | Silent boolean, or a dead WS with no explanation |
|
Multiple IDE windows | Second server instance fights for the port or silently fails | Leader/follower election; followers forward through an authenticated |
Batch operations | Hard caps (e.g. 50 ops) with all-or-nothing failure | Chunked streaming, partial commit, exact per-index error reporting, no hard cap |
Structural frames | Figma's default white fill turns layout wrappers into accidental white slabs | FRAME/COMPONENT without an explicit fill defaults to transparent; visible surfaces opt in |
Sandbox JS | Restricted/older syntax (no | Node |
Errors | Bare exceptions | Every failure carries |
Edit-in-place | Draw-from-scratch focus; per-op fights the single-threaded plugin | Selection-first workflow ( |
See ARCHITECTURE.md for the full design rationale and the root-cause fixes behind these defaults.
Related MCP server: figmad-mcp
1. Install
git clone https://github.com/<you>/reqwise-figma-mcp.git
cd reqwise-figma-mcp
npm install
npm run buildThis builds the server to dist/ and the plugin bundle to plugin/code.js.
2. Register the MCP server
claude mcp add reqwise-figma -- node /absolute/path/to/reqwise-figma-mcp/dist/server/index.js(See docs/INSTALL.md for Cursor and Claude Desktop JSON config, plus npx-based setups.)
3. Import the plugin into Figma Desktop
Figma Desktop → menu → Plugins → Development → Import plugin from manifest… → select plugin/manifest.json from this repo. Run it from Plugins → Development → Reqwise Figma MCP and keep its window open.
4. Check the connection
Ask your agent to call figma_status. A healthy connection looks like:
{
"pluginConnected": true,
"mode": "leader",
"port": 38470,
"plugin": { "version": "0.1.0", "apiVersionMatch": true, "fileName": "My File", "pageName": "Page 1" },
"hints": ["All systems nominal. Draw with figma_write; verify with figma_read layout_audit."]
}If pluginConnected is false or a hint mentions a version mismatch or missing heartbeat, see the troubleshooting table in docs/INSTALL.md.
pluginConnected is tri-state: true/false are measured, null means unknown — a follower process could not query the leader (see statusSource and statusError). Treat null as "no information", not as disconnected: operations may still be forwarding fine, so do not reinstall or restart the plugin on the strength of a null.
Tool | Purpose |
| Rich connection diagnostics — plugin connection, leader/follower mode, heartbeat, queue, sessions, and an ordered |
| Read the canvas via an |
| Execute modern-ES JavaScript against the |
| One-call design-system rule sheet (styles + variables + components) as markdown — read before drawing so you reuse instead of hardcode. For a durable spec, use |
| On-demand documentation: |
Full parameter reference for every operation and every figma.* method: docs/TOOLS.md.
figma_write// Set tokens once — they persist in this session's `state.tokens`.
await figma.setupTokens({
colors: { primary: "#2563EB", surface: "#0B0B0F" },
numbers: { "radius-md": 8 },
});
// Draw a card with wrapping text, reusing the parent's width.
const card = await figma.create({
type: "FRAME", name: "Card", parentId: state.rootId,
width: 320, layoutMode: "VERTICAL",
});
await figma.applyVariable(card.id, "fills", "surface");
await figma.create({
type: "TEXT", parentId: card.id, wrap: true,
characters: "A long paragraph that must wrap inside the card.",
});
// Verify before screenshotting for a human.
const audit = await figma.layoutAudit(card.id);
if (audit.summary.issues.length) console.warn(audit.summary.issues);design.mdAsk your agent to call:
{ "op": "generate_design_md", "params": { "depth": 3, "includeAnatomy": true, "includeScreens": true } }The response contains a source-grounded design.md: extraction coverage, colors,
typography, observed layout frequencies, screen composition evidence, local and
remote component usage, exact node ids/keys/variant ids/property keys, ready-to-run
instantiate examples, reuse rules, responsive evidence and known gaps. Save
it in the target codebase before asking the agent to create UI from an existing
Figma component system. Facts are separated from observations and unknown UX
semantics. For a very large file, tune maxComponents, maxScreens,
maxInstances or maxOutputChars; output limits omit complete sections rather
than cutting Markdown mid-table/code-block.
MCP client (Claude Code / Cursor)
│ stdio (MCP)
▼
Reqwise MCP server (Node ≥ 18, TypeScript)
│ owns HTTP+WS server on localhost:38470 (fallback +1..+9)
│ GET /health → diagnostics JSON
│ POST /rpc → follower → leader forwarding (auth token)
│ WS /ws → Figma plugin UI connection
▼
Figma Desktop plugin
├── ui.html (WebSocket client, heartbeat, reconnect w/ backoff)
└── code.js (Plugin API executor, safe-default handlers)Every operation — leader-direct or follower-forwarded — passes through one validateOperation() choke point before it reaches the plugin. Full topology, the leader/follower protocol, and the 15 safe-default fixes are documented in ARCHITECTURE.md.
docs/INSTALL.md — detailed setup, MCP client configs, troubleshooting
docs/TOOLS.md — full tool + figma.* API reference, error codes
docs/MIGRATION.md — migrating from figma-ui-mcp
docs/RECIPES.md — practical cookbook
ARCHITECTURE.md — design goals and internals
MIT © 2026 Hoang Phan. See LICENSE.
On-demand documentation for this API and its safe-by-default rules. Sections: rules | layout | api | tokens | icons | recipes.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Which doc section to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully carries the burden. It correctly implies a read-only, safe operation by describing documentation retrieval. Could be more explicit about idempotence or safety, but sufficient for a simple doc tool.
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?
Two sentences, no wasted words. Purpose and available sections are front-loaded. Ideal structure for quick comprehension.
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?
For a simple documentation retrieval tool, the description is complete given the schema coverage. It lacks mention of return format, but that is not critical given the tool's nature.
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 schema covers the parameter with 100% description coverage, but the description adds value by listing the valid sections explicitly. This aids the agent in understanding available options beyond the schema's generic description.
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 provides on-demand documentation for the API and its rules, listing specific sections. It distinguishes from sibling tools like figma_read and figma_write, which focus on design data operations.
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?
Usage is implied (when documentation is needed), but there is no explicit guidance on when to use this tool versus alternatives like figma_rules. No exclusions or context cues provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Figma canvas with a token-frugal response. Choose an operation and pass its params. layout_audit is the structured verify tool (declared vs rendered bounds, overflow, clipping, truncation). read_selection deep-reads the current selection in one call — the entry point of the selection-first edit-in-place lifecycle (read_selection → figma_write modify → layout_audit).
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | The read operation to run. | |
| params | No | Operation parameters (e.g. { nodeId }, { nodeIds }, { detail: 'sparse'|'compact'|'full' }, read_selection: { detail?, depth? }). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It mentions token-frugal responses and describes the purpose of layout_audit and read_selection. However, it lacks details on failure modes, authentication needs, or rate limits, which are important for a read tool with many operations.
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?
Four sentences with no wasted words. The first sentence front-loads the core purpose, followed by actionable guidance. Each sentence 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 tool's complexity (17 operations, nested params, no output schema), the description covers the main concept and key operations. It could be improved by mentioning typical return values or error handling, but it is reasonably complete for an experienced user.
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 description adds significant meaning beyond the schema: it explains the 'op' parameter structure and gives concrete examples for 'params' (e.g., { nodeId }, { detail }). It also clarifies the role of specific operations like layout_audit and read_selection, which are not fully defined in 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 'Read the Figma canvas', specifying the verb and resource. It also distinguishes from sibling figma_write by implying a read-only scope. The variety of operations is listed, making 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?
It provides context on when to use layout_audit vs read_selection, and mentions the token-frugal nature for efficiency. However, it does not explicitly exclude alternative tools like figma_docs or figma_rules, or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call design-system rule sheet as markdown: styles + variables + components, fetched in parallel. Read before drawing so you reuse tokens/components instead of hardcoding.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses parallel fetching and that it is a single call. However, it does not mention permissions, rate limits, or whether the data is cached. Still, it is transparent about the data type and purpose.
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 that conveys the purpose and usage guideline efficiently. It is front-loaded with the key action and result.
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 no output schema, the description explains the return format (markdown) and contents (styles, variables, components). It also advises when to use it. This is complete for the tool's 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 zero parameters, so schema coverage is 100%. The description adds no parameter info, but that is acceptable as there are none. Baseline for zero parameters is 4.
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 explicitly states it returns a design-system rule sheet as markdown with styles, variables, and components, fetched in parallel. The name 'figma_rules' aligns with this and distinguishes it from siblings like figma_docs or figma_read.
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 clear usage guidance: 'Read before drawing so you reuse tokens/components instead of hardcoding.' This tells the agent when to use this tool and the benefit. It also implicitly distinguishes from other tools that might not aggregate all rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rich connection diagnostics for the Figma bridge (never a bare boolean): plugin connection, leader/follower mode, port, heartbeat, queue, sessions, and an ordered list of concrete next-step hints when something is off.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the output components in detail and states 'never a bare boolean', but does not explicitly confirm read-only or non-destructive behavior, though implied. Safety and side effects are omitted.
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 concise (two sentences), front-loaded with purpose, and every phrase adds value. No unnecessary 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?
For a no-parameter, no-output-schema tool, the description provides a good overview of the diagnostic data returned. It lists multiple components. Could be enhanced with format details, but sufficient for an agent to understand outputs.
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?
No parameters exist, and schema coverage is trivially 100%. The description does not need to add parameter info. Baseline of 4 applies.
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 provides 'rich connection diagnostics' for the Figma bridge, listing specific elements like connection, leader/follower mode, port, etc. It distinguishes itself from sibling tools (figma_docs, figma_read, figma_rules, figma_write) which handle different operations.
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 context is clear: this tool is for diagnostics. Siblings have distinct purposes (docs, read, rules, write), so implicit differentiation exists. However, no explicit 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute modern-ES JavaScript in a sandbox against the figma.* proxy to draw/modify the canvas. state persists across calls in a session. Banned: require/process/fetch/timers/eval. Returns { ok, result, logs, warnings }.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript body. Use await figma.create({...}), figma.batch([...]), figma.layoutAudit(id), etc. Return a value to receive it as `result`. | |
| sessionId | No | Optional session key; omit to use the default session. `state` is shared per session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses sandbox execution, banned APIs, session state persistence, and return format {ok, result, logs, warnings}, ensuring 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?
Three sentences, no fluff, front-loaded with action, efficient and structured.
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 no output schema, description covers return values and key behaviors like sandbox restrictions and session persistence, making it 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 coverage 100%, description adds value by explaining code body usage, await figma examples, and sessionId role for state sharing, beyond schema definitions.
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 states 'Execute modern-ES JavaScript...to draw/modify the canvas', clearly indicating a write operation on the Figma canvas, distinct from sibling tools like figma_read.
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?
Provides context on when to use (draw/modify canvas), but does not explicitly exclude reading or mention alternatives; however, banned functions and session persistence are noted.
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.
v0.1.0figma_docsfigma_readfigma_rulesfigma_statusfigma_writeEach tool has a clearly distinct purpose: docs for API reference, read for canvas reading, rules for design systems, status for diagnostics, and write for modifications. No overlap.
All tools follow a consistent figma_verb naming pattern (figma_docs, figma_read, figma_rules, figma_status, figma_write), making it easy to infer functionality.
5 tools is well-scoped for a Figma MCP server, covering essential operations without unnecessary bloat.
The set covers reading, writing, documentation, rules, and status. While minor operations like explicit deletion or search are missing, the core lifecycle is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
DeFi safety layer for AI agents: wallet safety, token risk, tx decode/simulate. 20 tools.
Connect AI coding agents to Anima Playground, Figma, and your design system.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoangpm96/reqwise-figma-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
