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

Annotations already declare destructive=true, idempotent=true, readOnly=false and openWorld=true, so the bar is lower, and the description still adds non-annotation context: a mandatory read-before-apply precondition, the requirement to keep current target revisions and Library references valid, and the semantic constraint that saving does not implicitly create tracking. It still does not state what a failed or partial apply leaves behind, nor whether these operations are reversible.

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?

It is short and front-loads the action, and no sentence is padding. But the style is telegraphic fragments ("static or follow framing", "saving never buys tracking", "Cards and pages remain editable text") with no grouping, so a reader must already know the domain to parse the ordering, and the final card/page sentence reads as an orphaned afterthought.

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?

Placeholder.

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 coverage is only 50% and the description names no parameters at all: work_id, arguments (with its nested operation_id, edit_id, expected_revision, operations), and request_key are never explained. "Keep current target revisions" gestures at expected_revision but does not connect it to the field, and the free-form operations array (items typed only as generic objects) is left uncharacterized beyond incidental operation names. With half the schema undocumented, the description fails to compensate.

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 verb+resource is stated ("Apply current version-4 clip operations"), so the broad action is identifiable, but "version-4 clip operations" is opaque jargon that only resolves after a prior bootstrap. It hints at scope via named operation families (set_media, set_canvas, trim_section, split_section) but never contrasts itself with close siblings like native.apply_document_edits, native.apply_film_studio_actions, or native.genads_read_edit.

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?

"Read the edit first" gives one concrete prerequisite, and "Use the tracking skill for explicit measured follow; saving never buys tracking" is a real usage rule that prevents a likely mistake. However, no alternative tool is named as a routing option, there is no when-not guidance, and the read-before-write instruction never points to the specific sibling (native.genads_read_edit) an agent would need.

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