Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create frame

figma_create_frame
Idempotent

A frame — the building block for structure. Build designs step by step: one frame per section, row or card, each with auto-layout (layout, gap, padding, alignX/alignY), then add content into it by parentId.

Instructions

A frame — the building block for structure. Build designs step by step: one frame per section, row or card, each with auto-layout (layout, gap, padding, alignX/alignY), then add content into it by parentId. An auto-layout frame hugs its content on any axis you give no size for; sizing: { horizontal: "fill" } makes it take its parent column's width. A wrapping row (wrap) spaces its rows by rowGap (default: the gap). Content is not clipped unless clipsContent: true. Name it for what it is. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
gapNoSpace between items, px.
nameNoWhat it is, e.g. "Header", "Pricing card".
wrapNoWrap items onto new lines (horizontal layout only).
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.
widthNoFixes the width. Omit to hug (auto-layout) — a plain frame defaults to 100.
alignXNoHorizontal alignment of the items.
alignYNoVertical alignment of the items. baseline (a row only) lines up text baselines, e.g. "$29 /mo".
heightNoFixes the height. Omit to hug (auto-layout).
layoutNoAuto-layout direction: horizontal = a row, vertical = a column.
rowGapNoSpace between wrapped rows, px. Needs wrap; default the gap.
sizingNoHow it sizes, as in Figma's panel: { "horizontal": "fill" } to take the parent column's width; "hug" fits content; "fixed" keeps the number.
paddingNoPadding: one number for all sides ("24"), or four comma-separated ("48,48,32,32") for top,right,bottom,left.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
parentIdNoDefaults to the current page (in Slides: the focused slide).
backgroundNoOmitted: transparent inside another frame, white directly on the page.
alignContentNoHow wrapped rows share the height. Needs wrap.
clipsContentNoClip children at the frame edge. Default false (shadows stay visible).
cornerRadiusNo
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.0
Behavior4/5

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

Annotations already declare write, idempotent, non-destructive, so the bar is lower; the description nonetheless adds real behavior: no clipping unless clipsContent (so shadows stay visible), auto-layout hugging on any unsized axis, sizing fill inheriting parent width, and rowGap defaulting to gap. It doesn't cover the STALE/force write-refusal semantics, which live only in 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.

Conciseness4/5

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

Front-loaded with the concept ('A frame — the building block for structure') then compressed to practical advice. Dense and mostly earns its space, though the mixed backtick-heavy phrasing and trailing editor caveat read slightly telegraphic.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 21-parameter creation tool with no output schema, the description supplies the layout model and composition workflow an agent needs to call it correctly. Gaps remain around returned identifiers/return shape and the force/idempotency interplay, but the core decision inputs are present.

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 86%, so 3 is the floor; the description earns an extra point by explaining cross-parameter logic the schema can't: layout+gap+padding+align as a unit, rowGap defaulting to gap under wrap, and sizing.horizontal='fill' taking the parent column's width. It doesn't touch a few parameters such as cornerRadius or background defaults.

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 names a specific verb+resource ('Create frame') and defines the frame's role as the structural building block. It's clearly distinguishable from siblings like create_rectangle or create_section by the auto-layout emphasis, but it never names those alternatives explicitly.

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?

Clear contextual guidance: 'one frame per section, row or card, each with auto-layout ... then add content into it by parentId' supplies a usage pattern, and the editor scope (Design; unverified FigJam, Slides) tells the agent where it applies. It stops short of explicitly stating when to use a plain shape or group instead.

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