Create slides

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world, but the description adds what annotations cannot: slides are created empty, the background fill must live on the slide because rows/grid carry no fill, all positions are validated atomically before the first slide is created, and it notes the editor restriction ('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.

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

Front-loaded with purpose and workflow, then item semantics, return shape, and alternatives — a logical order with no filler. It is dense and slightly run-on in the 'Per item:' passage, and one clause is restated from the schema, but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description states what is returned (each slide's id, row, col and index as read back), and it covers permissions, atomic validation, workflow chaining and sibling alternatives. Nothing an agent needs to invoke this correctly is missing.

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

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

With 67% schema coverage, the description meaningfully compensates: it explains that `row`/`col` are counted against the grid left by earlier items in the same call, that omitting both appends to the end of the deck, and that on an empty deck the first slide creates row 0 — semantics the schema only hints at. It also disambiguates `skipped` and the hex `background` placement. Minor overlap with the schema's own wording on row-count behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb, resource, cardinality and dimension: 'Add 1–20 empty 1920×1080 slides to a Figma Slides deck, in list order.' It explicitly distinguishes itself from figma_create_frame, figma_move_slides and figma_set_slide_grid, 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.

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

Gives the full intended workflow (create slides, then feed each via figma_create_from_spec with parentId = slide id, then verify with figma_check_layout at 3–5 slides per call) plus explicit exclusions and the sibling to use for each alternative case. It even states the anti-pattern to avoid ('Do not delete and rebuild slides to restyle a deck').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.