Skip to main content
Glama
southleft

figma-console-mcp

by southleft

figma_get_library_component_by_key

Retrieves property definitions, variants, and visual specs for a published Figma library component from its component key, so you can inspect it before instantiating without the source file URL.

Instructions

Get full property definitions, variants, and visual specs for a SINGLE published library component using only its component key.

USE THIS when you have a component key (the 40-char hex returned by figma_search_components, figma_get_library_components, or search_design_system) and want to inspect what properties/variants it exposes before instantiating it — without first needing the source library file's URL.

RESOLVES: componentKey → file_key + node_id → componentPropertyDefinitions + variants + visualSpec.

WORKFLOW:

  1. Pass the componentKey from search results

  2. Tool tries /v1/component_sets/{key} first (most common case — buttons, inputs with variants)

  3. On 404 falls back to /v1/components/{key} (standalone components)

  4. Fetches the parent COMPONENT_SET at depth=2 to read componentPropertyDefinitions and per-variant visual data

  5. For COMPONENT_SET keys, also fetches the source file's /components list to map each variant's node to its published variant key (needed for figma_instantiate_component)

REQUIRES FIGMA_ACCESS_TOKEN with library_assets:read and files:read scopes.

Input Schema

NameRequiredDescriptionDefault
formatNo'full' returns properties + variants + visual specs. 'summary' returns properties + variant names only (no visualSpec). Auto-downgrades to 'summary' on large responses.full
componentKeyYesThe component key (40-char hex string from search results, e.g., '806826503bbd2ab15d0ff77d076a9406a5a83197'). Works for both COMPONENT_SET and standalone COMPONENT keys.
includeVisualSpecsNoInclude per-variant visual specs (fills, strokes, padding, typography). Default true. Auto-stripped if response exceeds 500KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4.5/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 behavioral burden and does so thoroughly: it documents the componentKey-to-file/node resolution, the /component_sets vs /components fallback on 404, depth=2 fetching, extra variant-key mapping for COMPONENT_SET keys, and required OAuth scopes.

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

Conciseness5/5

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

The description is front-loaded with purpose, followed by clear USE THIS, RESOLVES, WORKFLOW, and REQUIRES sections. Despite its length, every section adds actionable information for invoking the tool correctly.

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 read-only component-inspection tool with no annotations and no output schema, the description is complete enough: it explains the return shape (properties, variants, visualSpec), the resolution path, fallback behavior, auth requirements, and how the result supports instantiation.

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 the input schema already defines componentKey, format, and includeVisualSpecs clearly. The description adds useful context about where componentKey comes from and what the resolved output contains, but it does not significantly extend parameter semantics beyond the schema.

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 states a specific verb and resource: retrieving full property definitions, variants, and visual specs for a SINGLE published library component by key. It clearly distinguishes this from search/list tools by emphasizing component-key-only lookup and avoids ambiguity with URL-based lookups.

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?

It explicitly says to use this tool when you have a component key from search results and want to inspect properties/variants before instantiating, without needing the source library file URL. It names where keys come from but does not explicitly clarify when to use this versus sibling inspection tools such as figma_get_component_details.

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