Magic MCP vs Figme

Magic MCP tools

No tool names declared yet. Check the project README from the listing page.

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.