Copies a slide, including its shapes, background, and images, so you can reuse content, with an optional position for the copy or append it to the end.
Duplicate a slide, copying its shapes, background and images.
Args: index: Zero-based index of the slide to duplicate. new_index: Optional zero-based position for the copy. When omitted, the copy is appended at the end.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | ||
| new_index | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden: it usefully discloses what content is copied and that omission of new_index appends the copy, but it does not say whether the source slide is unmodified, whether inserting mid-deck shifts subsequent slides, or what identifies the new slide afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded and free of filler, and the per-argument notes are terse. The docstring-style Args formatting is slightly formal for a tool description but costs nothing in readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no annotations and no output schema, the definition covers the mechanics of the call adequately, but an agent still lacks the post-condition (where the duplicate lands, what happens to the source) needed to chain calls confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it largely does: both parameters are defined in prose (zero-based index, optional zero-based target position, append default). It omits bounds behavior for out-of-range or negative indices, which is the main remaining gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ("Duplicate a slide") and enumerates what is carried over (shapes, background, images), which distinguishes it from add_slide (blank creation) and move_slide (reordering). It stops short of explicitly naming those siblings, so the differentiation is inferable 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The args block implies usage via new_index omission (append to end), giving a hint about the default workflow, but there is no explicit when-to-use-this-vs-add_slide guidance and no stated preconditions such as an open presentation or valid index range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.