Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Move slides

figma_move_slides
Idempotent

Move slides within a Figma Slides deck as one block, in the order given, to exactly one anchor: after or before another slide (afterSlideId / beforeSlideId), or into a row (row, optional col, both counted once the moved slides are…

Instructions

Move slides within a Figma Slides deck as one block, in the order given, to exactly one anchor: after or before another slide (afterSlideId / beforeSlideId), or into a row (row, optional col, both counted once the moved slides are taken out; row = the row count opens a new last row). An anchor that is itself being moved is refused before anything changes. Every slide stays in the deck; a row the move empties stays as an empty section and is listed in emptiedRows. Per-slide results with the new row, col and index. To restate the whole deck's grouping use figma_set_slide_grid. Editors: Slides only, unverified.

Input Schema

NameRequiredDescriptionDefault
colNoWith `row`: their position in it; default its end.
rowNoPut them in this row (section); the row count opens a new last row.
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.
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
slideIdsYesThe slides to move, in the order they should end up.
afterSlideIdNoPut them right after this slide.
beforeSlideIdNoPut them right before this 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.8/5.0
Behavior5/5

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

Annotations already declare non-readonly, idempotent, non-destructive; the description adds real value beyond them: an anchor that is part of the moved set is refused before anything changes (validate-before-write), slides are never removed from the deck, emptied rows persist as empty sections and are reported in `emptiedRows`, and results are per-slide with new row/col/index. It also discloses the permission requirement ("Editors: Slides only, unverified").

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 action and scope, and every clause carries information (anchor modes, atomicity, emptied rows, return shape, alternative tool, permissions). It is packed into one dense paragraph with nested parentheticals, which costs some scannability.

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?

For an 8-parameter mutation with no output schema, the description covers the anchor model, ordering, indexing basis, atomic validation, no-data-loss guarantees, side effects (emptiedRows), return shape, and authorization scope. Nothing an agent needs to call it safely and correctly is missing.

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 baseline is 3, but the description adds semantics the schema does not: row/col are "counted once the moved slides are taken out" and "row = the row count opens a new last row", which is the non-obvious indexing behavior an agent would otherwise get wrong. It does not further explain `force`, `session`, or `idempotencyKey`, but those are already well documented in the schema.

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?

States a specific verb and resource ("Move slides within a Figma Slides deck") plus the key semantics: one block, in the given order, to exactly one anchor. It also names the sibling it is not (figma_set_slide_grid), so an agent can distinguish it without opening the schema.

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?

Explicitly enumerates the three mutually exclusive anchor modes (afterSlideId, beforeSlideId, row+col) and says "exactly one anchor", which excludes invalid combinations up front. It names the alternative tool and the condition that selects it: "To restate the whole deck's grouping use figma_set_slide_grid."

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