Skip to main content
Glama

search

Find layer names and full text in saved Figma files or prepared workspace indexes, with ranked results, exact node refs, and coverage/page state.

Instructions

Ranked search of layer names and full text in one stored scope, including instance text overrides, text/boolean properties and nested swaps as REST nodes resolve them. Each result has an exact ref {sourceId, snapshotId, nodeId} (instance sublayer IDs work with inspect/nodes/export), origin stored or instance-effective, textSource, page, scopeRoot (a navigation container, not a screen claim), path, and matches with reasons and UTF-16 spans. coverage says whether the scope was fully indexed (ready) or a work limit stopped it (partial, totalRecords null); hasMore/nextCursor page the same candidates. Hidden layers and internal pages are excluded unless requested. Give file to read and hash that .fig now (nothing is written), or workspaceId to rank the workspace's prepared indexes of exactly this scope across its sources as one corpus (sourceId narrows it, refs keep each source's sourceId); a workspace search never builds: sources without a ready index are listed in sources with state pending, not_prepared, stale, incompatible or unreadable and the nextSteps index call, and coverage then says partial.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search"
  }
}

Input Schema

NameRequiredDescriptionDefault
cropNo{x, y, width, height} in whole pixels of the query image (of the stored 256-pixel render for imageRef)
fileNothe saved .fig to read now: a local path or gs://bucket/object; give file or workspaceId
modeNotext (default); semantic or hybrid with a configured local model (see models); with image or imageRef, visual (default without query) or hybrid (default with query: image plus text channels)
nodeNostored scope root; default the document; narrow it when coverage is partial0:0
typeNoFigma node types to keep, comma-separated, e.g. TEXT or TEXT,INSTANCE
imageNowith workspaceId: a local PNG (at most 8 MiB, 4 MP) inside the server's roots to search by; read for this call only, never stored or sent anywhere. Not with imageRef
limitNo1-200 results per page, default 20; independent of indexing work limits
queryNowords or a phrase; case, width and accents fold, CJK matches by character pairs or a single character; no regex. Required unless image or imageRef is given
cursorNonextCursor from the previous page of the same query, filters and snapshot; a workspace cursor lasts one hour (then cursor_expired)
storageNoabsolute custom storage directory, only for a workspace kept outside the default storage; must be under the server's --storage-root
imageRefNowith workspaceId: {sourceId, snapshotId, nodeId} of a node in a search result, to search by its stored render; the snapshot must still be the source's current one. Not with image
sourceIdNowith workspaceId, search only this registered source
workspaceIdNows_... from the index tool: search its prepared indexes instead of reading a file
includeHiddenNoalso return hidden layers and instance copies hidden by overrides or properties
includeInternalNoalso return layers on Figma's internal-only page

Output Schema

NameRequiredDescriptionDefault
queryYesthe query as given, its normalized phrase, mode and the whole tokens actually searched; an image search adds image (kind path|bytes|ref and crop, never the path), requestedMode and usedModes (text, semantic, visual_hash, visual_exact, visual_embedding)
scopeNo
stateNoworkspace searches: ready, pending or not_prepared
sourceNosourceId (opaque, from this path), snapshotId (sha256 of the exact .fig bytes decoded) and freshness: file-stamp reuse, not a per-query disk hash
hasMoreYes
rankingNoranking and tokenizer versions, field weights and tie order; an image search names its fusion (visual-rrf-1), channels and candidatesPerChannel
resultsYesranked rows; in an image search each match names its basis (lexical, semantic, normalized_pixels, perceptual_hash, visual_embedding) and each row has visual {state rendered|failed|absent, bounds, diagnostics, diagnosticsTruncated, error}
sourcesNoworkspace searches: each visible source's sourceId, state, snapshotId, freshness and active job
coverageYescomplete, scannedRecords, totalRecords (null unless complete), layers.text.state ready|partial, layers.visual in image searches (hash and embedding state per source, ready|partial|pending|building|failed|stale|unavailable, and the approximate signal), layers.semantic in semantic and hybrid modes (state ready|partial|pending|unavailable, profileId, counts, reasons; workspace searches per source), layers.relations (per kind: ready or partial when built; stateless search builds contains, instance_of and variant_of and lists the others not_built, which says nothing about absence; library_identity relation_unavailable), reasons with counts, excluded hidden/internal matches, knownGaps and work limits
nextStepsNoworkspace searches: the index or jobs calls that make more sources ready
nextCursorYes
workspaceIdNoworkspace searches only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.3

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares read-only behavior ('nothing is written'), discloses that a workspace search never builds and lists sources as pending/not_prepared/stale/incompatible/unreadable with a nextSteps index call, explains coverage ready vs partial with totalRecords null, and describes paging via hasMore/nextCursor. These are non-obvious operational traits an agent could not infer from the schema.

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?

The purpose is front-loaded in sentence one, but the second sentence is a single sprawling run-on that packs refs, coverage, paging, mode selection, and workspace fallback into one block. Every claim is substantive, yet the lack of separation makes it hard to scan; structure is the weak point.

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 15-parameter tool with no annotations, the description covers input branches, mutation safety, index-state failure modes, pagination, and the shape of returned refs and coverage. Nothing material for correct invocation appears missing, even though an output schema also exists.

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 cross-parameter meaning the schema does not: file vs workspaceId are alternatives, sourceId narrows a workspace corpus while refs keep each source's sourceId, and node can be narrowed when coverage is partial. It also warns that scopeRoot is 'a navigation container, not a screen claim', clarifying an output field's semantics.

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?

Opens with a specific verb+resource+scope: 'Ranked search of layer names and full text in one stored scope', and enumerates what is searched (instance text overrides, text/boolean properties, nested swaps). It does not explicitly distinguish itself from the sibling 'find', but the described scope is specific enough that an agent knows what this tool returns.

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

Usage Guidelines4/5

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

Gives explicit branch conditions: 'Give file to read and hash that .fig now (nothing is written), or workspaceId to rank the workspace's prepared indexes', plus 'sourceId narrows it' and 'narrow it when coverage is partial'. It states exclusions for hidden/internal content and that a workspace search never builds indexes. It stops short of naming a sibling alternative (e.g. find) for exact-match lookups.

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