Skip to main content
Glama

PowerPoint Decks and Exports

ppt_deck
Destructive

Create, merge, split, export, validate, and maintain PowerPoint decks with live editing, backups, document properties, and show settings.

Instructions

Whole decks and PowerPoint itself: create, copy, snapshot, backups, copy slides between decks, merge, split, export to PDF, images, handouts or tables, document properties, agenda slides, compression, show settings, custom shows, footers, the opens-clean check (validate), and saving or scrolling a deck open in PowerPoint. Edits to a deck open in PowerPoint stay unsaved for the user to review and save; call live_save only when the user asks. Operations, one per line, as name: what it does:

  • create_presentation: Create a new .pptx, blank or from a template deck; an existing file is refused.

  • copy_presentation: Copy a deck byte for byte to dest_path; an existing destination is refused unless overwrite=true.

  • create_snapshot: Save a permanent copy of the deck in its hidden backup folder, or a visible one in dest_dir; never pruned or overwritten.

  • manage_backups: List, restore or purge the automatic backups (prev and anchor slots); purge is a dry run unless dry_run=false.

  • copy_slide_between: Copy one slide from another deck into this one; the source deck is not changed.

  • merge_decks: Append whole decks onto this deck, in order.

  • split_deck: Split a deck into files by section or slide range; the source is not changed.

  • export_pdf: Export the deck to PDF through PowerPoint, or LibreOffice when PowerPoint is absent.

  • export_slide_image: Render slides to PNG files to check them: slides counts from 0 (or send slide_numbers, from 1) and width sets the pixels (default 1280); the deck is not changed.

  • export_shape_image: Render one shape or group to a PNG at a set width; needs PowerPoint.

  • export_handout: Export a handout or notes-page PDF; needs PowerPoint.

  • export_table: Export a table's content as CSV or JSON, to a file or inline.

  • set_document_properties: Set the deck's document properties; an empty string clears a field.

  • generate_agenda_slide: Insert an agenda slide listing the sections, each linked to its first slide. More operations follow, in the same format, in the op parameter's description.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: one listed in this tool's description, or one of these, in the same format: - refresh_agenda_slide: Rebuild the agenda slide after reordering or section changes. - compress_deck: Shrink a deck by downsampling images; purge_unused=true also drops unused parts, and dry_run=true reports without changing anything. - set_show_properties: Set how the slide show runs: presenter, window or kiosk, looping, timings and range. - manage_custom_show: Create, rename, delete or list custom shows (named slide sequences). - set_footer: Set footer text, slide numbers and dates per slide or deck-wide, where the design allows them. - validate: Check the deck is sound: the file structure, then a real open in a hidden PowerPoint when available. - live_save: Save the open deck, only when the user asks; live edits stay unsaved for them to review. A first key saved_user_work means the save wrote their own edits too. - live_scroll_to: Scroll the open deck's window to a slide so the user can watch edits land.
argsNoThe operation's arguments as an object, including file_path unless the operation names other paths or reads no deck; unknown keys are refused. Slides count from 1 in slide_number and from 0 in slide: the user's slide 2 is slide_number 2 or slide 1. ppt_help lists every argument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important side effects and safeguards: live edits stay unsaved for user review, create_presentation refuses existing files, copy_presentation requires overwrite=true to replace, snapshots are never pruned, backup purge is a dry run unless dry_run=false, and validate opens the deck in hidden PowerPoint. This gives the agent substantial behavioral context for a destructive multi-operation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is long, but the length is largely justified by the 22 operations and it is structured one operation per line. The opening summary slightly duplicates the following operation list, but the format remains front-loaded and navigable.

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?

Given the high complexity, rich op schema, and annotations covering the destructive profile, the description is substantially complete for selecting an operation and understanding key side effects. Remaining gaps are outputs/return values and full per-operation argument coverage, which is partially mitigated by the pointer to ppt_help.

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?

The op parameter is the central dispatch parameter, and the description gives meaningful semantics for the first fourteen enum values that the schema enum alone does not explain. It also adds operation-specific argument hints such as overwrite, dry_run, dest_path, slide numbering, and image width, though it defers full argument documentation to ppt_help.

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

Purpose4/5

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

The description clearly states that this is the deck-level and PowerPoint-operations tool, then enumerates concrete operations such as create, copy, snapshot, merge, split, export, and validate. It is specific about verbs and resources, but it does not explicitly distinguish itself from siblings like ppt_edit, ppt_read, or ppt_inspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description provides clear operational context, including when to call live_save only when the user asks, when existing files are refused, and when dry_run or overwrite flags apply. It does not explicitly route the agent between this tool and the sibling tools, so the sibling-selection guidance is implied rather than stated.

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