Skip to main content
Glama
LeoGCode

figma-reader-mcp

by LeoGCode

figma_search

Read-only

Search Figma designs by layer name or text content, including text inside instances, with optional regex and node filters.

Instructions

Find nodes by name (and optionally text content). The query is a literal substring, case-insensitive unless case_sensitive: a name like Icons/Arrow/Left or /Card [v2]/ matches itself. Only regex=true reads it as a pattern, bare or /pattern/flags, and an invalid pattern is an error. With include_text, component instances are expanded, so strings that only exist as instance overrides or component property values are matched too, each tagged with via (direct/instance) and, where they apply, component, variant and frame. Name matching sees only real layers: layer names inside a collapsed instance live in its main component, so search that component instead. A hit's characters is a preview: longer text is cut to its first 120 characters followed by ... and flagged charactersTruncated (truncated, next to it, is about the number of results); figma_get_text returns the strings whole. When the text pass runs, unresolvedInstances counts the instances whose text could not be resolved and so was not searched (figma_get_text names the components); it is absent when the pass did not run. The result is dated by the copy it answers from. exportedAt is the ISO-8601 time this tool exported that snapshot through the browser: report what the design said then rather than as current, and pass refresh to export it again. For a local .fig the field is fileModifiedAt, that copy's own file time, which copying, syncing or re-downloading the file resets: the design data can be older than it says, and nothing here can date it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileYesPath 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.
pageNoRestrict to page name
limitNoDefault 50
queryYesName or text to find. A literal substring unless regex is set, so slashes and characters like [ ] ( ) . * match themselves
regexNoRead the query as a regex, bare or /pattern/flags, and report an invalid one. Default false: the query is a literal substring however it is written
typesNoNode types to match, e.g. FRAME, COMPONENT, INSTANCE, TEXT. A list without TEXT also turns include_text off, since every text hit is a TEXT node; an empty list is no filter at all
node_idNoSearch only this node and everything under it, like 12:34 (or 12-34); a node-id in the file URL is used when it is omitted
refreshNoSkip 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.
include_textNoAlso match text content, including text rendered inside instances
case_sensitiveNoMatch case (default false, for a regex too)
include_hiddenNoInclude text on layers hidden in the design (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true and openWorldHint=true, so the description carries the burden of behavioral disclosure. It does this thoroughly: it discloses that the result is dated by the snapshot copy (exportedAt vs fileModifiedAt), that refresh re-exports, that characters is truncated to 120 chars with charactersTruncated flag, that unresolvedInstances counts unresolved text, and that local .fig file times can be misleading. This is rich behavioral context beyond the annotations.

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

Conciseness4/5

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

The description is dense and information-rich, with the core purpose front-loaded in the first sentence. Every sentence adds meaningful behavioral detail. It is long, but the length is justified by the tool's complexity (11 parameters, subtle text-search semantics). A slight deduction for density: the paragraph on exportedAt/fileModifiedAt could be tightened, but it earns its place.

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?

For a tool with 11 parameters, no output schema, and only readOnly/openWorld annotations, the description is remarkably complete. It covers search semantics, regex behavior, instance expansion, truncation, result dating, refresh behavior, and error conditions (invalid regex). It also names sibling tools for follow-up (figma_get_text). Nothing critical is missing for an agent to select and invoke this tool correctly.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains the interaction between types and include_text ('A list without TEXT also turns include_text off'), the semantics of regex patterns (bare or /pattern/flags), and the meaning of via tags. It doesn't enumerate every parameter, but the schema already covers them; the description adds the non-obvious interactions.

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 description opens with a specific verb and resource: 'Find nodes by name (and optionally text content).' It immediately distinguishes the tool from siblings like figma_get_node and figma_get_text by stating it searches by name/text across nodes, and the rest of the description clarifies scope (literal substring vs regex, instance expansion). This is a clear, non-tautological purpose statement.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: it explains when regex=true is appropriate, when include_text is needed, and when to search a component instead of a collapsed instance ('Name matching sees only real layers... search that component instead'). It also names figma_get_text as the alternative for retrieving full strings, and figma_get_text for naming unresolved components. This is explicit routing to alternatives with conditions.

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