Figme vs Genable
A side-by-side look at the Figme and Genable MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Figme for architecture & design work as a local process; choose Genable for architecture & design as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Figme when
- You need dedicated capabilities in the Architecture & Design domain.
- You prefer a local stdio subprocess transport.
- You want tools like
fig_overview, fig_tree, fig_node.
Choose Genable when
- You need dedicated capabilities in the Architecture & Design domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
jsx, inspect, edit.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Architecture & Design | Architecture & Design |
| Quality signal | 59/100 · Good | 60/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 3 | 3 |
| Directory activity | 1 views 0 installs 0 upvotes | 6 views 0 installs 0 upvotes |
| Tools | 12 | 39 |
| Full listing | View Figme | View Genable |
Tools & capabilities
Figme tools 12
fig_overviewOpen a local Figma .fig file and summarise it: document name, export date, node counts by type, the page list, and how many components / variables / images it holds. START HERE. Then fig_tree a page, then fig_node / fig_style on interesting guids; fig_find jumps straight to a name or a piece of text. Everything is read-only and offline.fig_treeList the layers under a node, breadth-limited by depth (default 2, max 6). Returns a FLAT list in document order; each entry carries `depth` (relative to the requested root) and `parent`, so the hierarchy is reconstructable, and `children` (count) so you can see where to deepen. format:"outline" returns indented text lines instead of JSON and is roughly 4x denser for browsing. Large subtrees are truncated with truncated:true and a nextCursor you can pass back to continue.fig_nodeInspect one node by guid (e.g. "2:1339"). detail:"full" (default) gives geometry, fills/strokes/effects as hex colours, corner radii, auto-layout, text basics, component and variable links, plus child summaries. detail:"raw" returns the decoded Figma record verbatim — the escape hatch for fields this server does not map yet; it is limited to one node per call and can be large.fig_findSearch a file for nodes by name and by text content (case-insensitive substring), optionally restricted to node types and/or a subtree. Each hit comes back with the page it lives on, a breadcrumb of ancestor names, and which field matched — so you can jump straight to a guid and then call fig_node / fig_style. Omit `query` to list every node of the given types.fig_textExtract every string of copy in the file (or in one subtree via `scope`), in document order: guid, layer name, the characters, the page, and the base typography (font, size, line-height, colour). With includeRuns:true each node also carries its styled runs — the mixed-format spans Figma stores per UTF-16 code unit — with only the fields each run overrides. Use this for copy audits and translation passes rather than walking the tree.fig_styleThe flattened style of one node, shaped for writing code: hex fills / strokes / effects, corner radii, typography, and auto-layout translated into CSS flexbox terms (display, direction, gap, padding, justifyContent, alignItems, sizing) plus how the node behaves inside its parent layout (flexGrow, alignSelf, margin). Shared styles and variable bindings are named whenever they resolve inside this file.fig_componentsList the components (SYMBOL nodes) defined in the file: guid, name, description, the component-set it belongs to when it is a variant, its property definitions with defaults, and how many instances of it exist. Filter with `query` (case-insensitive substring of the name). Sorted by instance count, most-used first, so the load-bearing parts of the design system come back before one-off symbols. Follow up with fig_instance on a specific INSTANCE guid.fig_instanceExplain one component INSTANCE: which SYMBOL it points at, its component-property assignments with the property names resolved, and every override it applies — each with the path down into the component, the node that path addresses, and the fields it changes. Use it to see how an instance differs from its component without diffing two subtrees.fig_variablesList the design tokens in the file: every variable collection (VARIABLE_SET) with its modes, and every variable with its value per mode — colours as hex, numbers and strings verbatim. Aliases are followed when the target variable lives in this file; a variable published from another library is returned as its opaque assetRef instead. Filter with `set` (collection name or guid) or `query` (substring of the variable name).fig_imageFetch a bitmap stored inside the .fig: pass `hash` (the 40-hex image id reported by fig_node / fig_style on an image paint), or `guid` to take the image(s) used by that node, or hash:"thumbnail" for the document preview. Small images come back as viewable image content; larger ones come back as metadata (mime, byte size, pixel dimensions) — give `savePath` to write the exact bytes to disk instead. NOTE: a .fig contains no rendered pictures of frames, only the bitmaps placed in image fills plus thumbnail.png, so this cannot screenshot a design.fig_blobReturn the raw bytes of one entry in the file's blob table. Vector geometry, glyph outlines and similar bulk payloads are stored there and referenced by index from fields such as `vectorData.vectorNetworkBlob` and `Path.commandsBlob` (fig_node reports these as `vector.networkBlob` / `vector.fillBlobs`). This server does not decode the vector-network format — you get the bytes, base64 or hex, truncated to maxBytes with a flag when longer.fig_renderRender a node — frame, component, instance, group, shape, text, or a whole page — to a PNG the model can look at, or to SVG. Fully offline: geometry, text outlines and images all come from the file. Rendering is best-effort: read `approximated` and `unsupported` in the report before trusting fine details; exact values remain available from fig_node / fig_style / fig_text. Default output is PNG at 2x, capped to 1568 px on the longest edge; use `savePath` to write a file instead of inlining it.
Genable tools 39
jsxCreate 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.inspectRead 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.editBatch 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_jsxRead 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_jsxUpdate 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) atomicallyfind_nodesSearch 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 subtreediscover_propsDiscover 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 pagereplace_propsBulk 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_nodeDelete 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_nodeRelocate 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 parentclone_nodeDeep-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_variablesList 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 on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Figme
{
"mcpServers": {
"figme": {
"command": "npx",
"args": [
"-y",
"figme-mcp"
]
}
}
}
Genable
{
"mcpServers": {
"musepy-genable": {
"command": "npx",
"args": [
"-y",
"genable-mcp"
]
}
}
}
Frequently asked questions
Figme is categorized under Architecture & Design and uses a local stdio subprocess. Genable belongs to Architecture & Design and uses a local stdio subprocess. Pick Figme for architecture & design work and Genable for architecture & design.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Figme has no declared pricing — check the project's own site. Genable is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add figme and musepy-genable as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Figme has a quality signal of 59/100 (Good) with 1 views, 0 installs and 3 GitHub stars. Genable has 60/100 (Good) with 6 views, 0 installs and 3 GitHub stars.