Skip to main content
Glama
Sign In
LeoGCode

figma-reader-mcp

by LeoGCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

figma_load_file

Read-only

Load a Figma file from a local path, key, or URL to return a summary of pages, nodes, variables, styles, and components. Cached snapshots allow other tools to reuse the data.

Instructions

Export (Save local copy) and decode a Figma file, returning a summary: pages, node counts, variable collections, styles, components. Snapshots are cached; other tools reuse them. Export of large files can take a minute. For a snapshot exported through the browser, snapshotPath is its .fig in the cache, which the next export of the key replaces. Read by that path, it is never exported again, but it is dated fileModifiedAt and names no account like any local file: for a task's calls keep passing the key, and say so if exportedAt changes between them. 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)
refreshNoExport the live file again rather than read a local or cached copy (see the server's instructions, or figma-reader help)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 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 / 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

B3.4/5.0
Behavior4/5

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

Annotations only cover readOnlyHint and openWorldHint, yet the description adds real behavioral context: caching and reuse by other tools, a stated latency risk ('can take a minute' for large files), and snapshot replacement semantics. This goes well beyond the annotations, though the later sentences are garbled and hard to act on.

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

Conciseness2/5

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

The opening sentence is strong and front-loaded, but the following run-on sentences drift into confusing digressions about snapshotPath, exportedAt, fileModifiedAt and account dating. It is over-long and the trailing clause adds ambiguity rather than information.

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

Completeness3/5

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

For a tool whose snapshot/caching semantics are genuinely complex, the description does attempt to cover export vs cache-read and dating, but it repeatedly outsources the authoritative rules to external docs and ends on an unclear note. With no output schema, it should be self-sufficient, and it is only partly so.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description elaborates on caching/replacement behavior but also introduces 'snapshotPath', which is not a parameter in the schema, creating mild confusion, and it never names the actual 'refresh' parameter or explains its default.

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 first sentence gives a specific verb+resource ('Export and decode a Figma file') and even enumerates the returned summary (pages, node counts, variable collections, styles, components), which is more specific than most siblings. It implies its role as the file-level entry point that other tools draw from, but never explicitly contrasts itself with figma_get_tree or figma_get_node.

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?

'Snapshots are cached; other tools reuse them' hints that this is the load-first step and the refresh parameter controls re-export, so usage is implied. However, there is no explicit when-to-use / when-not / alternative guidance, and the reader is repeatedly deferred to 'the server's instructions' or 'figma-reader help' rather than given the rule inline.

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