Skip to main content
Glama

Create slides

figma_create_slides
Idempotent

Add 1–20 empty 1920×1080 slides to a Figma Slides deck, in list order. Then give each its content with one figma_create_from_spec (parentId = the slide id), and check the batch with figma_check_layout — 3–5 slides per call.

Instructions

Add 1–20 empty 1920×1080 slides to a Figma Slides deck, in list order. Then give each its content with one figma_create_from_spec (parentId = the slide id), and check the batch with figma_check_layout — 3–5 slides per call. Per item: name, background (hex; it goes on the slide, since rows and the grid have no fill), skipped, and where: row + col, counted against the grid the earlier items left (row = the current row count opens a new last row), or neither for the end of the deck. On an empty deck the first slide makes row 0. Every position is checked before the first slide exists. Returns each slide's id, row, col and index as read back. Not for frames on a page (figma_create_frame); to reorder use figma_move_slides, to regroup figma_set_slide_grid. Do not delete and rebuild slides to restyle a deck: edit them in place. Editors: Slides only, unverified.

Input Schema

NameRequiredDescriptionDefault
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.
slidesYes
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
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.7/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the description needn't restate safety. It instead adds non-obvious behavior: 'Every position is checked before the first slide exists' (all-or-nothing validation, no partial writes), the returned fields ('id, row, col and index as read back'), and an editor scope caveat ('Editors: Slides only, unverified'). The concurrency/STALE behavior lives in the schema's force param rather than the description, which is the only minor gap.

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 core action and scope, and every sentence carries information. The middle section cramming per-item fields, placement rules and cross-tool workflow into one dense passage is harder to parse than it needs to be, but nothing is disposable.

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 a 4-parameter mutation tool with no output schema, the description covers what it creates, the batch limits, placement semantics, validation timing, the return shape, follow-up tools, alternatives and environment requirements. An agent has everything needed to call it correctly and to know what comes next.

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?

Well beyond the 75% schema coverage: it explains that `row` is counted against the grid left by earlier items and that 'the current row count opens a new last row', that omitting both row and col appends to the end of the deck, and that on an empty deck the first slide makes row 0. It also justifies `background` placement ('it goes on the slide, since rows and the grid have no fill'), which the schema does not convey.

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 with hard scope: 'Add 1–20 empty 1920×1080 slides to a Figma Slides deck, in list order.' It also explicitly distinguishes itself from figma_create_frame (frames on a page), figma_move_slides (reorder) and figma_set_slide_grid (regroup), so an agent can route correctly without opening any 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?

Gives the full workflow: create the empty slides here, then fill each via figma_create_from_spec with parentId = slide id, then verify with figma_check_layout at 3–5 slides per call. It also names exclusions ('Not for frames on a page') and a negative pattern ('Do not delete and rebuild slides to restyle a deck: edit them in place'), which is exactly the when/when-not guidance the dimension asks for.

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