Skip to main content
Glama

delete_slide

Delete a slide and remove all associated references: notes, charts, embeddings, comments, custom-show references, and section memberships. Neuters jump links and handles backups and locked PowerPoint files.

Instructions

Delete a slide and garbage-collect everything only it used: notes, charts, embeddings, comments, custom-show references, section membership; jump links to it are neutered. slide: 0-based index or {"slide_id": N}. Prefer set_slide_hidden (design pack) when it might come back. Saves atomically with two-slot backup; backup=False skips rotation. live='auto' edits the open PowerPoint copy when the file is locked by it (UNSAVED until live_save, com pack); 'force' targets the open session; 'off' refuses locked files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
liveNoauto
slideYes
backupNo
file_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / slide / title
      Removed value: -"Slide"
  2. First observedv1.0.0

TDQS

A5/5.0
Behavior5/5

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

The description goes far beyond the single readOnlyHint:false annotation by disclosing garbage-collection behavior, neutered jump links, atomic saving with two-slot backup, and the unsafe 'UNSAVED until live_save' live-editing caveat. This is exactly the behavioral risk context an agent needs for a destructive tool.

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?

Three dense sentences cover the core action, side effects, alternatives, backup semantics, and live-editing behavior without fluff. The most critical destructive effects are front-loaded, and every clause adds operational value.

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 destructive tool with complex side effects, the description is complete: it covers what gets removed, how to avoid permanent deletion, backup behavior, locked-file behavior, and the live-saving implication. With an output schema present, the lack of return-value detail is not a gap.

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?

Schema description coverage is 0%, so the description must compensate. It defines the slide parameter's accepted forms ('0-based index or {"slide_id": N}'), explains backup=False behavior, and clarifies live mode values. This turns potentially ambiguous schema properties into actionable semantics.

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 the specific action 'Delete a slide' and names the resource, then elaborates the destructive scope: notes, charts, embeddings, comments, custom-show references, section membership, and jump links. This clearly distinguishes it from sibling slide operations like insert_slide, duplicate_slide, and reorder_slides.

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 to prefer set_slide_hidden when the slide might come back, giving a concrete alternative for a common scenario. The live parameter values 'auto', 'force', and 'off' also explain when each mode applies, including the locked-file case.

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