Skip to main content
Glama

Remove slide

remove_slide
Destructive

Delete one whole slide: its script markup, every narration and on-screen text it carries, and its stored element tree, in one atomic write. This is destructive: call with dryRun: true first, summarize what would disappear in user language, then wait for approval. Pass the slideUid from get_slide. Media files remain in the workspace; assets no longer used by any slide are detached from the project.

Input Schema

NameRequiredDescriptionDefault
dryRunNoWhen true, validate without writing anything.
slideUidYesThe stable uid of the slide to remove.
projectUidYes

Output Schema

NameRequiredDescriptionDefault
removedSlideUidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, yet the description still earns credit by detailing the blast radius (atomic removal of markup, narration, text, element tree) and the non-obvious side effects (media files survive; orphaned assets are detached). It stops short of stating irreversibility or any restore path, which keeps it below 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?

Four tight sentences with the scope and destruction list front-loaded, followed by the safety workflow and then the side-effect caveat. No sentence is filler; each adds an actionable fact.

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?

An output schema exists so return values need no explanation, and the description fully covers what a destructive tool needs: what is destroyed, the atomicity guarantee, the dry-run approval gate, and the asset/media aftermath. Nothing an agent needs to invoke it safely 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 67%, and the description meaningfully supplements it by stating where slideUid comes from (get_slide) and by instructing that dryRun be used before the real call. projectUid is left entirely unexplained in both the description and 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?

The description opens with a specific verb and scope ('Delete one whole slide') and enumerates exactly what is removed: script markup, narration, on-screen text, and the stored element tree. That list makes it unmistakable against siblings like update_slide or add_slide without needing to open 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?

It prescribes a concrete workflow: call with dryRun: true first, summarize what would disappear in user language, then wait for approval, and it names get_slide as the source of the slideUid. That is explicit when-and-how guidance rather than implied context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources