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

Goes well beyond the annotations: it discloses upsert semantics ('repeating an ID updates it'), a workspace-scoping constraint on asset IDs, atomic/undoable transaction behavior, and that dryRun validates without writing. This meaningfully enriches the destructiveHint=true / idempotentHint=true profile rather than repeating it, though it stops short of spelling out what specifically is overwritten on an update.

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?

A single dense paragraph front-loaded with the core action, followed by presets, ID semantics, constraints, and safety notes in descending order of importance. Every clause contributes distinct information with no filler.

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-mutation tool with an output schema (so return values needn't be explained), the description covers workflow, scoping, atomicity, and dry-run adequately. The remaining gap is the conditional per-preset field logic, which is delegated to the schema but is critical to correct invocation.

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 only 40%, so the description carries extra weight here, but it mostly reiterates what the schema already encodes (the preset enum, the 20-item cap). It does add non-schema meaning for `id` (project-scoped, upsert) and `dryRun`, but it does not clarify the per-preset conditional field requirements, leaving the compensating burden partly unmet.

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?

States a specific verb+resource+scope ('Create or update up to 20 visual blocks in one call'), and enumerates the eight presets so the agent knows exactly what it produces. It does not explicitly contrast itself with close siblings like add_text_overlay or carousels_apply_template, so the differentiation is inferable rather than stated.

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 a clear situational precondition — call it 'after edit timing is settled' — and notes 'No generation pass,' implying it consumes existing assets rather than creating them. It offers no explicit when-not conditions or named alternative tools, which keeps it short of a 5.

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