Skip to main content
Glama

duplicate_slide

Duplicate a slide within the same presentation by exporting and reimporting it at a specified position, keeping data server-side.

Instructions

Duplicate a slide within the same presentation. Exports the slide and reimports it at the specified position. Data stays server-side. The reimport makes PowerPoint view jump to the first slide.

Input Schema

NameRequiredDescriptionDefault
slideIndexYesZero-based index of the slide to duplicate
insertAfterNoZero-based slide index to insert the duplicate after. Default: same as slideIndex (duplicate appears right after the source).
presentationIdNoTarget presentation ID from list_presentations. Optional when only one presentation is connected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the export/reimport mechanism, notes 'Data stays server-side,' and warns of a visible side effect ('the reimport makes PowerPoint view jump to the first slide'). It stops short of stating permission requirements or whether notes/animations/layout links are preserved.

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 short sentences, each contributing something: purpose, mechanism, data locality, and the UI side effect. The key action is front-loaded and nothing is padded.

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

Completeness3/5

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

No output schema exists, and the description never says what is returned (presumably the new slide's index or the duplicated slide object), leaving the agent unable to chain on the result. Core behavior and the notable side effect are covered, but this return-value gap plus unstated fidelity guarantees keep it at minimum-viable-plus.

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% — every parameter, including the insertAfter default behavior, is documented in the schema itself. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Duplicate a slide') and constrains scope to 'within the same presentation,' which separates it from the cross-presentation-sounding copy_slides sibling. It does not name copy_slides explicitly, so sibling differentiation is implied rather than stated.

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 scope phrase 'within the same presentation' implies when this tool applies, and 'at the specified position' hints at insertAfter usage. However, it never says when to prefer copy_slides, add_slide, or edit_slide_xml instead, and no prerequisites or exclusions are given.

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