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

Annotations cover mutation/safety flags (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description still adds real behavior: it discloses the return value (new preview images and warnings), the side effect that the original open_url now opens the new version, and the lifecycle rule that edits apply only pre-save. It does not mention permission/auth requirements, which keeps it short of a 5.

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?

Purpose and the 'send only what changes' contract are front-loaded, and every sentence carries substantive information. The final sentence about edit_asset/editor lifecycle is dense and harder to parse, costing a point on structure rather than on length.

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?

There is no output schema, and the description compensates by explaining that it returns preview images and warnings and that the prior open_url resolves to the new version. Combined with the lifecycle and alternative-path guidance, an agent has everything needed to invoke it 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?

Schema description coverage is 100%, so the baseline is 3. The description nonetheless adds patch semantics not obvious from the schema alone ('Send only what changes') and summarizes the op vocabulary, helping the agent understand that changes is an ordered partial-update list rather than a full replacement.

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 (changes a design) and enumerates the concrete operations (set/add/remove/move layers, replace variant background/loop/title, add/remove variant), and anchors the resource as 'a design create_design made, before the user saves it.' It clearly distinguishes itself from create_design (the origin) and edit_asset (the alternate path for saved assets).

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?

Explicitly scopes when to use it (drafts not yet saved by the user) and names the alternatives with their selection conditions: designs changed via edit_asset stay there, and user-saved designs change in the editor or via edit_asset by asset_id. 'Send only what changes' also gives the patch-style invocation contract.

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