Skip to main content
Glama
Sign In
LeoGCode

figma-reader-mcp

by LeoGCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

figma_get_components

Read-only

Retrieve all components and variant sets from a Figma file, plus library components used, with instance counts for each.

Instructions

The components this file defines, and the library components it uses. componentSets are the variant sets, with their description, property definitions and one entry per variant carrying that variant's counts; components are the ones outside a set, each with a size and its own counts. A count is instances placed directly, plus swapInstances where the component is swapped into an instance (by an override or an instance-swap property). libraryComponentsUsed is a third list: components defined in other files, by name, with the variants used and the same two counts. Internal-only pages are left out of all three lists but not out of the counts: an instance placed on one still counts for the component it is of, except for a library component, whose uses on such a page are skipped. 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)
queryNoCase-insensitive filter on name; a component set matches when the set or any of its variants does
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

A3.6/5.0
Behavior4/5

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

With readOnlyHint=true already covering the safety profile, the description adds genuinely non-obvious behavior: exactly what a 'count' means (direct placements plus swapInstances), how internal-only pages are excluded from the lists but not from the counts, and the exception for library components on those pages. It also discloses how results are dated (exportedAt/account, or fileModifiedAt for disk reads).

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 with the resource definition, but the middle is dense and hard to parse, packing count semantics, page exclusions and a nested exception into single sprawling sentences. The final dating sentence is convoluted and defers to external docs rather than stating the rule, costing clarity for a paragraph that should be tighter.

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

Completeness4/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 burden of explaining the return shape, and it does so thoroughly for all three lists plus count semantics and exclusions. What is missing is any usage/routing context against the many sibling read tools, and the dating sentence is incompletely specified in-place.

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 file, query and refresh are already fully documented in the schema (including query's case-insensitive set/variant matching rule). The description adds nothing parameter-specific, so the baseline 3 is appropriate.

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

Purpose5/5

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

The first sentence states a specific resource and scope: the components a file defines plus the library components it uses. It then breaks that resource into three named lists (componentSets, components, libraryComponentsUsed), which unambiguously separates it from siblings like figma_get_styles, figma_get_variables and figma_get_tree.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of when to prefer this over figma_get_tree/figma_get_node, and no statement of prerequisites or the effect of the refresh/query parameters on workflow choice. The only routing hints are indirect references to 'the server's instructions', which push guidance out of the description entirely.

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