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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent behavior, so the safety profile is covered structurally. The description adds the default-model behavior (Nano Banana Pro / google-gemini-3-image) and the default-workspace behavior, but says nothing about cost/credit implications or what happens to existing edits — context the schema carries instead. With annotations doing the heavy lifting, a 3 is appropriate.

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?

Front-loaded with the core action and routing rule; the long model enumeration is bulky but each entry is a legitimate disambiguation cue for an agent matching user language. The two fallback defaults are placed at the end where they belong.

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 23-parameter, nested-object tool with an output schema and near-total schema coverage, the description supplies the missing decision layer — when to pick this tool and what defaults apply — without duplicating field documentation. Only the cost/credit aspect of a paid generation is left to the schema.

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 96%, so the baseline is 3, but the description adds genuinely new semantics: the concrete default model ID when none is specified, the default workspace fallback, and a pointer to get_model_catalog for alias resolution. That is real value beyond the schema's own field text.

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?

Starts with a specific verb+resource ("Generate an AI image through Sequencer") and enumerates the exact model families it can target, which cleanly separates it from edit_image, render_image, generate_video, and upscale_image in the sibling list. An agent can identify the tool's job without opening the 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?

Gives explicit trigger conditions ("whenever the user asks to make, create, or generate an image... or names an image model/provider"), names the alternative to prefer against (built-in image generation), and provides a fallback path (use get_model_catalog when an alias is unclear). This is genuine when/when-not routing.

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