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

The annotations carry only low-information false hints (not read-only, not idempotent, not destructive), so the description shoulders the behavioral burden and delivers: bullets win over body, an unfilled two-column side renders as a blank box when edited, all positioning is placeholder-driven with no manual geometry, and unrecognized layouts are rejected. This is substantial behavioral disclosure beyond the annotations, with no contradiction.

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 long (~200 words) but the tool is genuinely complex — 11 layouts, 8 slide fields, precedence rules — and nearly every sentence earns its place. It is front-loaded (purpose, sibling contrast, core mechanic), then organized as a readable layout matrix before behavioral rules and workflow; minor redundancy exists where the early 'fill only the slots' rule is restated by the matrix.

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 exists, so return-value documentation is not the description's job. It covers the behavioral model, slot validity, precedence, and the describe_slides/preview_slides verification loop. The main gap: three of eleven valid PredefinedLayout enum values are not mapped in the description, though the Slides-API knowledge pointer and the fully covered schema partially compensate.

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 100%, so the baseline is 3, but the description adds meaning beyond the per-field schema text: a consolidated layout→slot matrix (TITLE gets a subtitle, SECTION_HEADER does not, TITLE_AND_TWO_COLUMNS must fill both sides or shows a blank box) and the bullets-over-body precedence rule. Only minor deduction because three enum layouts (SECTION_TITLE_AND_DESCRIPTION, ONE_COLUMN_TEXT, CAPTION_ONLY) are absent from the matrix, and field-level semantics are already well covered by the schema.

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?

Opens with a specific verb+resource: 'Create a Google Slides deck from a structured outline.' It then explicitly differentiates itself from the closest sibling, create_presentation, by contrasting raw slides against Google's own layouts, so an agent can disambiguate without opening either schema.

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?

Names the alternative (create_presentation) and the condition that selects this tool: 'suits decks meant to look designed.' It also prescribes a post-call workflow — call describe_slides to catch dropped content/overflow/overlap, then preview_slides — telling an agent exactly what to run after this tool and why.

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