Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create from spec

figma_create_from_spec
Idempotent

Build a whole SECTION in one call (one undo step): a header, hero, card, grid of cards or footer — frames with auto-layout, text, shapes (rectangle, ellipse, polygon, star, line, vector path), SVG icons, images by URL, components and…

Instructions

Build a whole SECTION in one call (one undo step): a header, hero, card, grid of cards or footer — frames with auto-layout, text, shapes (rectangle, ellipse, polygon, star, line, vector path), SVG icons, images by URL, components and instances. To build anything new: a wrapper frame, then one call per section into it by parentId; after each, figma_check_layout and one figma_export_node, then targeted fixes. Not a whole page in one payload: a section at a time keeps every step checkable. The full spec grammar: figma_get_guide { topic: "spec" }. Minimal shape: { "type": "frame", "name": "Card", "layout": "vertical", "gap": 16, "padding": 24, "children": [ { "type": "text", "content": "Title", "fontSize": 20 } ] }. A field a type does not take is refused, never dropped. A mid-way failure does not roll back: created[] and failedAt say what exists. Supply your own idempotencyKey for a large spec. An array of roots (a slide's content) needs parentId or pageId. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
specYesThe node tree to build, as a JSON object serialised to a string (the tool description gives its grammar), or a JSON array of 1–50 such roots when parentId or pageId is given. Serialising it keeps the schema portable across providers — see docs/reference/tools.md.
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.
pageIdNoThe page to build on, at its top level, when no parentId is given. Not with parentId.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
parentIdNoWhere to attach it: a frame, section, slide or page. Defaults to the current page (in Slides: the focused slide).
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.6/5.0
Behavior4/5

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

Goes well beyond the annotations: one undo step, no rollback on mid-way failure, created[]/failedAt reporting, STALE-overwrite semantics reinforced via force, idempotencyKey retry behavior, and editor coverage (Design verified; FigJam/Slides unverified). Only the return payload shape is gestured at rather than described, keeping it short of a 5.

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?

Front-loaded with purpose and workflow, and the grammar pointer and minimal example earn their space. It is dense and the mid-sentence enumeration is long, but nothing is clearly redundant.

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?

No output schema exists, yet the description still tells the agent what a partial result looks like (created[], failedAt) and how to recover. Combined with workflow, grammar link, and editor caveats, an agent has everything needed to call this 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 coverage is 100%, so the baseline is 3; the description adds real value by pointing to the spec grammar doc and giving a minimal valid spec example with layout/gap/padding/children semantics. It reinforces parentId usage and idempotencyKey sizing advice beyond the schema text.

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?

Opens with a specific verb+resource+scope: 'Build a whole SECTION in one call', then enumerates exactly what it composes (frames with auto-layout, text, shapes, SVG, images, components). It also distinguishes itself from the granular siblings (figma_create_frame, figma_create_text, etc.) by emphasizing 'whole section', and from a whole-page build by 'Not a whole page in one payload'.

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?

Gives an explicit workflow: create a wrapper frame, then one call per section by parentId, then figma_check_layout plus one figma_export_node, then targeted fixes. It also names the grammar source (figma_get_guide topic: spec) and states the array-of-roots constraint (needs parentId or pageId), leaving little to inference.

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