Skip to main content
Glama

usages

Find exact inbound or outbound relations for a Figma node or resource—instances, variables, styles, images, prototype links, and library usage—within a stored file or prepared workspace scope.

Instructions

Exact relations of one node or resource in one stored scope, from the same effective index as search (nested instances and swaps included): direction in (default) lists the locations that point at it, out lists what it points at; with out, an instance_of, uses_style or binds_variable result whose cached library copy names it carries library {kind, namespace, key}, the selector the library argument takes. Relations: instance_of (instance to main component, recorded symbolData or resolved definition/swap), variant_of (component to its set; a COMPONENT_SET node also lists its known members and returns their instances with via), binds_variable (paint, effect and field variable bindings, local or library), uses_style, uses_image (a text range's style comes from the last row of its styleID, as REST nodes give it; its paint images and variables from the first such row with fills, as rendered), prototype_target (recorded transitions; never a claim that a flow is reachable) and contains (asked for explicitly). Every result keeps an exact ref {sourceId, snapshotId, nodeId}, relation, state (resolved, missing, unresolved, unsupported, external, recorded), basis (recorded or resolved), evidence, page, scopeRoot and path; names never establish identity. The definition may lie outside the scope; scope limits only the returned locations. No total is reported; coverage says complete or partial with reasons (work limits, hidden content not expanded, truncated members, library_identity unavailable), and nextCursor pages in a stable order (a workspace library cursor lasts one hour, then cursor_expired). Give file to read that .fig now (nothing is written), or workspaceId to read a source's prepared index of exactly this scope (never builds). Pass snapshotId from the ref you hold: another current snapshot is source_stale. With workspaceId, library {kind, namespace, key} instead of node or resource lists uses_library locations of that library component, style or variable across every visible source's prepared scope (basis cached_copy: the namespace comes from each file's cached copy); the definition stays unresolved (library_source_unproven) unless library.definition selects it by exact ref (selected, keyEvidence unverified), coverage lists each source's state and reasons (source_not_ready, index_partial, namespace_unknown, hidden_excluded, authorization_restricted), and snapshotId, relation and direction do not apply; its results carry ref, name, type, relation, basis, state, evidence, hidden, internal, page and scopeRoot but no path or origin.

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": "usages"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNothe saved .fig to read now: a local path or gs://bucket/object; give file or workspaceId
nodeNothe exact layer id, stored or an instance sublayer I...;...; give node or resource
limitNo1-200 results per page, default 50
scopeNostored scope root whose locations are returned; default the document; a workspace needs a prepared scope0:0
cursorNonextCursor from the previous page of the same query and snapshot
libraryNowith workspaceId, a library reference instead of a node or resource: {kind: component, style or variable, namespace, key}, as an out result's library names it; lists the layers in every visible source (or sourceId) whose cached copy records it. Optional definition {sourceId, snapshotId, nodeId} selects the definition by exact ref; without namespace only copies that record none are listed
storageNoabsolute custom storage directory, only for a workspace kept outside the default storage; must be under the server's --storage-root
relationNorelations to keep, comma-separated; default every one but contains
resourceNoa resource id instead of a layer: VariableID:..., StyleKey:... or image:<hash>
sourceIdNowith workspaceId, the source to read; needed when several have this scope; with library, narrows to that one consumer source
directionNoin (what points at it) or out (what it points at, with library {kind, namespace, key} on a use of a cached library copy)in
snapshotIdNothe snapshot your ref came from; a different current snapshot is source_stale
workspaceIdNows_... from the index tool: read its prepared index instead of the file
includeHiddenNoalso return hidden locations

Output Schema

NameRequiredDescriptionDefault
scopeNo
stateNoworkspace queries without a ready index: pending or not_prepared
sourceNosourceId and snapshotId; stateless calls add freshness
hasMoreYes
libraryNolibrary queries: the kind, namespace and key asked
membersNoCOMPONENT_SET queries: the known member ids and whether they are complete
resultsYesin: each location's ref, name, type, origin, hidden, page, scopeRoot, path, relation, state, basis, evidence and via (the member a set query matched); library queries: ref, name, type, relation, state, basis, evidence, hidden, internal, page and scopeRoot, no origin or path, plus definitionMatch when a definition is selected: equal (the use's cached copy has the selected definition's fingerprint on every facet; not proof the library published it), definition_mismatch (a facet differs) or unknown (a facet unread or unsupported, such as a field holding a file-local GUID, or no copy to compare); out: target ref or resource, its definition and the edge fields, plus library {kind, namespace (null with unknownReason when no copy records one), key, basis cached_copy} on an instance_of, uses_style or binds_variable use whose cached library copy names it: the selector a library query takes
coverageYescomplete, layers.relations kinds and version, reasons; library queries: complete, sources (sourceId, path, state, snapshotId, freshness when ready, nextSteps) and reasons; never a total count
directionNo
nextStepsNothe jobs or index call that makes the scope ready
relationsNo
definitionYeslibrary queries: state unresolved with a reason (library_source_unproven when none is selected), or selected with basis caller_ref, the selected ref and keyEvidence unverified; null while a workspace scope is pending or not_prepared; else ref or resource, state (indexed in scope, outside_scope, or the state of the edges that name it: missing, unresolved, external, recorded), name, type, setId and page when known
nextCursorYes
workspaceIdNoworkspace queries only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.3

TDQS

A3.9/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 discloses key behavior: file mode reads a .fig without writing, workspace mode reads a prepared index and never builds, coverage can be complete or partial with named reasons, cursors expire, snapshot mismatches return source_stale, and library mode has unresolved/selected states. It also explains result basis/state semantics and page/cursor behavior.

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 description is a very long run-on paragraph dense with semicolons and nested clauses, and much of it repeats schema parameter descriptions. It is front-loaded with the purpose, but the structure makes it hard to scan and could be substantially tightened or bulleted.

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?

Given 14 parameters, nested library selection, workspace/file modes, and an output schema, the description is complete enough for an agent to call it correctly. It covers edge cases, coverage reasons, snapshot staleness, cursor expiry, and library-mode restrictions.

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 still adds useful meaning beyond the schema by enumerating relation types, explaining direction behavior, and detailing library {kind, namespace, key} and exact-ref definition selection.

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 description states a specific operation: exact relations of one node or resource in a stored scope, with direction in/out and enumerated relation types. However, it only mentions search as the source of the index and does not explicitly distinguish this tool from siblings like find, tree, inspect, or search.

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 clear mode selection between file, workspaceId, and library usage, plus snapshot/cursor constraints. But it does not explicitly say when to choose usages over sibling tools such as search, find, tree, or inspect, leaving the main alternative-routing decision implicit.

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