Presentations Batch Update

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

Beyond the annotations, the description discloses important behavioral details: it retries transient Drive eventual-consistency failures with exponential backoff up to ~30s, and it recommends writeControl to guard against clobbering concurrent human edits. These add meaningful context beyond the readOnlyHint/destructiveHint annotations.

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 structured into three short paragraphs—purpose, usage instructions, and retry behavior—all of which directly support tool selection and invocation. Every sentence earns its place, with no filler or redundant repetition of schema details.

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 batch update tool with a rich schema and output schema, the description covers purpose, invocation pattern, request construction, concurrency safety, and retry behavior. The reference to the helper function and the writeControl source provides the necessary context for an agent to invoke the tool correctly.

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?

The schema already covers requests, writeControl, and presentationId at 75% coverage; the description adds practical meaning by specifying that requests should be built with build_link_requests() and that writeControl should contain a requiredRevisionId from presentations_get. The user_google_email parameter remains undescribed, but overall the description enhances parameter understanding.

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 'Apply a batch of update requests to a Google Slides presentation (presentations.batchUpdate)', which is a specific verb+resource that immediately identifies the tool's function. It explicitly names Google Slides and the exact API method, distinguishing it from sibling tools like spreadsheets_batch_update and docs_batch_update.

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 description provides concrete usage context: 'Used by the QBR skill to delete chart placeholders and embed LINKED Sheets charts' and explains how to build requests and pass writeControl. It does not explicitly state when not to use the tool or mention alternatives, but the context is clear enough for correct selection.

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