Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
fig_overviewA

Open 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_treeA

List 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_nodeA

Inspect 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_findA

Search 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_textA

Extract 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_styleA

The 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_componentsA

List 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_instanceA

Explain 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_variablesA

List 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_imageA

Fetch 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_blobA

Return 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_renderA

Render 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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 12 tools

Disambiguation4/5

Each tool targets a distinct concern: overview, tree, node, find, text, style, components, instances, images, blobs, render, variables. The only mild overlap is fig_node vs fig_style (both inspect a single node) and fig_image vs fig_blob (both fetch raw bytes), but descriptions clarify the different purposes.

Naming Consistency4/5

All tools share the fig_ prefix and use lowercase snake_case, which is consistent. The verbs are mostly clear (overview, tree, node, find, text, style, components, instance, image, blob, render, variables), though fig_overview is a noun-ish name rather than a verb_noun pattern like fig_list_pages or fig_get_overview.

Tool Count5/5

12 tools is well-scoped for a Figma file inspection server. Each tool covers a distinct aspect of the domain: navigation, inspection, text extraction, style extraction, components, instances, images, blobs, and rendering. No tool feels redundant or unnecessary.

Completeness4/5

The server covers the read-only Figma file inspection domain thoroughly: overview, tree navigation, node lookup, search, text extraction, style extraction, components, instances, images, blobs, and rendering. Minor gaps include no direct way to list all pages as a standalone tool (only via fig_overview) and no tool for comparing two nodes, but these are workarounds.

Maintenance

ActivityMaintained
ResponsivenessNo issues