Skip to main content
Glama
Sign In
LeoGCode

figma-reader-mcp

by LeoGCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

figma_get_tree

Read-only

Get a compact outline of a Figma file's layer tree from a local .fig or figma.com URL, showing IDs, types, names, sizes, and hints to inspect structure and choose nodes.

Instructions

Compact outline of the layer tree (id, type, name, size, hints such as ready for dev). Omit node_id for all pages. The first line is a header, '# ' followed by a JSON object holding its date (see below); the outline starts on the second line. max_nodes goes to one level before the next (pages, then top-level layers, then what is under them), so a large first section cannot crowd out later pages. A branch cut short ends in a '- ... N more children' line, a layer whose children were all left out says '(N children)', and the last line says it was truncated; when a level could not give each of its layers one line, it is left out whole and the last line says so instead: 'level 2 not shown: 40 layers have children, 30 of 400 lines left; open one with node_id, or pass max_nodes 450' (levels counted as depth counts them). A layer drawn only with vector shapes, however they are grouped, is one line counting them all, '(27 vectors)': pass its node_id to open it. Dated by exportedAt and account, or fileModifiedAt for a file read from disk, as the server's instructions say (figma-reader help on the command line).

Input Schema

NameRequiredDescriptionDefault
fileYesA local .fig path, a Figma file key or a figma.com/design/... URL (see the server's instructions, or figma-reader help)
depthNoLevels of children below the start node (default 2). With no node_id the start is the document, whose pages are level 0, so the default shows three: pages, their top-level layers, and one level under those
node_idNoStart node id like 12:34 (or 12-34)
refreshNoExport the live file again rather than read a local or cached copy (see the server's instructions, or figma-reader help)
max_nodesNoLines to spend (default 400), a level at a time: a level that does not fit is shared evenly between its parents, and the levels under it are not shown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.2
    • changedInput schema / properties / file / description
      Previous value: -"Path to a local .fig file, or a Figma file key / figma.com/design/... URL. A node-id in the URL is used when this tool takes node_id and it is omitted; a tool that answers about the whole file ignores it. A key or URL uses a local '<name> [<key>].fig' from FIGMA_FILES_DIRS when one exists, otherwise exports through the browser."New value: +"A local .fig path, a Figma file key or a figma.com/design/... URL (see the server's instructions, or figma-reader help)"
    • changedInput schema / properties / max_nodes / description
      Previous value: -"Default 400"New value: +"Lines to spend (default 400), a level at a time: a level that does not fit is shared evenly between its parents, and the levels under it are not shown"
    • changedInput schema / properties / refresh / description
      Previous value: -"Skip local/cached copies and export the live file through the browser. Has no effect when file is a path to a .fig: that file is read as it is on disk and the result carries refreshIgnored; pass the key or URL to export the live file instead."New value: +"Export the live file again rather than read a local or cached copy (see the server's instructions, or figma-reader help)"
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint/openWorldHint, yet the description discloses a great deal more: the header line format and its dating source, the exact truncation markers ('- ... N more children', '(N children)'), the level-dropping message with a worked example, and the vector-collapsing rule. This is unusually rich output-shape disclosure for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded and information-dense, but the truncation and dating sentences are tangled run-ons, and it defers to external material ('as the server's instructions say (figma-reader help on the command line)') for a core concept. Every sentence carries content, but the packaging could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining the return shape, and it does so thoroughly — header line, per-layer outline format, three distinct truncation signals, and vector grouping. An agent knows what it will receive and how to interpret a cut-off result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics on top: max_nodes is spent a level at a time so 'a large first section cannot crowd out later pages,' and depth is counted with pages at level 0. That clarifies allocation behavior the schema only partially captures.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific verb and resource ('Compact outline of the layer tree') and enumerates the fields it emits (id, type, name, size, hints). An agent can tell it produces a summary view rather than a full node dump, but no sibling (e.g., figma_get_node, figma_locate) is named to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditional parameter guidance ('Omit node_id for all pages') and hints at escalation ('pass its node_id to open it'), implying figma_get_node for detail. However it never states plainly when to reach for this tool versus figma_get_node, figma_locate, or figma_search, leaving the routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools