Skip to main content
Glama
AvYour

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a table (FigJam)

figma_create_table
Idempotent

Create a FigJam table for row-and-column data using rows or numRows plus numColumns, with header styling and custom dimensions, not a grid of shapes.

Instructions

A FigJam table — the tool for any row-and-column data, never a grid of shapes. Give rows (text, 1–100 rows of 1–20 cells, every row the same length; all of the user's data, no placeholders) or numRows + numColumns for an empty one: exactly one form. header (default true with rows) colours row 0 with headerColor, a table preset (default black: dark fill, white text): black, dark-gray, gray, light-gray, white, and green, teal, blue, violet, pink, red, orange, yellow each with a light- form (light-green, …), or a hex. fill colours the table; a fill is never removed ("" is refused). columnWidths / rowHeights resize; a column cannot shrink below its minimum, so the real widths come back. fontFamily, weight, fontSize apply to every cell. Cells have no ids: change them with figma_edit_table. Editors: unverified in FigJam, Slides.

Input Schema

TableJSON 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.
fillNoTable preset or hex.
nameNoLayer name.
rowsNoThe data, row by row; row 0 is the header.
headerNoStyle row 0 as a header. Default true with rows, false for an empty table.
weightNoFont weight as a number ("600") or a Figma style name ("Semi Bold" — Inter uses spaces, not "SemiBold").
numRowsNoAn empty table: with numColumns, not with rows.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
fontSizeNo
parentIdNoA section or frame to put it in (id or Figma link). Default: the current page.
fontFamilyNo
numColumnsNo
rowHeightsNoOne height per row, px.
headerColorNoHeader preset or hex. Default black.
columnWidthsNoOne width per column, px.
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. First observedv0.1.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly=false, idempotent=true, destructive=false, so the bar is lower, yet the description adds real behavior: fills are never removed ("" is refused), columns cannot shrink below their minimum so actual widths come back, and editors are unverified in FigJam/Slides. These are non-obvious constraints the agent needs, though permission/auth and return-shape behavior are not covered.

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 identification claim and the input-form rule, and every clause carries substance. It is dense and reads as one long run-on stream rather than a structured list, which slightly impairs scanning but wastes little.

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 17-parameter tool with no output schema, the description supplies validation rules, defaults, form exclusivity, and the edit handoff, which is substantial. It leaves positioning, naming, parenting, and session parameters to the schema, which is acceptable given 82% coverage.

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?

With 82% schema coverage the baseline is 3, but the description goes further than the schema by enumerating the header-color preset family (black, dark-gray, …, light-green) and explaining defaults and the rows-vs-numRows exclusivity. It adds genuine meaning for rows, header, fill, and sizing beyond the structured field 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?

The description names the resource precisely ("A FigJam table") and pins its scope with "the tool for any row-and-column data, never a grid of shapes," which distinguishes it from shape-based siblings like figma_create_shapes_with_text. Combined with the create verb in the name/title, an agent can identify exactly what this produces.

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 supplies an explicit when-not ("never a grid of shapes"), defines the two mutually exclusive input forms ("exactly one form"), and routes cell edits to figma_edit_table after creation. It stops short of naming all competing creation siblings, but the selection logic is clear.

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