delete_slide

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

With no annotations provided, the description carries the full burden of behavioral disclosure—and it delivers. It details destructive side effects, garbage collection behavior, jump-link neutering, atomic saves with two-slot backup, backup rotation skipping, and the nuances of live editing against a locked PowerPoint file. No annotation contradiction exists.

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 description is information-dense but every clause earns its place. The primary destructive action and consequences are front-loaded, followed by parameter semantics, an alternative, and the live-editing caveats. Nothing is redundant, and the structure mirrors the agent's likely decision order: what it does, how to specify it, and what side effects matter.

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 destructive tool with no annotations and 4 parameters, the description covers all critical aspects: object identification, backup behavior, live-session interaction, persistence caveats, and cleanup cascades. The presence of an output schema covers return-value expectations, so nothing essential is missing.

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 does. It clarifies the slide parameter format ('0-based index or {"slide_id": N}'), explains the live options ('auto', 'force', 'off') and their consequences, and defines backup behavior including the backup=False exception. file_path requires no further explanation.

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 description opens with a specific verb and resource—'Delete a slide'—and immediately enumerates the full cascade of what gets cleaned up (notes, charts, embeddings, comments, custom-show references, section membership) and how jump links are handled. This makes the tool's function unmistakable and clearly distinct from siblings like duplicate_slide, reorder_slides, or set_slide_hidden.

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?

It explicitly tells the agent when to prefer an alternative: 'Prefer set_slide_hidden (design pack) when it might come back.' It also explains the live-editing modes and when each is appropriate, including the warning that edits stay unsaved until live_save and that 'off' refuses locked files. This is concrete, actionable routing guidance.

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