Skip to main content
Glama

Remove a slide

slide_remove
Destructive

Delete a slide and all its content—separator, frontmatter, body, and notes—from an MDX deck; any stacked column is handed to the slide beneath it.

Instructions

Delete one slide (its separator, frontmatter, body and notes). A stack's top slide hands its column to the slide beneath it.

Input Schema

NameRequiredDescriptionDefault
dirNoDeck folder (contains deck.mdx). Absolute, or relative to the server's folder. Default: the server's folder.
slideYesA slide: 0-based index (authored order, as deck_outline lists them), "h.v", or its id.

Output Schema

NameRequiredDescriptionDefault
okYes
deckYes
filesYes
notesYes
slideYes
actionYes
slidesYes
diagnosticsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.6

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds real value beyond them by naming the exact artifacts destroyed and disclosing a non-obvious layout side effect: a stack's top slide inherits the column of the slide below. The side effect sentence is terse and hard to parse, and irreversibility/undo is never mentioned, keeping it just short of a 5.

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?

Two sentences, no filler, and the destructive action is front-loaded before the side-effect note. Every clause carries information the agent needs.

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?

With an output schema present and annotations covering the destructive profile, the description covers the essential gaps: what gets deleted and what happens to layout. It omits failure behavior (unknown slide id, deleting the final slide) and whether undo is possible, which are meaningful for an irreversible tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both `dir` and `slide` in detail, including index formats and the "h.v"/id alternatives. The description adds nothing about parameters, so the baseline 3 applies.

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 ("Delete one slide") and enumerates exactly what is removed: separator, frontmatter, body and notes. That scope detail cleanly separates it from siblings like slide_move, slide_update and slide_add, which act on slides without destroying them.

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?

The delete framing implies when to use it, but there is no explicit guidance on when to prefer it over neighboring tools (for example, whether reordering should go through slide_move instead of a delete-and-re-add). No prerequisites, confirmations, or exclusions are stated.

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