move_slide

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

Annotations carry only a title — no readOnly or destructive hints — so the description bears the disclosure burden. It resolves the key behavioral ambiguity by stating that new_index is the post-lift-out final position with a concrete five-slide example, which preents the classic off-by-one error. It does not disclose in-place mutation, bounds behavior, or side effects on slide content, but the indexing semantics are the core unknown here and it nails them.

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 short paragraphs totaling about 40 words, with the one-line purpose front-loaded and the semantic clarification second. The worked example earns its place because it preempts a common misinterpretation rather than padding.

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?

An output schema is present so return values need no explanation, and the parameter set is simple. However, with empty safety annotations and 0% schema coverage, the description omits that the operation mutates the presentation in place and gives no error behavior for out-of-range indices or identical slide_index/new_index calls, leaving boundary conditions to guesswork.

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. It precisely defines slide_index and new_index (0-based, new_index measured after removal) for the two non-obvious parameters, which the bare schema leaves opaque. presentation_id is not mentioned at all, though its meaning is reasonably inferable from context.

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?

The opening sentence names a specific verb and resource ('Move a slide to a different position in the deck'), making the action unmistakable. It distinguishes cleanly from position-adjacent siblings like add_slide, delete_slide, duplicate_slide, and copy_slide_between_presentations without needing to open their schemas.

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?

There is no guidance on when to use this tool vs alternative s; no sibling is named and no exclusions are stated, despite 49 siblings including closely related reordering tools. The phrase 'in the deck' implies a same-presentation operation, but that is left to inference rather than explicitly routed.

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