reorder_slidesReorder an entire Google Slides presentation by supplying every slide ID exactly once in the desired sequence.
Set the complete slide order. Pass every slide object ID exactly once, in the desired order.
| Name | Required | Description | Default |
|---|---|---|---|
| presentationId | Yes | Presentation ID. Found in the Google Slides URL: docs.google.com/presentation/d/<ID>/edit | |
| orderedSlideIds | Yes | All slide object IDs in the new order |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write-but-not-destructive semantics, so the description's job is to add the nuance that matters: this is a full replacement requiring every slide ID exactly once. That duplicate-omission constraint is real behavioral value beyond the annotations. It stops short of saying what happens if an ID is missing or duplicated (error vs. silent drop).
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?
Two sentences, no waste, with the whole-deck replacement constraint front-loaded before the ordering instruction. Nothing could be removed without losing meaning.
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?
A two-parameter mutation tool with no output schema and clear annotations, so most of the burden is covered elsewhere. However, failure behavior (what happens on missing or duplicate IDs), and whether the prior order is recoverable, are left unstated for a full-replace operation.
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 coverage is 100%, and the schema already describes orderedSlideIds as 'All slide object IDs in the new order'. The description only adds the uniqueness constraint ('exactly once'), which is a modest gain over an otherwise complete schema; baseline 3 applies.
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?
States a specific verb and resource (set slide order) plus the scope ('complete slide order'), which implicitly separates it from move_slide's incremental single-slide move. It never names that sibling explicitly, so the differentiation is inferred 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?
'Set the complete slide order' implies this is the whole-deck reorder path, but there is no explicit when-to-use versus move_slide guidance and no statement of consequences for choosing the wrong one. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.