Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create stickies (FigJam)

figma_create_stickies
Idempotent

FigJam sticky notes, one idea each, 1–200 in one call, laid out as a grid from their REAL sizes: a sticky is 240 wide (416 with wide) and grows taller with its text, so rows are placed after the text is in and never overlap.

Instructions

FigJam sticky notes, one idea each, 1–200 in one call, laid out as a grid from their REAL sizes: a sticky is 240 wide (416 with wide) and grows taller with its text, so rows are placed after the text is in and never overlap. color: white, gray, green, teal, blue, violet, pink, red, orange, yellow, or a hex — names land on FigJam's exact swatches. The size is fixed: no width or height; use wide for about 100 words or more. columns per row (default one row), gap (default 64). Prompts, labels and instructions are text, not stickies. The parent is never resized: parentOverflow says how far the block runs past it (then figma_fit_sections). Returns created [{ index, id, x, y, width, height }] and bounds. Editors: FigJam only, unverified.

Input Schema

NameRequiredDescriptionDefault
xNoLeft edge, in the parent's coordinates. Default: below what the parent holds; on the page, right of its content.
yNoTop edge, in the parent's coordinates.
gapNoSpace between stickies, px. Default 64.
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.
columnsNoItems per row. Default: all in one row.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
parentIdNoA section or frame to put it in (id or Figma link). Default: the current page.
stickiesYes
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
Behavior5/5

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

Beyond annotations, it explains layout behavior: grid placement from real sticky sizes, no overlap because rows are placed after text is applied, fixed size with no width/height, and the parent is never resized. It also discloses the return shape (`created [{ index, id, x, y, width, height }]` and bounds), which annotations alone do not cover.

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?

The key constraints are front-loaded and the dense prose is mostly information-bearing. It is longer than necessary because it repeats some schema-provided defaults, but it remains structured and readable.

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?

There is no output schema, so the description appropriately explains the return value and bounds. It also covers the important parent-overflow behavior, FigJam-only scope, layout rules, and size constraints, making it complete for correct invocation.

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 already 89%, so the schema carries most parameter meaning. The description adds useful semantics beyond the schema, such as color names landing on exact FigJam swatches and `wide` being for about 100 words or more, while also repeating some schema defaults like `columns` and `gap`.

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: create FigJam sticky notes, one idea each, 1–200 per call, laid out as a grid. It also distinguishes stickies from text-based annotations by saying prompts, labels, and instructions are text, not stickies.

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 gives explicit context: FigJam only, use `wide` for about 100 words or more, and use `figma_fit_sections` when `parentOverflow` occurs. It also says prompts/labels/instructions should be text rather than stickies, but does not name the specific text-creation sibling, so the alternative routing is slightly implicit.

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