Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Convert to component

figma_convert_to_component
Idempotent

Turn an existing node (usually a frame) into a reusable COMPONENT, keeping its properties and children — the toolbar's Create component. The result has its own id (returned).

Instructions

Turn an existing node (usually a frame) into a reusable COMPONENT, keeping its properties and children — the toolbar's Create component. The result has its own id (returned). A node that is already a component, or sits inside a component or instance, cannot be converted. To place copies afterwards use figma_create_instance. Editors: Design; unverified: Slides.

Input Schema

NameRequiredDescriptionDefault
nameNoComponent name. Defaults to the node's name.
forceNoOverwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.
nodeIdYesThe node to convert.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
descriptionNoWhat the component is for — shown in the assets panel and Dev Mode.
idempotencyKeyNoCaller-owned retry key, ≤128 chars. Re-calling with the same key never executes twice: it returns the existing result, or waits for the op still in flight. Supply your own for anything large — if the MCP client times out (rather than the bridge), only a key you chose can be used to retry safely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Overwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.",
+  "type": "boolean"
+}
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds useful behavioral detail: the conversion keeps the node's properties and children, returns a new component id, and cannot run on nodes already inside components or instances. It does not cover permission or stale-edit failure handling, but the force parameter's schema description does.

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 the core operation and then efficiently layers in constraints, the relevant sibling tool, and editor availability. Every sentence carries useful information.

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 without an output schema, the description compensates by noting that the result id is returned. It also covers conversion constraints, the next-step sibling, and editor scope, leaving little an agent needs to know before calling it.

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 both required and optional parameters are already documented. The description does not add parameter-specific semantics beyond the schema; its mention of the returned id is output context rather than parameter guidance.

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: 'Turn an existing node (usually a frame) into a reusable COMPONENT.' It distinguishes the operation from sibling tools like figma_create_instance by naming that tool for placing copies afterward.

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?

It gives explicit when-to-use context ('existing node, usually a frame'), when-not conditions ('already a component, or sits inside a component or instance, cannot be converted'), and points to figma_create_instance for the follow-up copy step.

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