Skip to main content
Glama

Edit a table (FigJam)

figma_edit_table
DestructiveIdempotent

Change a FigJam table's structure and cells. Cells have no ids: they are { row, column }, 0-based. Applied in this order, every index checked against the table's size before anything changes: removeRows / removeColumns (their content is…

Instructions

Change a FigJam table's structure and cells. Cells have no ids: they are { row, column }, 0-based. Applied in this order, every index checked against the table's size before anything changes: removeRows / removeColumns (their content is lost), then insertRowsAt / insertColumnsAt (positions in the table after removals; each adds one before that index, the count appends), then moveRow / moveColumn { from, to }, then columnWidths / rowHeights [{ index, width | height }], then cells (up to 2000, in the final table): text, fill (table preset or hex; "" is refused — give "#FFFFFF" to reset), textColor. Removing every row or column is refused. Returns the new size and per-cell results. Editors: unverified in FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
cellsNo
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 TABLE.
moveRowNo
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
moveColumnNo
removeRowsNo
rowHeightsNo
columnWidthsNo
insertRowsAtNo
removeColumnsNo
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.
insertColumnsAtNo

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?

Goes well past the annotations: it discloses the atomic index-validation guarantee ('every index checked against the table's size before anything changes'), that removed rows/columns lose content, the 2000-cell cap, that empty-string fill is refused, and what is returned. The closing note 'Editors: unverified in FigJam, Slides' adds platform caveat context, though it is vague about what 'unverified' actually means for the caller.

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 before the dense ordering sentence, and every clause (ordering, atomicity, remove-everything refusal, empty fill refusal, return shape) carries non-redundant information. The operation-order sentence is a long chain of 'then ... then' that takes effort to parse, but nothing in it is filler.

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 13-parameter, nested-object mutation tool with no output schema, the description covers execution ordering, atomicity, limits, refusal conditions and return shape. The main remaining ambiguity is the trailing 'Editors: unverified in FigJam, Slides' note, which leaves unclear whether the tool is supported in Slides tables at all.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 31% schema description coverage across 13 parameters, the description carries the load and does so: it explains that cells have no ids and are 0-based {row, column}, that insert positions refer to the table *after* removals and append at the row count, the {from, to} shape for moves, and the {index, width|height} shape for sizing. force, session and idempotencyKey are already documented in the schema, so the remaining gap is minimal.

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?

Opens with a specific verb+resource ('Change a FigJam table's structure and cells') and then enumerates exactly which structural operations are supported, which cleanly separates it from the create-side sibling figma_create_table. It never names the create/delete alternatives explicitly, but the scope is unambiguous from the first sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the operation list and refusal rules ('Removing every row or column is refused'), so an agent can infer the domain of valid edits. However, there is no guidance on when to prefer this tool over figma_create_table or figma_set_text for cell content, and no statement of prerequisites (must be a FigJam table node).

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