Skip to main content
AllMCPs
BrowseBestCategoriesStackCompareToolsGuidesBlog
Log in Submit MCP

Stay in the loop

Get new MCP servers and top picks in your inbox.

AllMCPs

The open directory for discovering and installing Model Context Protocol servers.

AllMCPs on GitHub (opens in a new tab)
Launched onTiny Startupstinystartups.com
Explore
  • Browse servers
  • Best MCP servers
  • Categories
  • MCP clients
  • Agent prompts
  • Stack Builder
  • Compare servers
  • Random discovery New
  • Submit a server
  • Pricing & Boost Boost
Learn
  • Guides hub
  • What is MCP?
  • Install guide
  • Build an MCP server
  • Deploy an MCP server
  • Security guide
  • Troubleshooting
  • MCP for SEO & AEO
  • Protocol versioning
  • Transports: stdio vs HTTP
  • State of MCP (stats)
  • Blog & updates
Tools
  • All developer tools
  • Config generator
  • Config validator
  • Config auditor
  • MCP playground
  • Token calculator
  • OpenAPI → MCP
  • Badge generator
For agents
  • REST API docs
  • Trust & traffic Live
  • Remote MCP server SSE ↗ (opens in a new tab)
  • llms.txt ↗ (opens in a new tab)
  • Catalog JSON ↗ (opens in a new tab)
Company
  • About
  • Advertise Sponsor
  • Contact
  • GitHub ↗ (opens in a new tab)
  • Terms
  • Privacy
AllMCPs VerifiedAllMCPs VerifiedFeatured on Nick LaunchesFeatured on Nick LaunchesLaunch Llama NewsletterLaunch Llama NewsletterVerified DR - allmcps.comVerified DR - allmcps.comFeatured on SaaSGrowFeatured on SaaSGrowFeatured on Twelve ToolsFeatured on Twelve ToolsFeatured on Saaspa.geFeatured on Saaspa.geFeatured on Findly.toolsFeatured on Findly.toolsFeatured on Startup FameFeatured on Startup FameFeatured on LaunchKiwiFeatured on LaunchKiwiFeatured on ScrollLaunchFeatured on ScrollLaunchFeatured on DailyPingsFeatured on DailyPingsFazier badgeFazier badgeFeatured on NewTool.siteFeatured on NewTool.siteFeatured on saasfame.comFeatured on saasfame.comDR Checker - Domain RatingDR Checker - Domain RatingListed on Turbo0Listed on Turbo0Launched on LaunchBoard - Product Launch PlatformLaunched on LaunchBoard - Product Launch PlatformList on SimilarlabsList on Similarlabshttps://codetrendy.comhttps://codetrendy.comListed on DevTool.ioFeatured on BuildlistFeatured on BuildlistLaunched on Tiny StartupsFeatured on ShowMeBestAIFeatured on ShowMeBestAIFind us on LaunchZoneFind us on LaunchZoneAllMCPs VerifiedAllMCPs VerifiedFeatured on Nick LaunchesFeatured on Nick LaunchesLaunch Llama NewsletterLaunch Llama NewsletterVerified DR - allmcps.comVerified DR - allmcps.comFeatured on SaaSGrowFeatured on SaaSGrowFeatured on Twelve ToolsFeatured on Twelve ToolsFeatured on Saaspa.geFeatured on Saaspa.geFeatured on Findly.toolsFeatured on Findly.toolsFeatured on Startup FameFeatured on Startup FameFeatured on LaunchKiwiFeatured on LaunchKiwiFeatured on ScrollLaunchFeatured on ScrollLaunchFeatured on DailyPingsFeatured on DailyPingsFazier badgeFazier badgeFeatured on NewTool.siteFeatured on NewTool.siteFeatured on saasfame.comFeatured on saasfame.comDR Checker - Domain RatingDR Checker - Domain RatingListed on Turbo0Listed on Turbo0Launched on LaunchBoard - Product Launch PlatformLaunched on LaunchBoard - Product Launch PlatformList on SimilarlabsList on Similarlabshttps://codetrendy.comhttps://codetrendy.comListed on DevTool.ioFeatured on BuildlistFeatured on BuildlistLaunched on Tiny StartupsFeatured on ShowMeBestAIFeatured on ShowMeBestAIFind us on LaunchZoneFind us on LaunchZone
© 2026 Jackalope Digital LLC. All rights reserved.
  1. Home
  2. Browse
  3. Memi
  4. vs Genable
Side-by-Side Model Context Protocol Comparison

Memi vs Genable

In-depth architectural comparison of the Memi and Genable MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.

At a Glance & Executive Verdict

Memi
Architecture & Design · Local stdio
Quality: 55/100 (Good) | Auth: No auth required
Genable
Architecture & Design · Local stdio
Quality: 63/100 (Good) | Auth: No auth required
Verdict Summary: Choose Memi if you need specialized Architecture & Design tools running via a local process. Choose Genable if your workspace requires Architecture & Design integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.

Which MCP Server Should You Choose?

Memi logo

Choose Memi when:

  • You need dedicated capabilities in the Architecture & Design domain.
  • You prefer local stdio subprocess transport architecture.
  • Your security boundary fits: No auth required (Free / Open Source).
  • Primary tools included: 46 MCP tools for design-system and interface workflows, Frontend interface audits, Tailwind token extraction.
Explore Memi Details
Genable logo

Choose Genable when:

  • You need dedicated capabilities in the Architecture & Design domain.
  • You prefer local stdio subprocess transport architecture.
  • Your security boundary fits: No auth required (Free / Open Source).
  • Primary tools included: jsx, inspect, edit.
Explore Genable Details

Feature & Specification Comparison

Specification
Memi logo
Memi
sarveshsea
Architecture & Design
Genable logo
Genable
musepy
Architecture & Design
SummaryDesign-system memory for coding agents with 46 MCP tools for UI audits, Tailwind token extraction, shadcn registry workflows, Figma context, design docs, and interface-quality diagnostics.Write-side MCP for Figma — complements Figma's official read-only MCP. 41 tools for building and editing Figma designs from Claude Code, Cursor, Cline: JSX-like tree creation, variables/tokens, components, cross-page navigation, and visual verification via screenshots. Install: npx -y genable-mcp.
Category & Scope

Tools & Capabilities Breakdown

Memi Tools (6)

46 MCP tools for design-system and interface workflows
Frontend interface audits
Tailwind token extraction
shadcn registry workflows
Figma context and design documentation
Deterministic GitHub Actions checks with SARIF support

Genable Tools (39)

jsx
Create design trees with nested JSX markup. One jsx call builds a complete subtree atomically — nesting is the hierarchy. Keep a single logical unit inside one call; the returned root's children are already built, not stubs to be filled in later. Examples: jsx({markup: "<frame name='Card' layout='column' padding={16} fill='#FFFFFF' w='fill' />"}) jsx({markup: "<frame name='Row' layout='row' gap={8} padding={12} w='fill'><icon name='lucide:settings' size={20} /><text name='Label' w='fill'>Account</text><icon name='lucide:chevron-right' size={16} /></frame>"}) Elements: frame, text, rect, ellipse, line, icon, image, instance, component, group, section, vector Attributes (frame): layout, justify, items, wrap, w, h, minW, maxW, p, gap, bg, fill, rounded, stroke, shadow, blur, bgblur, opacity, layoutPositioning Attributes (grid container): cols, rows, gap, rowGap, colGap, colSizes, rowSizes, autoFlow, autoRows — see "Grid layout" below Attributes (grid child): colSpan, rowSpan, alignX, alignY, rowStart, colStart Attributes (text): size, weight, lineHeight, font, fill, w (w="fill" for wrap), maxLines, textTruncation, paragraphSpacing Multi-paragraph text: put a BLANK LINE between paragraphs inside <text> — it becomes a real paragraph break. A single newline is collapsed to a space (prose wrap); for a hard single-line break write {'\n'}. Pair multi-paragraph body copy with paragraphSpacing={N} for gap between paragraphs. Truncation: maxLines={N} caps a wrapping text at N lines with an ellipsis (needs a bounded width, e.g. w="fill" or w={240}). Advanced text — inline emphasis spans (**bold** *italic* ~~strike~~ in content), coloured/sized spans, vertical trim, hanging indent/punctuation, list spacing → read skill:typography (don't inline these here). Effects: shadow="0,8,32,0,#0006" or shadow={shadow(0,8,32,0,'#0006')}; blur={10} for layer blur; bgblur={20} for frosted-glass/glassmorphism background blur. Multiple effects merge automatically. Decoration in auto-layout: floating orbs/blobs/decorative shapes inside a row/column parent need layoutPositioning="absolute" so they don't get stacked into the main-axis flow. Full-frame backgrounds: set the parent frame's bg directly. Don't add a separate <rect> backdrop. Supported gradient strings (CSS-like subset, not full CSS): - linear-gradient(<angle>deg, <#hex> <pos>%, ...) e.g. "linear-gradient(135deg, #A 0%, #B 100%)" - linear-gradient(to <direction>, <stops>) directions: top/right/bottom/left and corners (e.g. "to bottom right") - radial-gradient(<stops>) centered, ellipse-fill — no position/shape modifiers - radial-gradient(circle, <stops>) centered, circle shape only - conic-gradient(from <angle>deg, <stops>) Unsupported (will be rejected): "circle at X% Y%", "ellipse at ...", "X% Y%" position syntax, named colors (red/blue/...), hsl(), and numeric stops without a percent sign. Text: <text size={24}>content here</text> Rich text (mixed inline styles in one text node — runtime parses markup per character): **bold** e.g. "Click **here** to continue" *italic* e.g. "Read the *fine print*" ***bold italic*** e.g. "This is ***critical***" ~~strikethrough~~ e.g. "Was ~~$19.99~~" {color:#HEX|text} e.g. "{color:#EF4444|Error}: something failed" {size:N|text} e.g. "{size:32|Big} then normal" Nesting stacks: "{color:#EF4444|**$9.99**}" → red + bold on the same range. For uniform whole-text styling use the weight / fill / size props instead — markup is only for MIXED styles within one text node. Instance: <instance ref="Button" variant="Size=Large"/> Self-closing: <line w="fill" stroke="#E5E7EB"/> (use line for dividers/separators; rect/ellipse for SMALL pure decoration with no children — page-level backgrounds belong on the parent frame's bg) Arc/Ring: <ellipse w={120} h={120} arc="0 270" fill="#4F46E5"/> (arc="start end innerRadius?" — innerRadius 0-1 makes a donut/ring) Grid layout: `layout="grid"` + `cols={N}`. Omit `rows` for auto-rows (rows grow to fit children); set `rows={M}` for a fixed N×M. `gap`, or `rowGap`/`colGap` separately. - Per-track sizing: `colSizes="240px 1fr 1fr"` (fixed sidebar + two flexible columns) or `rowSizes="80px 1fr"` (fixed header row + flexible body). Tokens: `Npx`/`N`=fixed px, `Nfr`=flexible share (`1fr 2fr` ⇒ 1:2), `hug`=fit-content. Setting `colSizes`/`rowSizes` infers `cols`/`rows` from the token count — don't also pass a conflicting count. - Auto-flow: `autoFlow` packs children row-major into the next free cell (best for galleries/masonry, esp. with mixed spans). `autoRows` lets the grid manage its own row count. - Per-child: `colSpan`/`rowSpan` (cell spanning), `alignX`/`alignY` (start|center|end|auto within the cell), `rowStart`/`colStart` (0-based explicit cell anchor — requires manual placement, so do NOT combine with `autoFlow`). Sizing defaults (lean on them): rows are HUG (cells fit content) and the container HUGS its height automatically, while children default to fill-width / hug-height. So a content gallery needs only `cols` + a `w` (fixed px or `"fill"`) — no `rowSizes`, no height. For equal-height rows (KPI tiles, dashboards) set `rowSizes="1fr 1fr"` (children then FILL the rows); for fixed-height bands use px row sizes. A `rowSpan>1` child fills its span. Gotchas: (1) the container can hug HEIGHT but not WIDTH (columns are FLEX) — always give it a `w` (`"fill"` or px). (2) `justify`/`items` are no-ops on a grid — use per-child `alignX`/`alignY`. (3) for a 1-column stack use `layout="column"`, not grid. Prefer grid for a 2-D matrix (galleries, KPI tiles, pricing tiers, dashboards); use row/column when children differ in width or you need space-between. Variable binding: fill/bg/stroke accept qualified bare-name token strings (e.g. bg="$Theme/Bg/Surface"). Object literals (fill={{variable_id:...}}) drop the binding silently — always use the string form. Swap an existing subtree: jsx({replaceId: "<id>", markup: "..."}) replaces the old node at the same parent and sibling index atomically, preserving position in one call. Markup must have a single root. Use jsx for tree creation; edit for property updates on known nodes.

Ready-to-Paste Client Configurations

Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).

Memi Configuration
mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "sarveshsea-memi": {
      "command": "npx",
      "args": [
        "-y",
        "@memi-design/cli@latest"
      ]
    }
  }
}
Genable Configuration
mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "musepy-genable": {
      "command": "npx",
      "args": [
        "-y",
        "genable-mcp"
      ]
    }
  }
}

Frequently Asked Questions

Memi is categorized under Architecture & Design and uses a local stdio subprocess. In contrast, Genable belongs to Architecture & Design using local stdio subprocess. Select Memi when you need capabilities focused on architecture & design and Genable when you require tools for architecture & design.

More alternatives to MemiMore alternatives to GenableArchitecture & Design category hubCanonical compare URL

Related MCP Server Comparisons

Popular comparisons with Memi

  • Uxloom logoMemi vs Uxloom
  • Saglitzdesign MCP logoMemi vs Saglitzdesign MCP
  • Brandkit MCP logoMemi vs Brandkit MCP
  • Tentra MCP logoMemi vs Tentra MCP

Popular comparisons with Genable

Architecture & Design
Architecture & Design
Quality signal55/100 (Good)63/100 (Good)
Transport ProtocolLocal Subprocess (stdio)Local Subprocess (stdio)
Auth RequirementNo auth requiredNo auth required
Pricing ModelFree / Open SourceFree / Open Source
Required Env VarsNone requiredNone required
Compatible Clients
Claude DesktopCursorWindsurfClineVS Code
Claude DesktopCursorWindsurfClineVS Code
Install path signalnpx · highnpx · high
Engagement & Health 2 views 0 copies 0 upvotes 46 stars 4 views 0 copies 0 upvotes 2 stars
Verified / OfficialCommunity ListingCommunity Listing
Open full listingView Memi ListingView Genable Listing
inspect
Read design node(s) — choose what to surface with `facets`. Default (no facets) returns a skeleton: id, name, type, role, children. For anything else, list the facets you need — nothing else is included. Facets: structure name, type, size, layout shorthand — cheap overview layout layoutMode/gap/padding/align/sizing (row/column, fill/hug, etc.) paint|fill fills + Paint.boundVariables.color (see bound tokens) stroke strokes, strokeWeight, strokeAlign, dashPattern effects shadows, blurs typography|text fontFamily, fontSize, fontWeight, lineHeight, letterSpacing appearance opacity, visible, blendMode, cornerRadius, clipsContent variables node-level boundVariables + explicitVariableModes (token bindings) lint validation view — per-node role + visual/layout summary + issues (severity error/warning/info). Specific node only, depth-3 default; exclusive (ignores other facets). all everything Parameters: node "/" for page root, or node ID from jsx/inspect results (e.g. "100:5"). facets array of facet names listed above. depth Max tree depth (default: 5, max: 10). Selection: when the user prompt carries a `<selected_nodes>[{id,name,type}…]</selected_nodes>` block, those IDs are authoritative (a reference, not a snapshot) — inspect them directly, don't call `get_selection`. Start shallow (depth 1–2); go deeper only when the task needs leaf access — a full-depth dump of a large tree burns thousands of tokens. Examples: inspect({node: "/"}) → page skeleton inspect({node: "100:5"}) → one-node skeleton inspect({node: "100:5", facets: ["variables"]}) → token bindings only inspect({node: "100:5", facets: ["layout", "paint"]}) → layout + fills inspect({node: "100:5", facets: ["all"]}) → full properties inspect({node: "100:5", facets: ["lint"]}) → validate subtree (roles + issues) Use `get_screenshot` for visual verification. Use `facets: ["lint"]` to validate a subtree (roles + issues) rather than read properties.
edit
Batch update properties on nodes. The universal write tool — use for sizing, radius, opacity, effects, instance component-prop overrides, or any property not covered by focused setters. For single-property changes, prefer focused setters (they validate input more strictly): set_text — text content set_fill — fill / background color set_stroke — border set_layout — auto-layout (gap, padding, direction) Use when: - Batch fixes — multiple nodes, mixed properties in one call - Properties not covered by setters: w/h, corner, opacity, blur, shadow, INSTANCE TEXT/BOOLEAN/INSTANCE_SWAP overrides - Need to mix Figma props and component property overrides in the same node entry Returns (per node): `applied: [keys]` (written), `noop: [keys]` (already that value), `rejected: [{key, reason}]`. Empty arrays are omitted. - Single: { data: { id, name, type, applied?, noop?, rejected? } } - Batch: { data: { count, results: [...], errors?, partial? } } `rejected` is TERMINAL: the property is invalid for that node type (e.g. `corner`/cornerRadius on a TEXT node, `layoutMode` on a vector) or readonly — it will NEVER apply. Do NOT retry a rejected property; choose one valid for that node type, or target a different node. If EVERY requested property is rejected, the call returns `{ error }` — do not re-issue it. `partial: true` (batch) means some entries succeeded and some failed — check `errors[]` for which entries to retry. Skip when: - One property on one node — use the focused setter for clearer errors - Color via variable token — use set_fill/set_stroke (edit silently drops bare-name tokens here) - Need to apply auto-layout — use set_layout Component property overrides: For instances, use property DISPLAY NAMES (e.g. "Label") — edit resolves them to Figma's internal keys automatically. Component props mix with Figma props in the same call. Examples: edit({node: "1:2", props: {corner: 16, opacity: 0.8}}) edit({nodes: [ {node: "1:1", props: {w: "fill", corner: 8}}, // Figma native props {node: "1:2", props: {opacity: 0.6}}, {node: "1:3", props: {Label: "Sign In"}} // instance TEXT prop (by display name) ]})
read_jsx
Read a Figma subtree as canonical JSX text — the same dialect the `jsx` tool accepts as input. Output is line-numbered and byte-stable: slicing a chunk and feeding it as `edit_jsx`'s `old_string` is guaranteed to match. Each existing node carries `id="X:Y"` as the first attribute so edit_jsx can update it in place. Defaults are dropped, vocabulary uses short DSL names (w/h/p/gap/bg/rounded/layout/justify/items/content). When to use: - Before `edit_jsx`: read first to get the exact text to replace - To browse a subtree as code rather than as JSON (inspect facets) - To produce a substring for `search_jsx` to grep against Skip when: - You only need one property value → use inspect with facets - You need variable bindings or style references → use inspect's variables/styles facet Example: read_jsx({ node: "1:1" }) → 0001 <frame id="1:1" name="Login" w={320} h={480} layout="column" gap={12} p={24} bg="#fff"> 0002 <text id="1:2" size={24} weight="Bold">Welcome back</text> 0003 <frame id="1:3" w="fill" h={44} rounded={8} layout="row" justify="center" items="center" bg="#000"> 0004 <text id="1:4" size={14} fill="#fff">Sign In</text> 0005 </frame> 0006 </frame> Output is wrapped in {data:{jsx:"..."}} — pass jsx (with or without line numbers) to edit_jsx.
edit_jsx
Update existing nodes by editing the canonical JSX text of a subtree. Same contract as Claude Code's Edit tool: pass an `old` substring (from read_jsx output) and a `new` substring; the system locates the match, parses the new JSX, and applies property changes to every node whose `id` is preserved across old → new. Read first, then edit. `old` must come from read_jsx output for the same scope. Uniqueness is enforced unless replace_all is true. Chaining edits — DON'T re-read between edits. On success the response returns the re-serialized scope as `data.jsx` (same line-numbered format as read_jsx, reflecting your change). Slice your next `old` from THAT, not from a stale earlier read. Only call read_jsx again if `data.jsxTruncated` is set (scope too large to echo). Accepted `new` shapes: - Self-closing: `<frame id="1:5" bg="#0066FF" rounded={8} />` — prop-only edit, children untouched - Opening tag only: `<frame id="1:5" bg="#0066FF" rounded={8}>` — auto-converted to self-closing (same semantics as above) - Full element with closing: `<frame id="1:5" ...>...children...</frame>` — touches nested ids too What it does (MVP scope): - For every `<tag id="X:Y" ...>...</tag>` in `new`, set that node's props to match (multi-node, multi-prop in one call). - For text nodes, the children content is treated as the new `characters`. - Defaults are dropped, vocabulary uses short DSL names (w/h/p/gap/bg/rounded/layout/justify/items/content). What it does NOT do yet: - Creating new children (use `jsx` tool — the description tells you what's supported). - Deleting children that disappeared from new (use `delete_node`). - Reparenting / moving (use `move_node`). Example — restyle a button: // 1. Read first read_jsx({ node: "1:1" }) // 2. Edit edit_jsx({ scope: "1:1", old: '<frame id="1:5" w="fill" h={44} rounded={8} bg="#000">', new: '<frame id="1:5" w="fill" h={44} rounded={12} bg="#0066FF">', }) // → updates node 1:5 with new rounded + bg Example — multi-node edit (one call): edit_jsx({ scope: "1:1", old: '<frame id="1:5" w="fill" h={44} rounded={8} bg="#000">\n <text id="1:6" size={14} fill="#fff">Sign In</text>\n</frame>', new: '<frame id="1:5" w="fill" h={44} rounded={12} bg="#0066FF">\n <text id="1:6" size={16} fill="#fff">Sign Up</text>\n</frame>', }) // → updates node 1:5 (rounded, bg) AND node 1:6 (size, content) atomically
find_nodes
Search nodes on the current page by name substring or type. Case-insensitive. Scoped to the current page — call switch_page first if your target lives elsewhere. Match logic: a node matches if its NAME contains the query (substring) OR its TYPE equals the query (exact, lowercased). So query "frame" finds both nodes named "Frame 12" and all nodes of type FRAME. Use when: - User refers to a node by name without giving an ID ("the Hero button", "the Footer") - Locating all nodes of a specific type (COMPONENT, TEXT, FRAME, INSTANCE) before bulk operations - Looking up existing nodes before jsx() so you can wire them as <instance>/<component> Returns: { data: { results: [{id, name, type, x, y, width, height}], total, truncated: boolean } } Capped at 20 results — set explicit scope to narrow if truncated. Skip when: - You already have the node ID — call inspect directly - You want the user's current selection — use get_selection - Target is on a different page — call switch_page first Examples: find_nodes({query: "Button"}) // by name substring find_nodes({query: "frame"}) // by type (FRAME) find_nodes({query: "Card", scope: "1:2"}) // scoped to subtree
discover_props
Discover the unique values used for given properties across a subtree. For surveying a design system or auditing inconsistency. Use when: - Auditing token coverage — "what colors actually appear in this page?" - Spotting outliers — "are there fontSize values that escaped the type scale?" - Before a bulk replace_props — to know which source values you'll be replacing Returns: { data: { <propName>: [<unique values, deduplicated>...] } } Each requested property name becomes a key; its value is the list of distinct values found at any node in the subtree. Searchable properties: fillColor, textColor, strokeColor, strokeWeight, opacity, cornerRadius, gap, fontSize, fontFamily, fontWeight. Skip when: - You want a specific node's properties — use inspect with facets - You want to find nodes BY a value (not values used by name) — use find_nodes or replace_props - Property you care about isn't in the searchable list — discover_props can't surface it Examples: discover_props({node: "1:2", props: ["fillColor", "fontSize"]}) discover_props({node: "/", props: ["cornerRadius", "opacity"]}) // whole page
replace_props
Bulk find-and-replace property values across a subtree (target node + all descendants). Destructive batch mutation — no preview, no undo across many nodes. Returns per-rule match counts. Use when: - Theming pass: change every #FFF fill to #000 across a screen - Token migration: bump every fontSize from 14 to 16 - Normalizing values left inconsistent by earlier passes - The alternative is N targeted single-node calls (set_text / set_fill / edit) Returns: { data: { replacements: [{ rule: 0, matched: 12 }, { rule: 1, matched: 0 }] } } Parameters beyond schema: - `node` is the subtree root; search recurses into all descendants (depth-first). - Each rule's `from` is an EXACT-match string (no substring, no regex). For typed props (fontSize, opacity), pass values as strings — the executor coerces. - Zero matches do NOT error — they return matched: 0. Sanity-check with discover_props first if you're unsure values exist. Skip when: - Updating a single known node — use set_text / set_fill / set_stroke / set_layout for type-aware single-intent edits, or edit for generic. - Values are variable-bound (tokens) — replace_props bypasses bindings; use bind_variable to swap the token instead. - You need partial / fuzzy match — replace_props is exact-only; you'll need find_nodes + a loop. Examples: // single rule, white -> black replace_props({node: "1:2", rules: [{prop: "fillColor", from: "#FFF", to: "#000"}]}) // batch theme update — both rules applied in one pass replace_props({node: "1:2", rules: [ {prop: "fillColor", from: "#FFF", to: "#000"}, {prop: "fontSize", from: "14", to: "16"} ]})
delete_node
Delete a node and all its children. The node id becomes invalid after deletion — drop any cached references. Use when: - Removing nodes you created earlier in this session (cleanup, retry after misplacement) - User explicitly asks to remove, delete, or "get rid of" an element Returns: { data: { id, name, changed: true } } If the deleted node was NOT created in the current session, the response carries an extra `warning` field. The deletion still happened — this is a signal that you removed pre-existing user work, surface it to the user if it wasn't requested. Skip when: - Target is the page root ("/") — use delete_page to remove a whole page - You want to relocate rather than remove — use move_node - The node is currently user-selected and removal wasn't explicitly requested — confirm via ask_user first Examples: delete_node({node: "1:2"})
move_node
Relocate a node without recreating it. Preserves IDs, bound variables, and component instances across the move, so callers tracking the node by ID never need to re-discover it. Use for: (a) changing child order within a container, (b) moving a subtree into a different parent, (c) fixing a placement mistake after jsx. Examples: move_node({node: "1:3", name: "NewTitle"}) — rename in place move_node({node: "1:3", parent: "1:4"}) — move into parent 1:4 move_node({node: "1:5", index: 0}) — reorder within current parent
clone_node
Deep-copy a node with optional property overrides. Examples: clone_node({node: "1:2"}) — clone to page root, same name clone_node({node: "1:2", parent: "/"}) — clone to page root explicitly clone_node({node: "1:2", parent: "/", name: "Hero Copy"}) — clone to root with custom name clone_node({node: "1:2", parent: "1:4"}) — clone into parent node 1:4 clone_node({node: "1:2", parent: "1:4", overrides: {"bg": "#D9D9D9"}})
list_variables
List variables as a flat array with referenced collections. Returns {data: {variables[], collections[], nextCursor?}}. Each variable carries its full Figma shape: id, name, variableCollectionId, resolvedType, valuesByMode. collections[] only includes collections referenced by the returned variables (use for mode-name resolution). Parameters: collection — VariableCollectionId to filter by filter — substring match on variable name (case-insensitive) cursor — opaque pagination cursor from a previous call limit — max variables per page (default 100) Examples: list_variables() list_variables({collection: "VariableCollectionId:1:2"}) list_variables({filter: "bg"}) list_variables({cursor: "100"})
+27 more tools listed on main page
Opentakeoff logo
Genable vs Opentakeoff
  • Figwright logoGenable vs Figwright
  • Icon Composer MCP logoGenable vs Icon Composer MCP
  • Saglitzdesign MCP logoGenable vs Saglitzdesign MCP