Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Set slide properties

figma_set_slide_properties
Idempotent

Per slide of a Figma Slides deck: skipped (left out of the presentation, kept in the deck) and speakerNotes (the presenter's notes as markdown; "" clears).

Instructions

Per slide of a Figma Slides deck: skipped (left out of the presentation, kept in the deck) and speakerNotes (the presenter's notes as markdown; "" clears). Notes keep lists, bold, italic and strikethrough; headings, code and links stay literal text and earn a warning. Write notes only when asked or for a deck meant to be presented: short bullets that add to the slide, not a script. If this Figma build does not expose speaker notes, a call that sets them is refused before anything changes. Per-slide results. Slide names: figma_rename_node; backgrounds: figma_set_fills on the slide; transitions: figma_set_slide_transition. 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.9/5.0
Behavior5/5

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

Beyond annotations, it explains what `skipped` means operationally, how `speakerNotes` formatting is preserved or degraded with a warning, and that unsupported speaker-note writes are refused before any change. It also states return granularity ('Per-slide results') and editor applicability ('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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the two per-slide properties and their semantics, then covers markdown limits, note-writing guidance, refusal behavior, result granularity, sibling routing, and editor scope. Every sentence carries actionable information; none repeats annotations or schema descriptions.

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 nested mutation tool with no output schema, the description supplies the missing behavioral context: property meanings, markdown limitations, preflight refusal, per-slide results, and adjacent-tool routing. The remaining parameters (`force`, `session`, `idempotencyKey`) are fully documented in the schema, so an agent has enough to call this correctly.

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 75%, so the baseline is 3, but the description adds meaningful semantics absent from the schema for nested fields: `skipped` is defined as left out of presentation but kept in the deck, and `speakerNotes` formatting and clearing behavior are expanded. The top-level `force`, `session`, and `idempotencyKey` semantics remain schema-only.

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 specific resource (a slide in a Figma Slides deck) and the exact properties being set (`skipped` and `speakerNotes`). It also routes slide names, backgrounds, and transitions to sibling tools, so an agent can distinguish this tool from neighbors without opening schemas.

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?

It explicitly says when to write speaker notes: 'only when asked or for a deck meant to be presented', with a concrete style expectation ('short bullets... not a script'). It also names alternative tools for adjacent slide operations: figma_rename_node for names, figma_set_fills for backgrounds, and figma_set_slide_transition for transitions.

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